Shop plötzlich nicht erreichbar oder „429 Too Many Requests“? Wenn automatisierter Bot-Traffic die Ursache ist

Gerade bei Online-Shops kommt es gelegentlich vor, dass die Website plötzlich nicht mehr erreichbar ist (Fehler 503 Service Unavailable) oder Besucher eine Meldung wie 429 Too Many Requests sehen. Ein häufiger Auslöser dafür ist automatisierter Zugriff durch Bots oder Crawler, die gezielt ressourcenintensive Funktionen wie Produktfilter, Suchfelder oder Warenkorb-Aktionen in kurzer Zeit sehr oft aufrufen.

Wie so eine Überlastung entsteht

Automatisierte Anfragen – oft von einer sehr großen Zahl unterschiedlicher IP-Adressen gleichzeitig – können bestimmte Funktionen deines Shops (insbesondere dynamische, datenbankintensive Funktionen wie Produktfilter) so stark belasten, dass der Server für reguläre Besucher nicht mehr rechtzeitig antworten kann. Das äußert sich zunächst als 503-Fehler. Sobald die serverseitige Schutzschicht eingreift und auffällige Zugriffsmuster über Rate-Limiting abfängt, kann dies für einzelne Besucher oder Systeme als 429-Fehler sichtbar werden.

Erste Schritte bei akuter Überlastung

• Aktiviere, falls verfügbar und noch nicht aktiv, das Sicherheits-Plugin bzw. die serverseitige Sicherheitsschicht (Imunify360) für deine Website – sie erkennt auffällige automatisierte Zugriffsmuster und bremst diese über Rate-Limiting ab.
• Lass deine eigene IP-Adresse vorsorglich auf die Whitelist setzen, damit du selbst während der Analyse uneingeschränkt auf deinen Shop zugreifen kannst.
• Wäge ab, ob ein kurzzeitiger Wartungsmodus sinnvoll ist – bedenke aber, dass er Bestellungen für echte Kunden vollständig blockiert. Oft ist ein aktives Rate-Limiting die verträglichere Sofortmaßnahme.

Nachhaltige Lösung

Da reines Rate-Limiting automatisierten Traffic zwar abbremst, aber die zugrunde liegende Ursache (stark frequentierte, ressourcenintensive Funktionen) nicht beseitigt, sind meist zusätzliche Schritte auf Caching- und Anwendungsebene sinnvoll, zum Beispiel:

• Caching für Produktfilter- und Suchergebnis-Seiten, soweit technisch möglich
• Feinjustierung der Bot-/Rate-Limits für spezifische, stark betroffene URL-Muster

Rechne nach Einleitung dieser Maßnahmen mit einer spürbaren Verbesserung für reguläre Nutzer typischerweise innerhalb weniger Tage, da zunächst Zugriffsmuster ausgewertet werden müssen, bevor die Feinjustierung erfolgen kann.

Sonderfall: Backend lädt extrem langsam, obwohl du nichts geändert hast

Bot-Traffic auf deine Produktfilter zeigt sich nicht immer als 503- oder 429-Fehler im Frontend. Häufig merkst du es zuerst im WordPress-Backend: /wp-admin lädt minutenlang oder gar nicht, während ein anderer Shop auf demselben Hosting-Paket normal funktioniert. Kurz darauf ist alles wieder schnell, dann wieder langsam. Plugins, Theme und Cache sind dabei oft gar nicht das Problem.

Woran du dieses Szenario erkennst

• Das Backend (und oft auch das Frontend) wird plötzlich sehr langsam, obwohl du in letzter Zeit keine Updates oder Änderungen gemacht hast.
• Die Langsamkeit kommt und geht über Stunden hinweg, ohne erkennbares Muster.
• In den Statistiken in Plesk siehst du ungewöhnlich viele Zugriffe und vereinzelte 503-Fehler.
• Im Zugriffsprotokoll tauchen sehr viele Anfragen an admin-ajax.php oder an deine Shop-Seite mit langen Filter-Parametern auf (z. B. ?filter_farbe=…&filter_groesse=…).
• Die Anfragen stammen nicht von einer einzelnen IP-Adresse, sondern von vielen verschiedenen, die sich wie normale Besucher verhalten.

Warum das passiert

Jede Kombination aus Filtern löst eine eigene, aufwendige Datenbankabfrage aus. Ein Seiten-Cache hilft dabei zunächst nicht, weil praktisch jede Filterkombination neu ist. Moderne KI-Crawler und Bots klicken sich systematisch durch diese Kombinationen und verteilen ihre Anfragen auf viele IP-Adressen. Eine einfache IP-Sperre greift deshalb nicht mehr. In der Summe erreicht dein Hosting-Paket seine Ressourcen-Limits (LVE), und alle Anfragen, auch deine eigenen im Backend, müssen warten.

Was du tun kannst

1. KI-Bot-Schutz prüfen: Öffne in deinem WordPress-Backend Imunify Security → Dashboard und prüfe, ob der Bot-Schutz für deine Website aktiv ist. Wenn der Bereich fehlt oder der Schutz nicht aktiv ist, bitte unseren Support, ihn für dich einzurichten.
2. Filter-URLs cachen lassen: Wenn dein Filter-Plugin die Filter als normale URLs mit Query-Strings lädt, kannst du diese Parameter in WP Rocket unter Einstellungen → WP Rocket → Erweiterte Regeln → Query-String(s) cachen eintragen (z. B. filter_farbe, filter_groesse). Häufig aufgerufene Filterkombinationen werden dann aus dem Cache ausgeliefert, statt jedes Mal neu berechnet zu werden. Trag nur die Filter-Parameter ein, keine Parameter für Warenkorb, Kasse oder Kundenkonto.
3. Filter-Logik optimieren lassen: Laufen die Filter ausschließlich über admin-ajax.php, greift das Query-String-Caching nicht. Bitte in diesem Fall deine Agentur oder deinen Entwickler, die Filter-Abfragen zu verschlanken (z. B. weniger kombinierbare Attribute, Filter-Indizes des Plugins nutzen, auf einen Filter mit eigener Index-Tabelle wechseln).
4. Fehlerprotokoll prüfen: Schau in Plesk unter Websites & Domains → Protokolle nach wiederkehrenden PHP-Warnungen, z. B. aus der functions.php deines Child-Themes. Solche Warnungen sind selten die Hauptursache, verlängern aber jede einzelne Anfrage und sollten von deinem Entwickler behoben werden.
5. Support mit den richtigen Infos kontaktieren: Nenne uns die betroffene Domain, seit wann das Problem besteht, ob ein anderer Shop auf demselben Paket normal läuft, und welches Filter-Plugin du einsetzt. Wir werten dann die Server-Logs aus und können den Bot-Traffic gezielt eingrenzen.

Wichtig: Eine reine Ressourcenerhöhung löst dieses Problem nicht dauerhaft. Solange jede Filterkombination teuer berechnet wird, wächst die Last einfach mit. Nachhaltig hilft nur die Kombination aus Bot-Schutz, Caching und schlanken Filter-Abfragen.

Wann du den Support kontaktieren solltest

Wende dich an den HostPress Support, sobald du wiederholt 503- oder 429-Fehler bemerkst oder Kunden dir melden, dass sie nicht bestellen können. Halte nach Möglichkeit bereit: den Zeitpunkt des ersten Auftretens, betroffene URLs oder Funktionen (z. B. Produktfilter) und deine aktuelle IP-Adresse für die Whitelist.