Vor allem Shops mit umfangreichen Produktfiltern sind hierfür sehr anfällig. Crawler und Bots rufen dort systematisch unzählige Filterkombinationen auf, wobei jede dieser Anfragen WordPress, WooCommerce und das Filter-Plugin voll beanspruchen können.
Kommen innerhalb kurzer Zeit sehr viele verschiedene Kombinationen zusammen, geraten CPU, Arbeitsspeicher, PHP-Prozesse und Datenbank an ihre Grenzen.
Für deine Besucher zeigt sich das durch sehr lange Ladezeiten, Timeouts oder Fehlermeldungen wie 503 Service Unavailable bzw. 524 Timeout.
In diesem Artikel erfährst du, woran du eine solche Überlastung erkennst, wie du die Ursache eingrenzt und welche Maßnahmen kurzfristig und dauerhaft helfen.
Voraussetzungen
Damit du das Problem angehen kannst, sind folgende Punkte wichtig:
Du besitzt einen WooCommerce-Shop mit Produktfiltern
Du hast Zugriff auf das Hosting Control Panel
Du bist eine robots.txt Datei (alternativ kannst du auch eine neue erstellen)
Du hast Zugriff auf unsere Serverseitigen Logs
bei technischen Anpassungen am Shop gegebenenfalls die Unterstützung durch eine Agentur oder einen Entwickler
Solltest du Fragen zu einen dieser Punkte haben, kannst du dich jederzeit bei unserem Support melden.
1. Typische Symptome erkennen
Eine Überlastung durch Crawler äußert sich selten durch einen einzelnen klaren Fehler, sondern vielmehr durch ein Muster. Achte dehare auf die folgende Anzeichen:
Der Shop wird plötzlich oder in Schüben sehr langsam, obwohl es keinerlei Updates oder großartige Änderungen gab.
Deine Kategorie- und Produktseiten laden ungewöhnlich lang.
Der Shop ist zeitweise gar nicht erreichbar und es treten 503- oder 524-Fehler auf.
Die CPU und RAM sind in der Ressourcenauslastung deutlich angestiegen.
Die Probleme treten zu bestimmten Uhrzeiten oder in regelmäßigen Abständen auf.
In den Logs finden sich sehr viele Anfragen auf unterschiedliche Filter-URLs. [BILD FOLGT]
Hinweis: Auch wenn ein Plugin in einer Fehlermeldung auftaucht, bedeutet das nicht, dass das Plugin auch wirklich hierfür verantwortlich ist. Bei Ressourcenmangel können Fehler an beliebigen Stellen in WordPress auftreten (mehr dazu in Abschnitt 8).
2. Ursache anhand der Serverlogs prüfen und eingrenzen
Ob Crawler oder Bots tatsächlich die Last verursachen, zeigen die serverseitigen Protokolle. Folgende Fragen helfen bei der Auswertung:
Welche URLs werden besonders häufig aufgerufen?
Von welchen IP-Adressen stammen die Anfragen?
Welche User-Agents werden verwendet?
Wie viele Anfragen gehen innerhalb eines bestimmten Zeitraums ein?
Handelt es sich überwiegend um Filter-URLs?
Werden immer wieder neue Kombinationen von Filterparametern abgefragt?
Besonders verdächtig ist es, wenn in kurzer Zeit sehr viele unterschiedliche URLs mit Filterparametern angefordert werden. Um das Live-Verhalten zu kontrollieren, kannst du oben links die Echtzeitaktualisierung starten.
Ein Beispiel: Ein Shop bietet Filter für Farbe, Größe, Material und Marke. Kombiniert man diese Filter miteinander, entsteht schnell eine fünf- oder sechsstellige Zahl möglicher URLs.
Dabei muss es sich nicht um einen gezielten Angriff handeln. Schon ein besonders aggressiver, aber „legitimer“ Crawler kann einen Shop in die Knie zwingen.
3. Warum Filter-URLs so problematisch sein können
Filter- und Facettennavigationen erzeugen URLs mit zusätzlichen Parametern. Je nach Filter-Plugin sehen sie zum Beispiel so aus:
website.de/shop/?filter_farbe=schwarz
website.de/shop/?filter_farbe=schwarz&filter_groesse=l
website.de/shop/?filter_farbe=schwarz&filter_groesse=l&filter_material=baumwolle
Für Besucher ist das komfortabel: Sie grenzen die Produktauswahl genau auf ihre Wünsche ein. Für einen Crawler dagegen entsteht daraus ein nahezu unendlicher Raum an URLs.
Mit jedem zusätzlichen Filter vervielfacht sich die Zahl der Kombinationen. Ruft ein Crawler diese URLs systematisch ab, muss der Server jedes Mal WordPress, WooCommerce und das Filter-Plugin ausführen.
Gefilterte Ansichten sind dabei meist deutlich rechenintensiver als ein normaler Seitenaufruf, weil die Datenbank aufwendige Abfragen über Produkte, Attribute und Taxonomien ausführen muss.
4. Warum Caching die Last nicht zuverlässig verhindert
Oft wird angenommen, dass ein aktives Caching-Plugin die Website bei solchen Zugriffen automatisch schützt. Das stimmt jedoch nur eingeschränkt.
Für den Cache ist jede URL mit einem anderen Parameter eine eigene Seite:
website.de/shop/?filter_farbe=schwarz
website.de/shop/?filter_farbe=blau
website.de/shop/?filter_farbe=schwarz&filter_groesse=l
website.de/shop/?filter_farbe=schwarz&filter_groesse=m
Ruft ein Bot ständig neue Kombinationen auf, existiert für die meisten dieser URLs noch kein Cache-Eintrag. Die Anfragen werden also an PHP und WordPress durchgereicht, und der Cache greift kaum.
Ein Cache entlastet den Server bei normalem Besucherverkehr sehr gut. Gegen eine große Menge dynamischer, ständig wechselnder Filteranfragen ist er jedoch kein zuverlässiger Schutz.
Da sich der Cache jedoch nach einer gewissen Zeit von selbst leert, baut sich der Cache jedes Mal neu auf.
5. Reguläre Crawler über die robots.txt steuern
Solltest du noch keine robots.txt dabei angelegt haben, wäre das dein erster Schritt. Hier kannst du nicht nur Crawler vollständig von deiner Seite ausschließen, sondern Suchmaschinen und anderen regulären Crawlern mitteilen, dass sie Filter-URLs nicht abrufen sollen.
Eine Anleitung zur robots.txt Datei findest du in folgendem Artikel: Crawler auf deiner WordPress-Seite | WPspace Help Center
Welche Regel du benötigst, hängt vom verwendeten Filter-Plugin und vom Aufbau der URLs ab. Die Regeln können hierbei z.B. folgendermaßen aussehen:
User-agent: *
Disallow: /*?*filter_
Disallow: /*?*min_price=
Disallow: /*?*max_price=
Disallow: /*?*orderby=
Prüfe immer anhand deiner tatsächlichen URLs bzw. der Logs, welche Parameter in deinem Shop verwendet werden, und passe die Regeln entsprechend an. Teste die Änderungen anschließend, damit du nicht versehentlich Seiten ausschließt, die in Suchmaschinen auffindbar bleiben sollten.
Wichtig: Die robots.txt ist keine technische Zugriffssperre, sondern lediglich eine "Bitte" an Crawler.
Seriöse Suchmaschinen wie Google und Co. halten sich daran.
Scraper, aggressive Bots und Angreifer ignorieren sie jedoch. Betrachte die robots.txt daher als vorbeugende Maßnahme für reguläre Crawler, nicht als Schutz vor gezielten Angriffen.
6. Filter-URLs im Shop selbst begrenzen
Neben der robots.txt lohnt es sich, die Filternavigation selbst anzupassen. Je nach Plugin und SEO-Konzept kommen unter anderem folgende Maßnahmen in Betracht:
Filterkombinationen nicht als eigenständige, crawlbare URLs ausgeben (zum Beispiel per AJAX ohne URL-Änderung)
Filterlinks mit rel="nofollow" versehen
gefilterte Ansichten mit einer passenden kanonische URL auf die Hauptkategorie verweisen lassen
irrelevante Filterkombinationen per noindex von der Indexierung ausschließen
unnötige und nicht genutzte Filter und Parameter entfernen
die Anzahl gleichzeitig kombinierbarer Filter begrenzen
Beachte dabei: noindex und Kanonische-Angaben funktionieren nur, wenn die Seite von Crawlern überhaupt aufgerufen werden darf. Wird dieselbe URL gleichzeitig per robots.txt gesperrt, kann der Crawler diese Hinweise nicht lesen. Sperre Filter-URLs daher gezielt und überlege, welches Ziel du erreichen möchtest (also z.B. die allgemeine Last zu reduzieren oder Indexierung die steuern).
Welche Variante sinnvoll ist, hängt stark vom Shopaufbau und den SEO-Zielen ab. Stimme die Änderungen am besten mit deiner Agentur oder einem Entwickler ab.
7. Sonderfall: Viele unterschiedliche IP-Adressen (Botnetz)
Besonders schwierig wird es, wenn die Anfragen nicht von einem einzelnen Crawler stammen. Bei einem Botnetz werden sehr viele verschiedene IP-Adressen genutzt. In den Logs wirkt das zunächst wie eine große Zahl normaler Besucher, welche jedoch im Sekundntakt auf deine Website zugreifen.
In den Protokollen kannst du auf folgende typische Merkmale achten:
Zugriff von sehr vielen unterschiedliche IP-Adressen innerhalb weniger Millisekunden
Sehr viele Anfragen in kurzer Zeit (aktiviere hierzu am besten die Echtzeitaktualisierung)
Wiederkehrende Aufrufe von Filter-URLs
Ständig neue bzw. unterschiedliche Filterkombinationen
Ein hoher Anteil automatisierter Anfragen (von Bots, Crawlern, …)
Fehlende oder ungewöhnliche Referrer (der Besucher gelangt durch das Anklicken eines bestimmten Links auf eine bestimmte Seite)
Deutlich erhöhte CPU & RAM in der Ressourcenauslastung
Einzelne IP-Adressen zu sperren bringt in diesem Fall wenig. Sobald die nächste Anfrage von einer anderen Adresse kommt, setzt der Bot seine Aktivität ungehindert fort.
8. Warum bei einer Überlastung scheinbar zufällige Plugins betroffen sind
Bei starker Ressourcenüberlastung meldet WordPress in der Oberfläche oder in den Logs manchmal Fehler bei ganz unterschiedlichen Plugins. Ein Plugin kann plötzlich als Verursacher eines „kritischen Fehlers“ erscheinen, obwohl es mit der eigentlichen Überlastung nichts zu tun hat.
Der Grund: Gehen PHP Arbeitsspeicher oder Rechenzeit aus, tritt der Fehler dort auf, wo der Prozess gerade ausgeführt wurde. Das ist oft reiner Zufall.
Ein Plugin, das während einer Überlastung in einer Fehlermeldung auftaucht, ist nicht automatisch die Ursache des Problems.
Bevor du Plugins deaktivierst oder umfangreiche Änderungen vornimmst, prüfe daher zuerst, ob gleichzeitig ungewöhnlich viele Anfragen eingehen.
9. Warum die robots.txt bei einem Botnetz nicht ausreicht
Ein Angreifer oder ein bösartiger Bot ist nicht an die Regeln der robots.txt gebunden. Gegen ein Botnetz bietet sie deshalb keinen Schutz.
Sinnvoll bleibt sie trotzdem: Reguläre Crawler werden davon abgehalten, unnötig viele Filter-URLs abzurufen, und der Anteil harmloser Zugriffe sinkt. Bei einem akuten Angriff sind zusätzlich Maßnahmen auf Serverebene erforderlich.
10. Ergänzend: Cloudflare
Cloudflare kann ein sinnvoller zusätzlicher Baustein sein. Es ersetzt aber nicht die Grundlagen aus den vorherigen Abschnitten: eine saubere Filterkonfiguration, passende robots.txt-Regeln und die Analyse der Logs. Richte Cloudflare in Ruhe ein, teste den Shop gründlich und ziehe bei Bedarf eine Agentur oder einen Cloudflare-Experten hinzu.
In folgendem Artikel findest du eine Schritt-für-Schritt Anleitung, wie du Cloudflare einrichtest: Cloudflare einrichten (Bot-Protection)
11. Staging- und Testumgebungen schützen
Ein gern übersehener Punkt sind öffentlich erreichbare Staging- oder Testumgebungen. Läuft eine Staging-Installation auf demselben Server wie der Live-Shop, teilen sich beide in der Regel dieselben Ressourcen. Wird die Testumgebung von Bots überlastet, kann das also auch den Live-Shop ausbremsen.
Wir empfehlen deshalb, jede öffentlich erreichbare Testumgebung mit einem Passwort zu schützen. Das verhindert gleichzeitig, dass Suchmaschinen die Staging-Seite indexieren.
Passwortschutz im WP Toolkit einrichten
Öffne auf der Serveroberfläche das WP Toolkit über den linken Menüpunkt Website & Domains
Wähle die Staging- bzw. Testinstallation aus.
Aktiviere den Passwortschutz.
Vergib einen Benutzernamen und ein ausreichend starkes Passwort.
(Gib die Zugangsdaten nur an Personen weiter, die tatsächlich Zugriff benötigen.)Lass den Passwortschutz für die Testumgebung dauerhaft aktiviert.
Hier erfährst du genau, wie du den Passwortschutz aktivierst: Passwortschutz aktivieren / deaktivieren | WPspace Help Center
Eine Staging-Umgebung sollte grundsätzlich nicht frei für Besucher oder Suchmaschinen erreichbar sein. Testumgebungen, die du nicht mehr benötigst, solltest du vollständig löschen.
Das solltest du bei einem akuten Ausfall tun
Ist dein Shop gerade nicht oder nur sehr langsam erreichbar und du siehst 503- oder Timeout-Fehler, führe zunächst keine umfangreichen Änderungen am System durch. Insbesondere solltest du nicht vorschnell:
Plugins deaktivieren
Themes wechseln
Datenbanken bereinigen
Caching-Einstellungen ändern
umfangreiche Updates einspielen
Solche Maßnahmen verschlechtern die Lage mitunter und verschleiern die eigentliche Ursache.
Klär stattdessen zuerst, woher die Last kommt. Anhand der Logs lässt sich meist schnell erkennen, ob die Last verursacht wird durch:
normale Besucher,
einen einzelnen Crawler,
viele verschiedene Bots,
Filter-URLs,
ein bestimmtes Plugin,
fehlerhafte Prozesse
oder etwas ganz anderes.
Bis die Ursache feststeht, kann es sinnvoll sein, den Shop vorübergehend in den Wartungsmodus zu versetzen, sofern der laufende Betrieb das zulässt. Auch hierfür gibt es auf der Serverseitigen Oberfläche die Option „Wartungsmodus“.
In folgendem Artikel wird dir genau erklärt, wie du den Modus aktivierst: Wartungsmodus aktivieren/deaktivieren | WPspace Help Center
Serverseitige Sperren bei akuter Überlastung
Sollten alle oben stehenden Maßnahmen keinen Erfolg bringen, kintaktiere bitte unseren Support. Schreibe uns hierfür bitte eine Mail an [email protected] oder kontaktiere und über den Live-Chat.
Stellen die Logs eindeutig fest, dass automatisierte Anfragen den Shop massiv belasten, können diese bereits auf Webserver-Ebene abgefangen werden. Sie erreichen dann WordPress und WooCommerce gar nicht erst und verbrauchen entsprechend weniger Ressourcen.
Hinweise auf solche Anfragen liefert häufig eine Kombination aus mehreren Merkmalen:
Filterparameter in der URL
fehlender Referrer
ungewöhnlicher oder leerer User-Agent
hohe Anfragezahl innerhalb kurzer Zeit
So lassen sich verdächtige Zugriffe blockieren, während normale Besucher den Shop weiter ungestört nutzen können.
Achtung bei direkten Filter-Links
Eine serverseitige Regel kann auch legitime Besucher treffen, wenn sie eine bereits gefilterte URL direkt aufrufen. Wenn sich ein Kunde zum Beispiel einen Link abgespeichert hat oder ein gefiltertes Produkt direkt über einen Newsletter verschickt wird, kann es zu Problemen kommen.
Weitere Beispiele:
Newsletter
Lesezeichen
Links auf externen Webseiten
Werbekampagnen (etwa Google Ads oder Social Media)
gespeicherte oder weitergeleitete Links
Verwendest du gefilterte URLs gezielt in solchen Kanälen, teile das dem Support mit, bevor entsprechende Regeln eingerichtet werden. So können Ausnahmen berücksichtigt werden.