JTL-Shop durch Bots langsam? 7 Signale aus Access-Logs, bevor Sie blockieren

Die kurze Antwort: Blockieren Sie nicht zuerst den auffälligsten User-Agent. Prüfen Sie zuerst, ob Anfragen in einem klaren Zeitfenster auf teuren Pfaden konzentriert sind, ob gleichzeitig Antwortzeiten und Serverfehler steigen und ob die vermeintlichen Crawler verifiziert werden können. Erst diese Verbindung macht aus „viel Bot-Traffic“ eine belastbare Mitigationshypothese.

Ein langsamer JTL-Shop kann mehrere Ursachen gleichzeitig haben: eine große Zahl neuer Filter-URLs, ein ausgelasteter PHP-Worker-Pool, langsame Datenbankabfragen, ein bereits zu enges Rate Limit oder tatsächlich missbräuchliche HTTP-Anfragen. Access-Logs helfen, diese Möglichkeiten zu trennen. Sie beweisen allein aber keine Ursache.

JTL-Logbuch und Access-Log sind nicht dasselbe

Das JTL-Logbuch erfasst Fehler, Warnungen, Hinweise und Debug-Meldungen der Anwendung. Der offizielle JTL-Guide zum Logbuch beschreibt diese Anwendungssicht.

Für eine Traffic-Analyse brauchen Sie zusätzlich das Access-Log des Webservers, Reverse Proxys, Hosters oder einer vorgeschalteten WAF. Dort steht, welche HTTP-Anfrage wann verarbeitet wurde und mit welchem Status sie endete. Beide Sichten sollten über dasselbe Zeitfenster verglichen werden: Access-Log für das Anfragemuster, JTL- und Infrastrukturmetriken für die Ursache im System.

Der datensparsame Mindestdatensatz

Für eine erste Auswertung reichen wenige Felder. Mehr Daten machen die Analyse nicht automatisch besser.

Nginx stellt beispielsweise mit $request_time eine Request-Dauer bereit. Beachten Sie dabei die Semantik des konkreten Logformats: Request-Dauer, Upstream-Dauer und reine Anwendungszeit sind nicht dasselbe.

Nicht in einen solchen Export gehören Request Bodies, Cookies, Authorization- oder Session-Header, Zahlungsdaten, Bestell- und Kundenexporte, Passwörter, Tokens oder private Schlüssel. Query Strings sollten im abgeleiteten Bericht entfernt werden. E-Mail-Adressen, Tokens, Artikel-IDs und andere hochvariable Segmente lassen sich durch Platzhalter ersetzen; bekannte JTL-Frontcontroller-Routen können als wertfreie Gruppen wie search, product, category oder cart erscheinen.

Wenn ein externer Dienstleister die Logs verarbeitet, gehören Zweck, Übertragung, Speicherort, Zugriff, Aufbewahrung und Löschung vor der Übergabe schriftlich geklärt. Obhut nimmt Access-Logs für eine beauftragte Analyse erst nach unterzeichneter Auftragsverarbeitungsvereinbarung (AVV) entgegen, nutzt einen verschlüsselten Transfer und vereinbart einen Löschtermin für Rohlogs. Senden Sie Rohlogs nicht als offenen E-Mail-Text.

Signal 1: Eine echte Anfrage-Spitze im Incident-Fenster

Zählen Sie Anfragen in kurzen, festen Zeitfenstern, zum Beispiel pro Minute. Vergleichen Sie die betroffene Stunde mit einem ruhigen Referenzfenster unter ähnlichen Bedingungen. Notieren Sie Gesamtzahl, ersten und letzten Zeitpunkt sowie die Spitze pro Minute.

Eine Spitze ist zunächst nur ein Zeitmuster. Kampagnen, Preisimporte, Monitoring, ERP-Aufrufe oder Suchmaschinen können dieselbe Kurve erzeugen wie ein unerwünschter Crawler. Relevant wird sie, wenn im selben Fenster teure Pfade, lange Antwortzeiten oder Fehler auffällig werden. Ein pauschaler Grenzwert für jeden Shop wäre deshalb unseriös.

Signal 2: Ein dynamischer Pfad dominiert den Traffic

Gruppieren Sie normalisierte Pfade und berechnen Sie deren Anteil am Gesamtverkehr. Bei einem JTL-Shop sind insbesondere diese Gruppen interessant:

• Suche und Suchvorschläge,
• Filter und facettierte Navigation,
• Kategorie- und Produktlisten,
• Produktdetailseiten,
• Feeds, Exporte und Sitemaps,
• Warenkorb, Login, Konto und Checkout.

Filterkombinationen können sehr viele verschiedene URLs erzeugen, obwohl sie fachlich dieselbe teure Funktion aufrufen. Google beschreibt für facettierte Navigation ausdrücklich das Risiko praktisch unbegrenzter URL-Räume und den damit verbundenen Ressourcenverbrauch in der Dokumentation zu facettierten URLs. Auch JTL weist in den Sucheinstellungen darauf hin, dass eine zu hohe maximale Trefferzahl die Suche verlangsamen kann.

Das heißt nicht, dass jede Suche geblockt werden sollte. Es heißt: Wenn /suche oder eine Filtergruppe im Incident-Fenster einen großen Anteil trägt, ist sie der erste Ort für eine gemeinsame Prüfung von Crawler-Verhalten, JTL-Konfiguration und Kapazität des Ursprungsservers.

Signal 3: 5xx und besonders 502 steigen gleichzeitig

Zählen Sie nicht nur Statusklassen. Bewahren Sie auch die konkreten Codes auf. Ein Anstieg von 5xx zeigt, dass die Server- oder Upstream-Kette Anfragen nicht erfolgreich beantwortet. Ein 502 in einem Reverse-Proxy-Log kann auf ein Problem zwischen Proxy und Upstream hinweisen; das Access-Log allein sagt nicht, ob PHP-Worker, Datenbank, Anwendung, Netzwerk oder Proxy die Ursache waren.

Entscheidend ist die Korrelation:

• Welche normalisierten Pfade liefern die Fehler?
• Beginnen sie gleichzeitig mit der Anfrage-Spitze?
• Treten sie auch bei normalen Browsern oder bekannten Integrationen auf?
• Was zeigen JTL-Logbuch, PHP-Worker, Datenbank und Host-Metriken im selben Zeitraum?

Wenn 5xx über viele unabhängige Pfade steigen, ist ein reines Crawler-Problem weniger plausibel als ein allgemeiner Kapazitäts- oder Verfügbarkeitsfehler.

Signal 4: Antwortzeiten steigen auf denselben Pfaden

Berechnen Sie je Pfadgruppe mindestens Mittelwert, p95 und Maximum, sofern das Log eine belastbare Dauer enthält. Der Mittelwert zeigt die allgemeine Verschiebung. p95 macht einen langsamen Rand sichtbar. Das Maximum hilft bei der zeitlichen Korrelation mit einzelnen Störungsfenstern.

Diese Werte brauchen immer eine Stichprobengröße. Ein p95 aus zehn Requests ist kein stabiler Leistungsindikator. Er ist lediglich ein Hinweis, den Sie mit PHP-, Datenbank- und Infrastrukturmetriken prüfen. Aussagekräftiger wird das Muster, wenn beispielsweise /suche gleichzeitig einen hohen Traffic-Anteil, mehrere 502 und deutlich längere Antwortzeiten hat.

Signal 5: 429 trifft bereits geschäftskritische Pfade

429 Too Many Requests bedeutet, dass irgendwo bereits eine Anfragerate begrenzt wird. Der Standard lässt offen, wie gezählt und welcher Akteur identifiziert wird; er erlaubt einen Retry-After-Hinweis. Das beschreibt RFC 6585.

Prüfen Sie deshalb für jeden 429:

• Pfad und Methode,
• Quelle und User-Agent-Familie,
• welches System den Status erzeugt hat,
• konfigurierte Schwelle und Zeitfenster,
• Auswirkungen auf Käufer, Suchmaschinen und Integrationen.

Drei 429 auf automatisierten Suchanfragen können ein funktionierender Schutz sein. Drei 429 auf POST /warenkorb können dagegen zeigen, dass eine bestehende Regel bereits legitime Geschäftsprozesse gefährdet. Die richtige Reaktion ist dann nicht automatisch ein noch engeres Limit.

Signal 6: Eine User-Agent-Familie ist konzentriert – aber nicht verifiziert

User-Agents lassen sich in begrenzte Familien wie Googlebot, Bingbot, AhrefsBot, SemrushBot, HeadlessChrome, curl oder python-requests gruppieren. Das reduziert Varianten und macht Zeitverläufe vergleichbar.

Der Header ist jedoch frei wählbar. Eine Anfrage mit Googlebot im User-Agent ist noch kein Googlebot. Google empfiehlt vor einer Block- oder Ausnahmeentscheidung den Abgleich mit den veröffentlichten IP-Bereichen oder eine Reverse-DNS-Prüfung mit anschließender Forward-DNS-Bestätigung. Die aktuelle Anleitung steht unter Google-Anfragen verifizieren.

Führen Sie dieselbe Prüfung bekannter legitimer Akteure für Payment Provider, ERP/PIM, Feeds, Monitoring und eigene Automatisierung durch. Eine prominente Familie ist ein Kandidat für eine beobachtende Regel, nicht automatisch für eine Block-Regel.

Signal 7: Wenige grobe Quellmuster tragen einen großen Anteil

Quelladressen können für den Bericht datensparsam zu IPv4-/24- oder IPv6-/48-Mustern zusammengefasst werden. Vergleichen Sie Anteil, ersten und letzten Zeitpunkt des Musters sowie die betroffenen Pfade.

Vor einer Maßnahme müssen Sie klären, ob die Quelle wirklich die Client-Adresse ist. Steht im Log nur die private Adresse des Reverse Proxys, fehlt die Entscheidungsgrundlage. Auch ein öffentliches Netz kann ein NAT, Hosting-Proxy, Suchmaschinenbereich oder Partnernetz sein. Quellkonzentration allein rechtfertigt deshalb keinen Block.

Kritische Pfade werden vor jeder Maßnahme separat geprüft

Erstellen Sie vor dem ersten Limit eine kurze Allow-/Avoid-Liste. Sie ist wichtiger als eine lange Liste vermeintlich böser Bots.

Eine Regel, die den Checkout schützt, kann den Checkout zugleich abschneiden. Deshalb brauchen umsatz- und betriebsrelevante Pfade einen eigenen Test, eine verantwortliche Person und ein Abbruchkriterium.

Die sichere Reaktionsleiter: vom URL-Raum bis zum zeitlich begrenzten Notfall

Beginnen Sie mit der Maßnahme, die am wenigsten legitimen Traffic beeinflusst.

1. URL-Raum bereinigen. Prüfen Sie interne Links, Canonicals, Sitemaps und die Facettenstrategie. Nutzen Sie robots.txt für kooperative Crawler, wenn bestimmte Filter-URLs nicht gecrawlt werden sollen. Der Robots Exclusion Protocol ist laut RFC 9309 ausdrücklich kein Zugriffsschutz.
2. Nur beobachten. Erfassen Sie Treffer einer konkreten Pfad-, Methoden-, Header- oder Quellregel, ohne zu blockieren. Prüfen Sie mindestens ein repräsentatives Last- und Geschäftsfenster.
3. Einen teuren Pfad konservativ begrenzen. Starten Sie mit einer großzügigen, pfadspezifischen Schwelle. Beobachten Sie 429, 5xx, Antwortzeit, Checkout und bekannte Akteure.
4. Nur verifizierte Muster blockieren. Stellen Sie eine Regel erst dann auf Blockierung um, wenn Treffer, legitime Ausnahmen, verantwortliche Person, Stop-Kriterium und Rollback dokumentiert sind. Eine Kombination aus Pfad, Methode und geprüftem Akteur ist meist belastbarer als ein User-Agent allein.
5. Notfallmaßnahmen zeitlich begrenzen. Challenge- oder Under-Attack-Modi gehören in ein aktives Störungsfenster, nicht in den Dauerbetrieb ohne Ausnahmen. Für einen tatsächlich überlastenden, verifizierten Googlebot nennt Google temporäre 429 oder 503 als Notfalloption, warnt aber vor längerem Einsatz und möglichen Indexierungsfolgen. Siehe Googles Hinweise zu übermäßigem Crawling.

Diese Reihenfolge trennt kooperative Steuerung, Beobachtung, Drosselung und Blockierung. Sie verhindert auch, dass ein SEO- oder Ursprungsserver-Problem vorschnell als Sicherheitsregel konserviert wird.

Rollback gehört vor die erste produktive Regel

Dokumentieren Sie vor jeder Änderung:

• Regel oder Limit, Startzeit und verantwortliche Person,
• erwartete Wirkung und zu beobachtende Kennzahlen,
• bekannte gute Akteure und kritische Pfade,
• Abbruchschwellen für Checkout, Payment, Suche, 429, 5xx und Erreichbarkeit,
• den letzten bekannten guten Zustand,
• den konkreten technischen Rückweg.

Bei einer Fehlblockierung wird in umgekehrter Risikoreihenfolge zurückgebaut:

1. die letzte WAF-Blockregel auf Beobachtung stellen oder deaktivieren,
2. das betroffene pfad- oder anwendungsweite Limit lockern oder deaktivieren,
3. einen Challenge-/Under-Attack-Modus deaktivieren,
4. falls der gesamte Pilotpfad betroffen ist, das vorher vereinbarte Routing wiederherstellen.

Nach jedem Schritt werden Käuferfluss, Checkout, Payment, Suche und Erreichbarkeit erneut geprüft. Ein Vorher-/Nachher-Vergleich zeigt beobachtete Änderungen; er beweist nicht, dass eine einzelne Regel sie verursacht hat.

Synthetisches Beispiel: 24 Anfragen, keine Kundendaten

Transparenz: Das folgende Beispiel stammt aus einem künstlich erzeugten JTL-ähnlichen Access-Log mit den in RFC 5737 reservierten Dokumentationsadressen. Es enthält keine Kunden-, Interessenten- oder Produktionsdaten und ist keine Fallstudie. Der Auswertungszeitraum umfasst vier Minuten; alle 24 Zeilen wurden erkannt.

Aus diesem Beispiel lässt sich eine Reihenfolge ableiten: zuerst Suche und Filter mit Metriken des Ursprungsservers korrelieren, dann das bestehende Warenkorb-Limit prüfen, Crawler-Familien nur beobachten und bekannte Suchmaschinen verifizieren. Nicht ableitbar ist, dass „Bots den Ausfall verursacht“ haben oder dass ein Block die Antwortzeiten verbessern würde.

Was Access-Logs nicht beantworten

Auch eine saubere Auswertung hat Grenzen:

• Sie zeigt keine PHP-Worker-, CPU-, Speicher-, Datenbank- oder Cache-Auslastung.
• Ein User-Agent kann gefälscht, eine Adresse geteilt und ein Quellheader falsch konfiguriert sein.
• Normalisierung und entfernte Query-Werte schützen Daten und reduzieren Kardinalität, verlieren aber Detailinformation.
• Ein kurzes oder nicht repräsentatives Fenster verzerrt Anteile und Perzentile.
• 5xx, lange Dauer und Crawler-Traffic im selben Fenster zeigen Korrelation, nicht Kausalität.
• HTTP-Access-Logs erklären keine volumetrischen Layer-3-/Layer-4-Angriffe.

Deshalb sollte jeder Bericht Parse-Abdeckung, Zeitraum, Zeitzone, Datenquelle, fehlende Felder und offene Unsicherheiten sichtbar ausweisen.

Wo Obhut heute hilft – und wo nicht

Obhut passt, wenn sich die Last als HTTP-Muster aus Pfad, Header, Methode, IP/CIDR oder Anfragerate untersuchen und vorsichtig begrenzen lässt. In einem geführten Pilot können wir bereitgestellte Access-Logs datensparsam auswerten, normalisierte Pfade, Methoden, Statuscodes, begrenzte User-Agent-Familien, grobe Quellmuster und vorhandene Dauerfelder vergleichen und daraus einen prüfbaren Maßnahmenplan erstellen.

Für Traffic, der kontrolliert über Obhut läuft, stehen benutzerdefinierte WAF-Regeln in log- oder block-Modus und Per-IP-Limits auf Pfad- und Anwendungsebene zur Verfügung. Ein Under-Attack-Modus lässt sich manuell aktivieren und wird im Pilot nur für ein vereinbartes Incident-Fenster eingesetzt. Jede produktive Maßnahme bleibt manuell geprüft, kundenseitig freigegeben und rückrollbar. Für tatsächlich aufgezeichnete harte Sicherheitsablehnungen lässt sich die Integrität der Ereigniskette und eines bereitgestellten Nachweispakets prüfen. Nicht automatisch gespeichert wird jede einzelne Crawler-Anfrage.

Obhut ist kein CDN oder Cache, kein globales Anycast-Netz und kein volumetrischer DDoS-Scrubber. Offline-Vorschläge werden nicht automatisch umgesetzt; es gibt heute kein ML-Reputationssystem, keine verwaltete crawler-spezifische Bot-Reputation und keinen kundenseitigen Forensik-Explorer für jede Anfrage. Wenn primär Hosting-Kapazität, Caching oder Layer-3-/Layer-4-Abwehr fehlt, ist ein anderer erster Schritt passender.

Quellen und weiterführende Dokumentation

• JTL-Guide: Logbuch einsehen
• JTL-Guide: Sucheinstellungen
• Google: Facettierte Navigation und Crawling
• Google: Anfragen von Crawlern und Fetchern verifizieren
• Google: Fehler und übermäßiges Crawling behandeln
• IETF RFC 9309: Robots Exclusion Protocol
• IETF RFC 5737: IPv4-Adressbereiche für Dokumentation
• RFC Editor: RFC 6585 und HTTP 429
• Nginx: Semantik von request_time