Wenn Bots Ihre Filternavigation durchpflügen — und warum Rate-Limits nichts bringen
Verteilte Crawler bleiben unter jeder Schwelle und fälschen den User-Agent. Trennscharf ist ein anderes Merkmal: die Anzahl kombinierter Filter.
Ein Shop, dessen Startseite normal lädt, dessen Kategorieseiten aber zäh werden. Im Zugriffslog: hunderttausende Aufrufe auf URLs mit fünf, sechs, sieben Filterparametern. Kein Angriff — ein Crawler, der die Filternavigation systematisch durchgeht.
Das Problem daran ist nicht der einzelne Aufruf. Es ist die Kombinatorik.
Warum die Zahl so schnell explodiert
Eine Filternavigation mit Hersteller, Preisspanne, Farbe, Größe und Verfügbarkeit sieht überschaubar aus. Rechnet man die Kombinationen durch, ergeben fünf Filter mit je fünf Werten über dreitausend gültige URLs — mal drei Sortierungen, mal die Seitenzahlen. Aus einer Kategorie mit zweihundert Artikeln werden so schnell fünfstellige URL-Mengen.
Für Ihren Shop bedeutet das dreierlei: Rechenlast für Filterabfragen, die zu den teuersten Datenbankoperationen überhaupt gehören. Cache-Einträge, die das Dateisystem fluten — dazu habe ich den Fall mit dem Inode-Limit ausführlich beschrieben. Und Crawl-Budget, das an Filterkombinationen verbraucht wird statt an Ihren Produktseiten.
Was in der Praxis nicht funktioniert
Rate-Limits nach IP. Klingt naheliegend und scheitert an der Realität verteilter Crawler. Wenn sich die Abrufe auf hunderte Adressen verteilen, bleibt jede einzelne IP deutlich unter jeder Schwelle, die Sie für echte Kunden noch verantworten können. In einem Fall, den ich untersucht habe, lag der Spitzenwert bei rund hundert Aufrufen pro Stunde und IP — das erreicht ein Kunde mit mehreren Browsertabs auch.
Sperren nach User-Agent. Wer sich die Mühe macht, systematisch zu crawlen, sendet einen aktuellen Browser-Kennstring und einen plausiblen Referer gleich mit. Sie sperren damit die höflichen Bots aus und die unhöflichen bleiben.
robots.txt. Wirkt bei Suchmaschinen, die sich daran halten. Genau die sind selten das Problem.
Was trennscharf funktioniert
Es gibt ein Merkmal, das echte Kunden praktisch nie erzeugen: die Anzahl gleichzeitig kombinierter Filter.
Wer in einem Shop einkauft, wählt Hersteller und vielleicht eine Preisspanne. Manchmal kommt eine Größe dazu. Drei Filter sind viel, vier sind die Ausnahme. Ein Crawler dagegen geht bis zur letzten Kombination — der Unterschied ist nicht graduell, sondern kategorisch.
Daraus lässt sich eine Regel bauen, die auf Webserver-Ebene greift, bevor PHP überhaupt startet:
# Anfragen mit sehr vielen kombinierten Filtern beenden
RewriteCond %{QUERY_STRING} (^|&)(f|filter)\[[^\]]*\](=|&|$) [NC]
RewriteCond %{QUERY_STRING} ^(.*&){6,}
RewriteRule ^ - [R=410,L]
Zwei Punkte dazu, die über Erfolg oder Ärger entscheiden:
Status 410 statt 403. „Gone” signalisiert Suchmaschinen, dass diese URLs dauerhaft weg sind — sie verschwinden schneller aus dem Index als bei 404 und werden seltener erneut abgerufen.
Die Schwelle gehört verifiziert, nicht geraten. Sechs Parameter sind ein Startwert, kein Naturgesetz. Zählen Sie im eigenen Log nach, wie viele Parameter Ihre echten Kunden und wie viele der Bot verwendet. Erst wenn dazwischen eine klare Lücke liegt, setzen Sie die Schwelle hinein.
Die Falle beim Auswerten des Logs
Genau bei dieser Auswertung bin ich schon zweimal auf dieselbe Stelle hereingefallen. In der üblichen Log-Zeile steht die angefragte URL innerhalb des ersten Anführungszeichen-Paares:
1.2.3.4 - - [28/Jul/2026:10:15:32 +0200] "GET /kategorie?f[a]=1&f[b]=2 HTTP/1.1" 200 4711 "-" "Mozilla/5.0 ..."
Trennt man mit awk -F'"', ist die Anfrage nicht Feld 1, sondern Feld 2 — Feld 1 ist alles davor. Wer das übersieht, wertet Zeitstempel statt URLs aus und kommt zu wunderbar plausiblen, völlig falschen Zahlen.
Sauber zählt man so:
awk -F'"' '{print $2}' access.log \
| grep -oE '\?[^ ]*' \
| awk -F'&' '{print NF}' \
| sort -n | uniq -c
Das gibt Ihnen die Verteilung: wie viele Anfragen mit einem Parameter, wie viele mit zwei, wie viele mit zwölf. Die Lücke in dieser Verteilung ist Ihre Schwelle.
Was ich zusätzlich empfehle
Filterseiten auf noindex, follow. Verhindert die Aufnahme in den Index, lässt Links aber weiterverfolgen. Ergänzt die Sperre, ersetzt sie nicht.
Canonical auf die ungefilterte Kategorie. Damit landen Signale auf der Seite, die tatsächlich ranken soll.
Den Cache im Blick behalten. Wenn Filterergebnisse auf der Platte landen, ist das Aufräumen ein Wettlauf, den Sie verlieren. Besser gar nicht erst cachen oder in den Arbeitsspeicher legen.
Nach dem Scharfschalten das Log kontrollieren. Nicht die Serverlast — die sinkt sofort und beruhigt trügerisch. Schauen Sie nach, ob Suchmaschinen-Bots in die Regel laufen. Wenn ja, ist die Schwelle zu niedrig, und das merken Sie sonst erst an fallenden Rankings.
Häufige Fragen
Warum sind Filter-URLs überhaupt ein Problem?
Weil ihre Zahl kombinatorisch wächst. Fünf Filter mit je fünf Werten ergeben bereits über dreitausend Kombinationen, mit Sortierung und Seitenzahlen ein Vielfaches. Jede dieser URLs erzeugt Serverlast, oft einen Cache-Eintrag, und verbraucht Crawl-Budget, das für Ihre Produktseiten fehlt.
Reicht es nicht, die Filterseiten auf noindex zu setzen?
Das verhindert die Aufnahme in den Index, nicht das Crawlen. Der Bot ruft die Seiten weiterhin ab, Ihr Server rechnet weiterhin, der Cache füllt sich weiterhin. Gegen die Last hilft nur, die Anfragen früher zu beenden oder gar nicht erst zu ermöglichen.
Sperre ich damit nicht auch Google aus?
Nicht, wenn die Schwelle richtig gewählt ist. Google folgt Ihrer Filternavigation, kombiniert aber selten mehr als drei bis vier Filter gleichzeitig. Prüfen Sie die Schwelle immer erst am eigenen Zugriffslog, bevor Sie eine Regel scharf schalten.
