JTL-Shop langsam? Oft sind es Bots: Zugriffe auswerten, Filter-URLs bremsen, Bot-Netze sperren

Der Shop reagiert zäh, Kategorieseiten laden langsam, der Hoster meldet hohe Last – und in den Besucherstatistiken ist trotzdem kein Ansturm zu sehen. In solchen Fällen lohnt ein Blick in das Zugriffsprotokoll des Webservers. Häufig zeigt sich dort, dass ein großer Teil der Anfragen gar nicht von Menschen stammt, sondern von Crawlern und Bot-Netzen.

Dieser Artikel beschreibt den Weg, den wir in mehreren Fällen bei JTL-Shops gegangen sind: Protokoll auswerten, Filter-URLs per robots.txt bremsen, Bot-Netze gezielt sperren – und dabei sicherstellen, dass keine echten Kunden im Sperrnetz landen.

Das Symptom

Typische Anzeichen für Bot-Last:

• spürbar langsame Kategorie- und Filterseiten, vor allem zu Zeiten ohne Kampagnen,
• viele Antworten mit Status 429 (zu viele Anfragen) im Protokoll – der Server drosselt bereits,
• Analyse- oder Tracking-Werte, die nicht zu Umsatz und Warenkörben passen,
• gelegentlich Fehler 500, wenn ein Hintergrundprozess regelmäßig abbricht.

In einem Fall stammte rund ein Viertel aller Anfragen eines Tages von einem einzigen Bot-Netz, ein weiteres Viertel entfiel auf Filter-URLs. Der Server beantwortete zehntausende Anfragen am Tag mit 429.

Schritt 1: Das Zugriffsprotokoll auswerten

Die Besucherstatistik des Shops ist für diese Frage zu ungenau. In einem Fall waren die IP-Adressen dort anonymisiert (die letzten zwei Stellen genullt) – für Sperren unbrauchbar. Sie brauchen das Access-Log des Webservers, bei Shared Hosting meist im Kundenmenü des Hosters herunterladbar, oft als .gz-Datei je Tag.

Werten Sie mindestens einen vollständigen Tag aus und zählen Sie:

• Anfragen je User-Agent: Welche Crawler und Browserkennungen dominieren?
• Anfragen je Netzbereich: Kommen auffällig viele Aufrufe aus wenigen Netzen, etwa eines Cloud-Anbieters?
• Filter-URLs: JTL-Shop bildet kombinierte Merkmalfilter in SEO-URLs mit doppeltem Unterstrich ab (/Kategorie__Merkmal__Wert). Wie viele Aufrufe enthalten __, und wie viele Filter sind darin kombiniert?
• URL-Parameter: Sortierung, Blättern, Verfügbarkeit, Suche sowie Klick-Kennungen von Werbeplattformen, die denselben Artikel unter vielen URLs erscheinen lassen.
• Statuscodes: Anteil von 200, 404, 429 und 500.

Ein einfacher Einstieg auf der Kommandozeile – hier die häufigsten User-Agents:

zcat access.log.gz | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -30

Was wir typischerweise finden

• Seriöse Crawler auf Filter-URLs: Bingbot, GoogleOther, KI-Crawler und SEO-Werkzeuge folgen jeder Filterkombination. Bei vielen Merkmalen entstehen so praktisch unendlich viele URLs.
• Bot-Netze mit gefälschten Kennungen: In einem Fall kamen die Anfragen aus wenigen Netzen eines Cloud-Anbieters aus Asien, mit bunt gemischten, veralteten Desktop-Chrome-Versionen und null Mobilgeräten. Die Seiten wurden vollständig geladen – dadurch feuerte auch das Tracking und verfälschte die Statistik.
• Fremdnutzen-Crawler: In einem Fall waren nur Google und Bing für die Auffindbarkeit relevant; ein großer Teil der übrigen Crawler-Besuche brachte dem Shop keinen erkennbaren Nutzen.

Prüfen Sie auch, ob ein „Googlebot“ wirklich von Google stammt. Die Kennung lässt sich beliebig fälschen; verlässlich ist erst die Prüfung per Reverse-DNS. Wer nach User-Agent sperrt oder freigibt, ohne das zu prüfen, trifft womöglich den echten Crawler und lässt den falschen durch.

Schritt 2: Filter-URLs per robots.txt bremsen

Der größte Hebel gegen seriöse Crawler ist, sie von den Filterkombinationen fernzuhalten. Die Kategorieseiten selbst bleiben erreichbar, nur die Kombinationen mit mehreren Filtern werden ausgeschlossen. Eine allgemein formulierte Regel:

User-agent: *
Disallow: /*__*__*

Enthält Ihre robots.txt eigene Blöcke für einzelne Crawler (etwa User-agent: Bingbot), muss die Regel in jedem dieser Blöcke stehen – ein Crawler liest nur den für ihn passenden Block.

Ob Sie zusätzlich Parameter wie Sortierung oder Werbe-Klickkennungen ausschließen, sollten Sie anhand Ihres Protokolls und Ihrer SEO-Strategie entscheiden. Eine pauschale Liste empfehlen wir nicht.

Wo die robots.txt herkommt

Bei JTL-Shop wird die robots.txt häufig nicht als statische Datei ausgeliefert, sondern per Rewrite-Regel von robots.php erzeugt. Erkennbar ist das an den Antwort-Headern, etwa einem Expires-Datum weit in der Vergangenheit und Cache-Control: no-store. In diesem Fall bringt es nichts, eine Datei robots.txt hochzuladen – gepflegt wird der Inhalt dann in der Shop-Verwaltung. In anderen Installationen liegt sie als Datei im Shop-Verzeichnis. Prüfen Sie nach jeder Änderung im Browser, was tatsächlich unter /robots.txt ausgeliefert wird.

In einem Fall war die robots.txt praktisch leer (Disallow: ohne Wert) – Crawler durften also alles.

Wirkung

In einem Fall sank der Bingbot-Verkehr auf Filter-URLs nach der Regel innerhalb von zwei Tagen auf null. In einem anderen Fall gingen die Anfragen auf Filter-URLs binnen weniger Tage um rund drei Viertel zurück; die großen Crawler waren dort vollständig verschwunden. Wichtig: Die robots.txt wirkt nur bei Crawlern, die sich daran halten. Bot-Netze ignorieren sie.

Schritt 3: Bot-Netze sperren – mit Prüfung vorher

Für Bot-Netze bleibt die Sperre in der .htaccess (bei Apache oder LiteSpeed). Auf Shared Hosting ist eine Sperre nach Land oft nicht verfügbar, dann geht es nur über IP-Bereiche oder Merkmale der Anfrage.

Die CGNAT-Falle

Bevor Sie einen Netzbereich sperren, prüfen Sie im Protokoll, welche User-Agents darin vorkommen. Wir haben in einem Fall einen Bereich gesperrt, der auf den ersten Blick zu einem Cloud-Anbieter gehörte. Tatsächlich war es ein deutsches Mobilfunknetz. Über die Hälfte der Anfragen kam von echten Smartphones, teils über bezahlte Anzeigen – diese Kunden erhielten „403 Forbidden“, bis die Regel wieder entfernt war.

Viele Anfragen von einer einzigen IP sind bei Mobilfunk kein Bot-Merkmal. Hinter einer Adresse (Carrier-Grade NAT) surfen viele Kunden des Netzbetreibers gleichzeitig. Umgekehrt spricht das Muster „eine Anfrage je IP, tausende verschiedene IPs“ eher für ein Bot-Netz über Proxys.

Prüfen Sie vor jeder Netz-Sperre:

# Welche User-Agents stecken im Bereich?
grep -E '^203\.0\.113\.' access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head

# Gibt es Anzeichen echter Mobilnutzer?
grep -E '^203\.0\.113\.' access.log | grep -icE 'iPhone|Android|Mobile Safari|Instagram|gclid|msclkid'

Der Bereich 203.0.113.x ist ein Dokumentationsbereich und dient nur als Platzhalter. Finden Sie Mobilgeräte, deutsche Spracheinstellungen oder Klickkennungen aus Werbekampagnen, handelt es sich um einen Internetanbieter – nicht sperren. Ein reines Bot-Netz sah in unseren Fällen anders aus: ausschließlich Windows-Desktop-Kennungen mit wild gemischten, veralteten Browserversionen. Zusätzlich lohnt der Abgleich mit den Bestellungen: Kamen aus dem Bereich Käufe oder Warenkörbe?

Die Sperre selbst

Erst wenn die Prüfung eindeutig ist, folgt die Regel – möglichst weit oben in der .htaccess, vor den Rewrite-Regeln des Shops:

RewriteEngine On
# Bot-Netz, im Protokoll geprüft am JJJJ-MM-TT (nur Desktop-Kennungen, keine Bestellungen)
RewriteCond %{REMOTE_ADDR} ^203\.0\.113\.
RewriteRule .* - [F,L]

Sichern Sie die .htaccess, bevor Sie sie ändern, und kommentieren Sie jede Sperre mit Datum und Begründung. In einem Fall gab das Bot-Netz nach einigen Tagen durchgehender 403-Antworten weitgehend auf.

Wenn die IPs ständig wechseln

Bot-Netze ziehen oft weiter: In einem Fall wechselten sie nach der Sperre in andere Cloud-Netze und über Proxys mit privaten Anschlüssen, auch aus Deutschland, und nutzten plötzlich aktuelle Browserkennungen. IP-Sperren laufen dann hinterher.

Wirksamer war dort ein Merkmal der Anfrage selbst: Echte Besucher setzten fast immer nur einen Filter, das Bot-Netz kombinierte fünf bis neun. Eine Regel, die URLs mit vier oder mehr Filtersegmenten abweist, traf unabhängig von IP und Kennung:

RewriteCond %{REQUEST_URI} "(__.*){4}"
RewriteRule .* - [F,L]

Übernehmen Sie diese Schwelle nicht ungeprüft. Zählen Sie vorher in Ihrem Protokoll, wie viele Filter echte Besucher kombinieren und ob Warenkorb, Bestellvorgang oder Bestellungen URLs mit so vielen Segmenten betreffen.

In einem anderen Fall waren die Bot-Kennungen technisch unmöglich – etwa Gerätemodelle mit einer Android-Version, die es für dieses Gerät nie gab. Eine Sperre nach genau diesen Kennungen half, ist aber nur eine Momentaufnahme: Sobald die Kennung wechselt, muss die Regel nach einem frischen Protokoll angepasst werden.

Schritt 4: Unnötige Last im Shop selbst entfernen

Das Protokoll zeigt oft auch hausgemachte Last:

• Nicht mehr genutzte Plugins: In einem Fall rief ein Cronjob alle 15 Minuten ein Plugin eines Drittanbieters auf, das jedes Mal mit Fehler 500 abbrach. Nach Entfernen des Plugins und des Cronjobs gingen die 500er von rund 80 auf 2 am Tag zurück.
• Fehlende Dateien: Ein Template verwies auf eine nicht vorhandene favicon.ico – über 1.600 Fehler 404 am Tag. Eine einfache Datei im Shop-Verzeichnis beseitigte sie.

Fehlerbild auf einen Blick

Schritt 5: Nachher kontrollieren

Eine Sperre ist erst fertig, wenn sie im Protokoll bestätigt ist. Werten Sie zwei bis drei Tage nach der Änderung erneut aus und vergleichen Sie mit dem Ausgangstag:

• Anfragen auf Filter-URLs und Anteil der großen Crawler darauf,
• Anzahl der 429-, 403- und 500-Antworten,
• wer die 403 erhält: Tauchen Mobilgeräte oder Kunden aus Werbekampagnen auf, ist eine Regel zu breit,
• Bestellungen und Warenkörbe im gewohnten Rahmen.

In einem Fall sank die Gesamtzahl der Anfragen nach robots.txt und Sperren um rund ein Drittel, die 429-Antworten gingen um rund 90 % zurück – ohne Fehlsperren bei deutschen Kunden. Danach genügt es, das Protokoll gelegentlich anzusehen, etwa wenn die 429-Antworten wieder steigen.

Wenn Sie Unterstützung möchten

Die Auswertung großer Zugriffsprotokolle und das sichere Formulieren von Sperrregeln kosten Zeit, und Fehler treffen direkt den Umsatz. Als zertifizierter JTL-Servicepartner unterstützt PC-Mixx Sie bei Analyse, robots.txt und .htaccess-Regeln für Ihren JTL-Shop.

Häufige Fragen