Die ?q=-Flut überstehen: Wie Crawler-Traffic die PrestaShop-Facettensuche zum DoS-Risiko macht

Sie wachen auf und finden mehrere Kunden-E-Mails vor, die fragen, warum die Website um 3 Uhr nachts nicht erreichbar war. Die Bestellzahlen sind normal, die Fehlerseite erscheint nur zeitweise, und im Admin-Dashboard sieht alles unauffällig aus. Der Hoster schickt eine Grafik: MySQL-Verbindungen am Limit, alle PHP-FPM-Worker belegt. Keine dieser Anfragen kam von echten Kunden.

Ein PrestaShop-Shop mit facettierter Suche (Layered Navigation) kann diesem Muster ausgesetzt sein, abhängig von URLs, Crawler-Traffic und Kapazität. Das Problem wirkt unspektakulär, die Ursache ist strukturell, und die richtige Lösung ist nicht die, zu der die meisten Shopbetreiber zuerst greifen. Bei der ?q=-Flut verwandelt gewöhnlicher Crawler-Traffic Ihre eigene Facettensuche in eine selbst geschaffene Denial-of-Service-Angriffsfläche. Den größeren Zusammenhang finden Sie in unserer Checkliste zur PrestaShop-Sicherheits-Härtung, die alle Ebenen miteinander verbindet.

Zuletzt aktualisiert: Juni 2026.

Das Symptom

Die Logs zeigen Tausende Anfragen an URLs wie /category-slug?q=Brand-Brand-A/Brand-Brand-B/Color-Red, jede leicht anders, von wechselnden IPs und mit gemischten angegebenen User-Agents. Manche geben vor, Bingbot zu sein, manche Chrome, andere melden sich als GPTBot, ClaudeBot oder PerplexityBot. Die Kategorie-URL selbst ist legitim, es ist Ihre eigene Facettensuche, die Marken- und Attributfilter als Query-String-Parameter ausgibt, aber das Volumen und die kombinatorische Vielfalt der Anfragen sind es nicht.

In den PrestaShop-Foren finden sich Berichte zu diesem Muster von Shopbetreibern mit 1.7.x und 8.x aus den Jahren 2024 und 2025. Das Bild ist immer ähnlich: Schon ein einzelner Thread dokumentiert Händler, die täglich Zehntausende einzigartige ?q=-URLs gecrawlt sehen, während der Controller selbst nach dem Deaktivieren des Moduls ps_facetedsearch weiter antwortet.

Das Erste, was die meisten Betreiber versuchen, ist das Deaktivieren des Moduls für die Facettensuche. Das kann die Filterberechnung reduzieren, stoppt aber keine Aufrufe bekannter URLs. ps_facetedsearch stellt Oberfläche und Filterlogik bereit; eine GET-Anfrage an /category-slug?q=anything kann PrestaShop auch nach dem Deaktivieren starten und den Kategorie-Controller erreichen. Die Filter-Seitenleiste verschwindet, automatisierte Clients können bereits entdeckte URLs jedoch weiter aufrufen.

Warum das Volumen wächst

Die kombinatorische Natur von URLs der Facettensuche gibt es seit der Auslieferung des Moduls. Neu ist das Ausmaß des automatisierten Traffics, der diese URLs findet und crawlt.

Cloudflares Analyse vom Juli 2025 zum Crawler-Traffic im eigenen Netzwerk meldete:

• Crawler-Traffic plus 18 % im Jahresvergleich, mit Spitzen von 32 % im April 2025.
• Googlebot: +96 % Wachstum, von ungefähr 30 % auf 50 % des gesamten Crawl-Traffics.
• GPTBot: +305 % Wachstum, von 2,2 % auf 7,7 % Anteil.
• PerplexityBot: innerhalb eines Jahres von praktisch null zu relevant.
• ClaudeBot: nach Änderungen Anfang 2025 um 46 % weniger Anfragen.
• Bytespider: minus 85 %.

Die Zusammensetzung verschiebt sich von Monat zu Monat, aber der Trend bleibt: mehr Crawler, die mehr URLs häufiger abrufen. Eine Kategorieseite, die ein paar hundert Filterkombinationen erzeugt, wird zum Ziel für alles, von Googlebot beim Aufbau strukturierter Datenindizes bis zu KI-Trainings-Scrapern, die Produktattribute sammeln. Cloudflare selbst begann Mitte 2025 damit, KI-Trainings-Bots auf neuen Zonen standardmäßig zu blockieren; das zeigt, wie die Plattform die Entwicklung einschätzt.

Über diesem legitimen Crawler-Traffic liegt eine deutlich kleinere, aber aggressivere Schicht feindlicher Automatisierung: Scraper, Competitive-Intelligence-Bots und Stress-Test-Traffic. Diese respektieren robots.txt nicht, rotieren IPs aggressiv und fälschen legitime User-Agent-Strings. Sie können den Shop überlasten; auch legitime Crawler können zu viel Last erzeugen. Diese breitere Klasse unerwünschter Automatisierung zu stoppen, nicht nur die ?q=-Flut, ist ein eigenes Thema; den allgemeinen Ansatz behandeln wir in Bad Bots und unerwünschten Traffic blockieren.

Warum die naheliegenden Lösungen nicht funktionieren

Die meisten Ratschläge in Community-Foren fallen in einen von fünf Bereichen. Keiner davon reicht allein aus.

Das Modul für die Facettensuche deaktivieren. Entfernt die Oberfläche, lässt aber die URL-Angriffsfläche bestehen. Der Kategorie-Controller beantwortet ?q=-Anfragen weiterhin.

Eintrag Disallow: /*?q= in robots.txt. Googlebot hält sich weitgehend daran. Bingbot hält sich uneinheitlich daran. Es gibt öffentliche Berichte, dass er gesperrte Query-Muster trotzdem crawlt. KI-Crawler respektieren robots.txt je nach Betreiber in sehr unterschiedlichem Maß. Feindliche Scraper ignorieren die Datei komplett. Sinnvoll, aber nie ausreichend.

Eine pauschale .htaccess-Sperre für jede URL mit ?q=. Das erwischt die Bots, beschädigt aber auch Ihre eigenen AJAX-Filteranfragen (dasselbe URL-Muster, das Ihr Front Office nutzt, um Filterergebnisse ohne Neuladen der Seite abzurufen) und alle gespeicherten oder geteilten Filter-URLs echter Kunden. Der SEO-Schaden wird größer, wenn Google einige dieser Filterseiten als kanonische Seiten für Long-Tail-Suchanfragen indexiert hatte. Es gibt einen Platz für sauber abgestimmte Serverregeln, nur nicht für die Holzhammer-Variante; unsere PrestaShop-.htaccess-Regeln für Sicherheit und Performance behandeln die Regeln, die sich lohnen.

Bestimmte Bot-User-Agents blockieren. Ein Katz-und-Maus-Spiel. Jede Woche tauchen neue Bots auf, feindliche Bots fälschen UA-Strings, und legitime KI-Referrer (ChatGPT, Perplexity, Copilot), die einen wachsenden Anteil eingehender Klicks liefern, würden ebenfalls blockiert. Das Verhältnis von Crawl zu Klick ist bei KI-Bots weiterhin schwach, aber nicht null, Cloudflares eigene Daten zeigen, dass Referrals existieren.

Full-Page-Caching von ?q=-URLs. Rufen Crawler viele unterschiedliche Filterkombinationen kaum mehrfach ab, kann die Cache-Trefferquote niedrig sein. Das Speichern jeder neuen URL verursacht dann Schreibzugriffe, ohne viel Arbeit am Origin einzusparen. Messen Sie Wiederverwendung und Cache-Verhalten, bevor Sie sich auf diese Maßnahme verlassen.

Die verbleibende Option, und darum geht es im Rest dieses Beitrags, ist, die Entscheidung darüber, wer diese URLs aufrufen darf, vollständig vor PrestaShop zu treffen, wo sie günstig und ohne PHP-Start möglich ist.

Die richtige Lösung: eine Cloudflare Managed Challenge für das Muster der Facettensuche

Cloudflares Managed Challenge kann hier helfen: Sie prüft passende Anfragen vor PrestaShop und benötigt keine Liste bestimmter Bot-Namen. Manche Browser passieren ohne Interaktion; andere erhalten eine interaktive Prüfung oder scheitern daran. Eine Ausnahme für X-Requested-With: XMLHttpRequest kann AJAX-Filter erhalten. Dieser Header lässt sich jedoch leicht fälschen und beweist nicht, dass die Anfrage aus Ihrem Front Office stammt.

Verwenden Sie eine benutzerdefinierte Regel für GET-Anfragen mit q; eine Bot-Score-Bedingung kommt nur hinzu, wenn Ihr Abonnement Bot Management umfasst. Ein kostenpflichtiger Tarif allein gewährt keinen Zugriff auf cf.bot_management.score. Prüfen Sie vor Aktivierung beider Varianten die tatsächlichen Kategorie-Routen und alle weiteren Verwendungen von q. Beschränken Sie die Regel mit einer zusätzlichen and-Bedingung auf bestätigte Facetten-Kategoriepfade, wenn andere Routen den Parameter ebenfalls verwenden. Beginnen Sie mit einer kleinen, ausdrücklich festgelegten Auswahl dieser Pfade. Berücksichtigen Sie Shop-Basispfad, Sprachpräfixe sowie lokalisierte und eigene Modul-/API-Routen; die Ausschlüsse /module/ und /api/ erfassen nur diese Pfade im Stammverzeichnis.

Wenn Ihr Abonnement Bot Management umfasst

Verifizierte Bots innerhalb dieser Regel ausnehmen. Behalten Sie not cf.client.bot in der konkreten q-Regel. Überspringen Sie nicht pauschal alle nachfolgenden benutzerdefinierten Regeln: Andere Schutzmaßnahmen sollen auch für verifizierte Crawler gelten. cf.client.bot ist Cloudflares Einstufung als verifizierter Bot, keine Sicherheitsblockade und keine Garantie gegen Überlastung durch diesen Crawler.

Wahrscheinliche Automatisierung auf bestätigten Facetten-Routen prüfen. Kombinieren Sie die oben beschriebene Routenbegrenzung mit diesen logischen Bedingungen:

• http.request.method eq "GET"
• und len(http.request.uri.args["q"]) >= 0, die Anfrage enthält einen q-Parameter
• und not cf.client.bot. Es ist kein verifizierter Crawler
• und not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest"), die Anfrage trägt diese fälschbare AJAX-Kennung nicht
• und not starts_with(http.request.uri.path, "/module/")
• und not starts_with(http.request.uri.path, "/api/")
• und cf.bot_management.score gt 1 and cf.bot_management.score lt 30, der hier gewählte niedrige Score-Bereich für wahrscheinliche Automatisierung

Aktion: Managed Challenge. Die Regel erfasst passende GET-Anfragen mit q auf den gewählten Routen, ausgenommen verifizierte Bots, Anfragen mit AJAX-Kennung und die von Ihnen identifizierten Modul-/API-Pfade. Mit Bot Management muss zusätzlich der gewählte Score-Bereich zutreffen. Anfragen, die die Challenge bestehen oder nicht unter die Regel fallen, können den Origin weiterhin erreichen. Die Regel stoppt nicht jede Automatisierung.

Für cf.bot_management.score eq 1 können Sie eine Regel vor der Challenge-Regel ergänzen. Übernehmen Sie dieselbe Kategoriebegrenzung, GET-mit-q-Bedingungen sowie Ausnahmen für verifizierte Bots, AJAX, Module und APIs. Score 1 ist Cloudflares stärkste Einstufung als automatisierter Traffic, kein Nachweis einer schädlichen Absicht. Testen Sie Managed Challenge oder, bei vertretbaren Fehlalarmen, Block, bevor Sie den Geltungsbereich erweitern.

Wenn Sie kein Bot Management haben (auch Free und Pro)

Free und Pro unterstützen benutzerdefinierte Regeln und Managed Challenge, aber weder reguläre Ausdrücke noch die Regelaktion Log. Business unterstützt Regex, aber kein Log; Enterprise unterstützt beides. Siehe Cloudflares Tarifverfügbarkeit und Voraussetzungen der Operatoren. Die folgenden gemeinsamen Bedingungen verwenden keine Regex und setzen kein Kategorie-URL-Präfix voraus. Ergänzen Sie vor der Aktivierung die oben beschriebene Begrenzung auf tatsächliche Routen:

http.request.method eq "GET"
and len(http.request.uri.args["q"]) >= 0
and not cf.client.bot
and not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest")
and not starts_with(http.request.uri.path, "/module/")
and not starts_with(http.request.uri.path, "/api/")

Ohne Bot-Management-Berechtigung können Sie cf.bot_management.score nicht verwenden. Das in älteren Anleitungen empfohlene Feld cf.threat_score ist dauerhaft auf 0 gesetzt und kann riskante Anfragen nicht unterscheiden.

len(http.request.uri.args["q"]) >= 0 ist eine gültige Anwesenheitsprüfung: Fehlt der Map-Schlüssel, ergibt der Vergleich in Cloudflares Sprache false. Siehe das dokumentierte Verhalten fehlender Werte. Das beweist jedoch nicht, dass q ein Facettenparameter ist. Testen Sie leere und gefüllte Werte, Such-URLs sowie lokalisierte oder eigene Modul-/API-Routen. Im umgeschriebenen Pfad codierte Filter benötigen eine separate Bedingung anhand der tatsächlichen Shop-Routen.

Verwenden Sie nach den folgenden Prüfungen Managed Challenge für den passenden Traffic. Die Filter-URL bleibt erhalten, aber Kunden müssen eine mögliche Challenge erfolgreich abschließen können. Weder ein Ein-Klick-Durchgang noch eine feste Zahl von Netzwerk-Roundtrips ist garantiert. Testen Sie gespeicherte und geteilte Links in echten Browsern, auch mobil, sowie AJAX-Filter. Eine Challenge-Seite als AJAX-Antwort kann die Filteroberfläche beschädigen. Verifizierte Bots, Anfragen mit AJAX-Kennung und erfolgreiche Challenge-Teilnehmer können weiterhin Origin-Last verursachen.

Wichtige Einschränkungen, bevor Sie das aktivieren

Mit den Werkzeugen Ihres Tarifs testen. Bei Enterprise können Sie Log 24–48 Stunden lang nutzen und passende Ereignisse vor Aktivierung von Managed Challenge prüfen. Free, Pro und Business bieten die benutzerdefinierte Regelaktion Log nicht: Prüfen Sie zunächst verfügbare Daten in Security Analytics und Anfrageprotokollen. Testen Sie danach Managed Challenge kontrolliert auf einer kleinen Auswahl bestätigter Kategorie-Routen und beobachten Sie Security Events. Prüfen Sie auch legitime Such-, Modul-/API-, Sitemap- und Analyseanfragen. Erweitern Sie die Regel erst nach Prüfung auf Fehlalarme und Browserprobleme. Der Detailgrad von Analytics und Logs hängt vom Tarif ab; siehe Cloudflares Verfügbarkeitstabelle.

Die X-Requested-With-Ausnahme schützt die UX, ist aber keine Sicherheitsgrenze. Jeder HTTP-Client kann den Header senden und damit diese Regel einschließlich ihrer Bot-Score-Bedingung umgehen. AJAX-Clients, die ihn nicht senden, sind hingegen nicht ausgenommen. cf.client.bot klassifiziert verifizierte Bots, der Score schätzt Automatisierung ein; keines der Felder blockiert selbst etwas. Behalten Sie andere Schutzmaßnahmen bei und überwachen Sie die Last ausgenommener Anfragen, auch von verifizierten Crawlern.

Proxy für jeden öffentlichen Web-Hostnamen aktivieren (orange Cloud), aber Mail- und Nicht-HTTP-Records korrekt behandeln. Mail/MX und andere Nicht-HTTP-Records dürfen in der Regel nicht durch Cloudflare geproxyt werden, und der Orange-Cloud-Proxy kann Nicht-HTTP-Dienste nicht auf dieselbe Weise schützen. Das echte Risiko ist jeder DNS-only-Record (graue Cloud), Mail, Dev, eine Admin-Subdomain, der auf denselben Server wie der Shop zeigt, weil er die Web-Origin-IP offenlegt. Wer den Origin findet, kann Cloudflare vollständig umgehen und PrestaShop direkt treffen. Lassen Sie Mail und andere Nicht-HTTP-Records DNS-only, aber stellen Sie sicher, dass sie nicht auf die Web-Origin-IP zeigen oder sie verraten, legen Sie Mail, Dev und Admin auf separate IPs oder schränken Sie sie ein. Prüfen Sie Ihr DNS-Panel, bevor Sie der WAF vertrauen.

Origin auf Cloudflare-IPs beschränken. Selbst wenn alles geproxyt ist, blockieren Sie den Origin auf Firewall-Ebene hart so, dass HTTP/HTTPS nur von Cloudflares veröffentlichten IP-Bereichen akzeptiert wird. Sonst kann ein Angreifer, der die Origin-IP aus alten DNS-Historien lernt, sie direkt ansprechen. Während Sie den Origin-Zugriff beschränken, stellen Sie sicher, dass der Origin Ende-zu-Ende nur HTTPS verwendet, unsere Anleitung zum Einrichten von SSL und HTTPS in PrestaShop behandelt Zertifikate und Weiterleitungen, damit Edge und Origin übereinstimmen.

Wenn Sie auf KI-Such-Referrals angewiesen sind, beobachten Sie die Auswirkungen. Einige KI-Crawler helfen Diensten, Seiten für spätere Verlinkungen zu entdecken. Challenges können diese Entdeckung und möglicherweise Referrals beeinflussen, je nachdem, welche Crawler und Routen tatsächlich erfasst werden. Prüfen Sie nach einer Woche Ihre Analytics und vergleichen Sie nützliche Besuche mit der eingesparten Origin-Last; die Abwägung hängt vom Shop ab.

Der Fallback: ein Dispatcher-Override

Wenn Cloudflare heute nicht verfügbar ist, kann ein Dispatcher-Override in PHP ausgewählte Nicht-AJAX-?q=-Kategorieanfragen auf dieselbe Kategorie ohne Filter umleiten. Beschränken Sie ihn auf bestätigte Facetten-Kategorie-Routen. Eine shopweite Entfernung von q würde auch Such- oder Modul-/API-Parameter verwerfen.

Der Erweiterungspunkt ist override/classes/Dispatcher.php: Die Klasse erweitert DispatcherCore und überschreibt dispatch(). Ermitteln oder prüfen Sie zuerst ausdrücklich eine Kategorie-Route für den aktuellen Shop und die Sprache. Verarbeiten Sie nur GET-Anfragen mit einem Schlüssel q in der geparsten Query und ohne die getestete AJAX-Kennung (HTTP_X_REQUESTED_WITH, ohne Beachtung der Groß-/Kleinschreibung verglichen). Nehmen Sie Suche und sämtliche Modul-/API-Routen aus. Parsen Sie $_SERVER['REQUEST_URI'], entfernen Sie nur q und bauen Sie die Query mit http_build_query() unter Beibehaltung anderer Parameter neu auf. Das Ziel muss Kategoriepfad, Shop-Basispfad und Sprachpräfix erhalten und den konfigurierten Shop-Origin verwenden; Tools::getShopDomainSsl(true) allein liefert kein Shop-Unterverzeichnis. Vermeiden Sie Weiterleitungsschleifen. Senden Sie die gewählte Location-Antwort und exit; andernfalls rufen Sie parent::dispatch() auf.

Auf den gewählten Kategorie-Routen entfernt eine 301 den Filter dauerhaft aus direkten Links. Verwenden Sie sie nur, wenn diese Filter-URLs dauerhaft auf die ungefilterte Kategorie zeigen sollen. Testen Sie zunächst mit einer temporären Weiterleitung, bevor Sie eine cachebare permanente Weiterleitung einsetzen. Anfragen mit AJAX-Kennung bleiben ausgenommen, auch Bots, die sie kopieren. Prüfen Sie daher das Filterverhalten des tatsächlichen Themes, vorhandene Dispatcher-Overrides und Modulkompatibilität. Leeren Sie nach der Installation den Class-Index-Cache. Das spart Arbeit bei passenden Anfragen, verhindert aber weder den PHP-Start noch Zugriffe auf andere Endpunkte.

Drei Kompromisse sollten Sie verstehen, bevor Sie das ausrollen:

• SEO-Auswirkung. Die Weiterleitung einer Filter-URL auf eine ungefilterte Kategorie ändert das Ziel und kann Long-Tail-Rankings beeinflussen. Prüfen Sie vorab die Search Console. Erhalten Sie wertvolle Filterseiten oder ordnen Sie sie ausdrücklich passenden Landingpages zu; geringe Suchrelevanz aller Facetten-URLs darf nicht vorausgesetzt werden.
• Lesezeichen und geteilte Links. Im Geltungsbereich der Weiterleitung verlieren gespeicherte Links die Filteransicht. Die Cloudflare-Regel erhält die URL, wenn der Besucher eine mögliche Challenge besteht; eine zusätzlich aktive Weiterleitung entfernt den Filter trotzdem.
• Er hilft nur gegen Last auf PHP-Seite. Die Anfrage erreicht PHP weiterhin, sie beendet sich nur schnell mit einem 301, statt die komplette Kategorieseite auszuführen. Wenn Ihr Engpass die Anzahl der Verbindungen und nicht CPU ist, hilft das weniger als die Lösung auf Edge-Ebene.

Setzen Sie ihn als Übergangslösung ein. Wechseln Sie zu Cloudflare, sobald es möglich ist.

Edge versus Origin: Welche Lösung für welchen Engpass

Die beiden Abwehrmaßnahmen sind nicht austauschbar. Wählen Sie danach, wo Ihr Shop tatsächlich leidet.

Kombinieren Sie beide Maßnahmen nur, wenn der Verlust der Filteransicht über die ausgewählten Direktlinks akzeptabel ist. Der Override leitet auch dann um, wenn Cloudflare einen Besucher durchlässt, und ersetzt keinen Schutz vor dem gesamten Origin-Traffic.

Der architektonische Blick: Die URL-Fläche selbst ersetzen

Indexierbare Filterseiten sollten bewusst angelegte URLs sein, keine zufälligen Crawler-Kombinationen.

Beide Maßnahmen können unerwünschten Traffic auf der bestehenden URL-Fläche von ps_facetedsearch reduzieren. Keine ändert den großen öffentlichen Raum an Filterkombinationen, den das Modul bereitstellt.

Eine andere Klasse von Filtermodulen vermeidet das Problem an der Quelle: Der Filterzustand bleibt clientseitig (oder in einem einzelnen AJAX-POST), die öffentliche URL bleibt sauber, und nur bewusst kuratierte SEO-Landingpages, eine von Hand erstellte Seite für "Herren-Laufschuhe" statt jeder Marken-Farb-Größen-Kombination, werden indexierbar. Wir haben Filter Revolution in diesem Stil gebaut, teilweise als Reaktion auf genau die hier beschriebenen Traffic-Muster. Was bedeutet das also für Sie? Es verkleinert die öffentliche URL-Fläche mit hoher Kardinalität, die ps_facetedsearch für Crawler attraktiv macht. Das bedeutet weniger kombinatorische Seiten, die Bots entdecken können, und möglicherweise weniger Crawler-Last, konfiguriert aus dem Back Office, ohne Ihr Theme zu forken. Es ist kein magischer Schutzschild gegen KI-Crawler. Nichts ist das, und es entfernt nicht rückwirkend URLs aus dem Index, die Google und Bing bereits gefunden haben. Das kann die Entdeckung neuer Filterkombinationen reduzieren; bekannte URLs und AJAX-Endpunkte benötigen weiterhin geeignete Traffic-Kontrollen.

Wenn ohnehin eine Überarbeitung der Facettensuche ansteht, prüfen Sie den Austausch des Moduls. Passt das bestehende Modul zum Shop, pflegen Sie die Cloudflare-Regel weiter und prüfen Sie sie nach Änderungen an Routen, AJAX-Verhalten oder Traffic.

Eine letzte Sache: die leeren Warenkörbe

Ein GET-Aufruf einer Kategorieseite erzeugt im PrestaShop-Core nicht automatisch für jeden Besucher eine ps_cart-Zeile. Ob ein Warenkorb gespeichert wird, hängt vom Anfrageablauf, Theme und den Modulen ab und davon, ob diese einen Warenkorb anlegen oder speichern. Löst Automatisierung dieses Verhalten aus, können leere Warenkörbe anwachsen und Admin-Listen verlangsamen oder Abläufe für abgebrochene Warenkörbe verfälschen. Prüfen Sie die Ursache im eigenen Shop, bevor Sie jeden anonymen Warenkorb einem Bot zuschreiben.

Eine wirksame Edge-Regel kann neue Bot-Warenkörbe aus abgefangenem Traffic reduzieren. Sie garantiert weder einen vollständigen Wachstumsstopp noch bereinigt sie vorhandene Zeilen. Prüfen Sie installierte Bereinigungswerkzeuge und Aufbewahrungsregeln. Das Ausblenden bestätigter Bot-Warenkörbe in Zählern und Listen kann die Bedienbarkeit verbessern und Daten für Untersuchungen erhalten. Anonyme oder leere Warenkörbe allein beweisen keinen Bot-Ursprung. Falls eine Löschung nötig ist, bereinigen Sie kontrolliert mit Sicherung und schützen Sie legitime Warenkörbe sowie Bestellreferenzen. Führen Sie dies als eigene Aufgabe neben der Traffic-Abwehr durch.

Wo das in Ihre breitere Abwehr gehört

Die ?q=-Flut ist ein bestimmtes Fehlerbild, aber die Kontrollebene, die Sie zu ihrer Abwehr aufbauen, zahlt sich in der restlichen Sicherheitslage ebenfalls aus. Ein paar angrenzende Aufgaben, die sich lohnen, sobald die Edge-Regel steht:

• Blockierung pro Besucher und IP-Sperren. Wenn eine einzelne Quelle nach der Challenge weiter sondiert, brauchen Sie eine saubere Möglichkeit, sie abzuschneiden und zu sehen, wer Sie trifft, siehe zusätzliche Kundendaten und IP-Sperren.
• Formular-Spam, getrennt von Traffic-Fluten. Dieselbe Automatisierung, die Facetten crawlt, hämmert auch auf Kontakt- und Registrierungsformulare ein; eine Challenge beim Absenden ist dort die Antwort, siehe reCAPTCHA für PrestaShop.
• Wenn Sie den Core noch nicht aktualisieren können. Shops, die auf einer älteren PrestaShop-Version feststecken, haben weniger native Hebel; der Edge-und-Override-Ansatz hier ist Teil einer breiteren Virtual-Patching-Strategie in erweiterter Härtung für Shops, die Sie noch nicht aktualisieren können.
• Wenn das alles neu für Sie ist. Wenn die Begriffe oben viel auf einmal sind, beginnen Sie mit dem einfach verständlichen Leitfaden für Shopbetreiber und arbeiten Sie sich von dort aus weiter.

Häufig gestellte Fragen

Warum stoppt das Deaktivieren des Moduls für die Facettensuche die ?q=-Flut nicht?

Das Deaktivieren von ps_facetedsearch entfernt die Filteroberfläche und kann Filterberechnungen reduzieren. Bekannte URLs wie /category-slug?q=anything können PrestaShop aber weiterhin starten und den Kategorie-Controller erreichen. Automatisierte Clients werden nicht daran gehindert, diese URLs aufzurufen.

Behebt robots.txt Disallow die ?q=-Flut?

Es hilft, reicht allein aber nie aus. Disallow blockiert Crawling, nicht Indexierung, und entscheidend ist: Nur gut erzogene Crawler halten sich daran. Googlebot respektiert es weitgehend, Bingbot uneinheitlich, KI-Crawler variieren je nach Betreiber, und feindliche Scraper ignorieren es vollständig. Traffic, der robots.txt ignoriert, benötigt separate Schutzmaßnahmen; auch kooperative Crawler können erlaubte URLs überlasten. Sinnvoll, aber nie die ganze Antwort. Die Sitemap-Aufnahme hängt vom Sitemap-Modul und seiner Konfiguration oder URL-Richtlinie ab, nicht allein von der PrestaShop-Core-Version. Das Ausschließen unerwünschter Facetten-URLs kann deren Entdeckung reduzieren, stoppt aber keine Aufrufe bekannter URLs.

Warum nicht einfach jede URL mit ?q= in .htaccess blockieren?

Eine pauschale Sperre trifft auch legitime AJAX-Filter, gespeicherte Filter-URLs und andere Verwendungen von q, etwa Suche oder APIs. Eine eingegrenzte Managed Challenge-Regel kann unerwünschten Traffic reduzieren und die URLs erhalten. Ihre Ausnahmen für verifizierte Bots und die AJAX-Kennung lassen einen Teil der Automatisierung weiterhin durch. Testen Sie echte Filteranfragen und überwachen Sie die verbleibende Origin-Last.

Was ist die schnellste Lösung, wenn ich Cloudflare heute nicht ausrollen kann?

Ein getesteter override/classes/Dispatcher.php kann Nicht-AJAX-GET-Anfragen mit q auf ausdrücklich ermittelten Facetten-Kategorie-Routen umleiten. Erhalten Sie Shop-Basispfad, Sprachpräfix und andere Query-Parameter; nehmen Sie Suche und Modul-/API-Routen aus. Prüfen Sie Override-Kompatibilität und leeren Sie den Class-Index-Cache. Verwenden Sie 301 nur, wenn der dauerhafte Verlust dieser Filter-URLs beabsichtigt ist. PHP startet weiterhin, und Bots können die AJAX-Ausnahme nachahmen. Das ist eine begrenzte Übergangslösung, kein vollständiger Schutz vor der Flut.

Warum füllt diese Flut auch meine Warenkorb-Tabelle mit Tausenden leeren Warenkörben?

Das kann passieren, wenn Theme, Module oder Anfrageablauf bei automatisierten Besuchen Warenkörbe anlegen und speichern. Ein Kategorie-GET allein erzeugt im PrestaShop-Core nicht für jeden Besucher eine ps_cart-Zeile. Prüfen Sie, welche Komponente die Warenkörbe speichert. Edge-Filter können diesen Traffic reduzieren; vorhandene unerwünschte Zeilen brauchen eine getrennte, kontrollierte Bereinigung. Anonyme Warenkörbe sind nicht automatisch Bot-Warenkörbe.

Hören Sie auf, das Problem einzupacken, verkleinern Sie die Fläche

Sowohl die Cloudflare- als auch die Dispatcher-Lösung schützen die bestehende URL-Fläche mit hoher Kardinalität; sie entfernen sie nicht. Filter Revolution hält den Filterzustand clientseitig, damit die öffentliche URL sauber bleibt und nur bewusst kuratierte SEO-Landingpages indexierbar werden, von Anfang an weniger kombinatorische Seiten, die Crawler entdecken können. Neben der Edge-Regel reduziert Cleanup Revolution die Bot-Warenkorb-Verschmutzung, und Security Revolution deckt die breitere Härtung ab, von der diese Flut nur ein Teil ist.

Schnelle Checkliste

• Cloudflare für die Domain aktivieren. Jeden öffentlichen Web-Hostnamen proxyn (orange Cloud); Mail und andere Nicht-HTTP-Records DNS-only lassen und sicherstellen, dass sie nicht auf die Web-Origin-IP zeigen oder sie verraten.
• Die eingegrenzte q-Regel mit not cf.client.bot innerhalb der Regel anlegen. Enterprise: 24–48 Stunden mit Log beobachten. Free/Pro/Business: verfügbare Security-Analytics-Daten und Anfrageprotokolle prüfen, dann Managed Challenge auf wenigen bestätigten Kategorie-Routen testen und Security Events beobachten.
• Tatsächliche Kategorie-URLs, weitere Verwendungen von q, lokalisierte/eigene Modul- und API-Pfade sowie AJAX und gespeicherte Links in echten Browsern testen. Erwarteten Crawler-Zugriff bestätigen und verbleibenden Origin-Traffic messen.
• Nach Prüfung auf Fehlalarme kann Enterprise von Log auf Managed Challenge umstellen; unter Free/Pro/Business den kontrollierten Challenge-Test nur auf geprüfte Routen erweitern. Security Events und Origin-Last weiter beobachten.
• Origin-Firewall auf Cloudflare-IP-Bereiche beschränken. Das schließt den Kreis.
• Ist Cloudflare keine Option, einen auf Kategorien begrenzten Dispatcher-Override unter Beibehaltung des Shop-Basispfads und anderer Query-Parameter testen und die Migration planen.
• Wenn ohnehin eine Überarbeitung des Filtermoduls ansteht, den vollständigen Ersatz von ps_facetedsearch prüfen.
• Die Back-Office-Warenkorb-Verschmutzung separat bereinigen, damit die Warenkorb-Administration nutzbar bleibt.

Fazit

Filterkombinationen können ein DoS-Risiko erzeugen, wenn der Crawler-Traffic die Kapazität des Shops übersteigt. Das Risiko hängt vom installierten Filtermodul, den erreichbaren Routen, dem Traffic und den Ressourcen ab; es trifft nicht zwangsläufig jede PrestaShop-Installation. Prüfen Sie tatsächliche Anfragemuster und wählen Sie Maßnahmen, die legitime Nutzung erhalten.

Eine benutzerdefinierte Regel ohne Bot-Score ist in Cloudflare Free verfügbar. Sorgfältige Routenanalyse, Browsertests und laufende Überwachung erfordern trotzdem Arbeit. Eine abgestimmte WAF und ein abgeschirmter Origin bilden eine Grundlage für weitere Maßnahmen; Credential Stuffing, Scraping und Fake-Checkout-Traffic benötigen jeweils eigene Kontrollen.

Für den vollständigen mehrschichtigen Ansatz kehren Sie zur Checkliste zur PrestaShop-Sicherheits-Härtung zurück. Was passiert, wenn ein Shop durch etwas Anspruchsvolleres als Crawler-Missbrauch kompromittiert wird, zeigt die Anatomie eines Magecart-ähnlichen Angriffs auf einen PrestaShop-1.7.x-Shop. Das Abwehrkonzept hat in beiden Fällen dieselbe Form: günstige Kontrollen an der Edge, enge Ausnahmen nur dort, wo sie nötig sind, und absolut keine Sicherheitsbehauptungen, die auf User-Agent-Strings beruhen.