Ein plötzlicher Rückgang bei Crawling und Indexierung wirkt oft wie ein SEO-Rätsel. In vielen Fällen steckt aber ein technisches Muster dahinter: Die Website liefert zu häufig „429 Too Many Requests“ aus. Das bedeutet, dass der Server oder ein vorgeschalteter Schutzdienst (z. B. WAF/CDN) Anfragen als „zu viele“ bewertet und blockiert oder drosselt. Für Nutzer:innen kann das nur einzelne Seiten treffen – für Suchmaschinen kann es aber dazu führen, dass wichtige Inhalte seltener oder gar nicht mehr gecrawlt werden.
Dieser Leitfaden erklärt verständlich, wie 429 entsteht, wie sich das Problem sicher diagnostizieren lässt und welche Maßnahmen in der Praxis am zuverlässigsten sind. Ziel ist eine Website, die Angriffe und Lastspitzen abfängt, ohne Suchmaschinen-Bots auszusperren.
Was ein 429-Statuscode für SEO praktisch bedeutet
429 kurz erklärt: Drosselung statt „echter“ Serverfehler
Der HTTP-Statuscode 429 Too Many Requests bedeutet: „Es kamen zu viele Anfragen in zu kurzer Zeit.“ Anders als ein 500er-Fehler ist das oft kein Defekt im Code, sondern eine bewusste Regel. Typische Auslöser sind Rate-Limits (Begrenzung pro IP, pro Minute) oder Sicherheitsmechanismen, die verdächtige Muster blocken.
Für SEO ist entscheidend, dass Suchmaschinen beim Crawling viele URLs abrufen. Wenn ein Bot regelmäßig an eine Grenze stößt, reduziert er seine Aktivität. Das kann dazu führen, dass neue Seiten später erscheinen, Updates länger brauchen oder einzelne Bereiche im Crawl „liegen bleiben“.
Welche Folgen möglich sind
- Wichtige Seiten werden seltener gecrawlt, Änderungen werden verspätet übernommen.
- Große Websites verlieren Tempo bei der Indexierung (z. B. Kategorien, Filterseiten, Blogs).
- Wenn 429 vermehrt auf zentrale URLs trifft (Startseite, Kategorien), können Rankings indirekt leiden, weil Google weniger zuverlässig auf aktuelle Inhalte zugreift.
Typische Ursachen: Warum Websites 429 auslösen
Zu strenge Limitierung auf Server-, Proxy- oder WAF-Ebene
Viele Setups begrenzen Requests pauschal pro IP. Das ist verständlich, kann aber Bots treffen, wenn Limits zu niedrig sind oder wenn viele legitime Anfragen über wenige IPs laufen. Besonders häufig ist das bei Konfigurationen in CDN/WAF-Produkten oder Reverse Proxies, die vorsorglich aggressiv drosseln.
Fehlkonfiguration bei Caching oder Bot-Schutz
Ein schlechter Cache kann die Last erhöhen: Jede Bot-Anfrage läuft dann bis zum Ursprung (Origin) durch, statt aus dem Cache beantwortet zu werden. Gleichzeitig können Bot-Schutz-Regeln (z. B. Challenge-Seiten, JavaScript-Prüfungen) aus Versehen auch Suchmaschinen treffen oder zusätzliche Requests auslösen.
Interne Auslöser: Crawling wird unnötig „aufgeblasen“
Auch ohne Angriffe kann eine Website sehr viele URLs erzeugen, die Bots anziehen: Parameter-URLs, Kalenderseiten, Filterkombinationen, interne Suche oder endlose Paginierungen. Je mehr unnötige URLs erreichbar sind, desto höher die Wahrscheinlichkeit, dass Limits erreicht werden.
Wer Parameter- und Filter-URLs im Griff behalten will, findet eine passende Vertiefung hier: Parameter-URLs sauber lösen.
Diagnose: So lässt sich 429 sauber nachweisen
In der Google Search Console nach Anzeichen suchen
In der Praxis zeigen sich 429-Probleme oft indirekt: Der Crawl wirkt schwankend, wichtige Seiten werden seltener abgerufen, oder es tauchen Meldungen zu Crawling-Problemen auf. Für eine solide Einordnung hilft eine strukturierte Analyse in der Google Search Console. Einen Überblick, wie die Daten sinnvoll gelesen werden, liefert: Search Console richtig nutzen.
Server-Logs prüfen: Welche URLs und welche Clients?
Die sicherste Quelle sind Logfiles. Dort steht, welche Requests tatsächlich 429 bekommen haben, von welchen User-Agents (Bots) und auf welchen URLs. Wichtig ist, Muster zu erkennen:
- Treffen 429 eher zufällig viele Seiten oder konzentriert es sich auf bestimmte Verzeichnisse?
- Ist es überwiegend ein Bot, ein Tool oder normale Nutzerlast?
- Gibt es Peaks zu bestimmten Uhrzeiten (z. B. Backups, Cronjobs, Feed-Reader)?
Wenn Logfile-Analysen neu sind, hilft der Praxisartikel: Logfile-SEO in der Praxis.
Abgrenzen: 429 vs. 503 und 5xx
429 ist eine „Drosselung“, 503 („Service Unavailable“) wird eher für geplante Wartung oder Überlast genutzt. Beide können Crawling beeinträchtigen, aber die Ursachen und Maßnahmen unterscheiden sich. Bei Wartungsszenarien ist dieser Leitfaden passend: SEO bei 503-Fehlern.
Konfiguration: Rate-Limits botfreundlich einstellen
Grenzen sinnvoll setzen statt pauschal blocken
Das Ziel ist nicht „kein Limit“, sondern ein Limit, das Angriffe abbremst, aber legitime Nutzung zulässt. Häufige Verbesserungen entstehen durch:
- Unterschiedliche Regeln je Endpoint (z. B. strenger für Login, lockerer für normale Seiten).
- Entkopplung von Bot- und Nutzertraffic (z. B. separate Regeln für bekannte Suchmaschinen-Bots).
- Statt harter Blocks eher „Soft Throttling“ (kurz drosseln), damit Crawling nicht komplett abreißt.
Bekannte Bots sauber erkennen (ohne Blind-Trust)
Viele Systeme whitelisten „Googlebot“ anhand des User-Agents. Das ist riskant, weil User-Agents leicht gefälscht werden können. Besser ist eine Prüfung über Reverse DNS bzw. verifizierte IP-Ranges, je nachdem, was die Infrastruktur erlaubt. Wenn Whitelisting genutzt wird, sollte es kontrolliert und dokumentiert passieren.
Retry-After nutzen, wenn 429 unvermeidbar ist
Wenn Drosselung in bestimmten Situationen nötig ist, hilft der Header „Retry-After“. Er signalisiert, wann erneut versucht werden soll. Das macht das Verhalten für Clients planbarer. Wichtig ist trotzdem: Ein dauerhaftes 429 auf wichtigen Seiten ist keine „saubere Lösung“, sondern ein Hinweis, dass Limits, Cache oder URL-Umfang angepasst werden müssen.
URL-Flut reduzieren: Weniger unnötige Requests, weniger 429
Filter, Suche und Parameter im Zaum halten
Wenn die interne Suche indexierbare Ergebnisse erzeugt oder Filterkombinationen massenhaft URLs bauen, kann Crawling ungewollt explodieren. Das Ergebnis sind hohe Request-Zahlen – und damit häufiger 429. Ein guter Start ist, die wichtigsten Bereiche sauber zu steuern:
- Interne Suche: Indexierung gezielt verhindern, wenn keine SEO-Landingpages geplant sind.
- Filterseiten: Nur die Kombinationen offen lassen, die echten Suchbedarf haben.
- Tracking-Parameter: Kanonisieren oder aus der Indexierung nehmen, damit Bots nicht Varianten abgrasen.
Für Shops ist das besonders relevant. Wer tiefer einsteigen will: Facettierte Navigation ohne Rankingverlust.
Interne Verlinkung entschlacken, damit Bots nicht in Sackgassen laufen
Eine unruhige interne Verlinkung (z. B. Tag-Wolken, Kalenderarchive, unendlich ähnliche Listen) verteilt Crawl-Aufmerksamkeit auf Nebenschauplätze. Das erhöht Last und kann Limits triggern. Sinnvoller ist eine klare Struktur mit priorisierten Links zu den wichtigsten Seiten. Dazu passt: Interne Verlinkung optimieren.
Performance als Schutz: Cache und Auslieferung stabilisieren
Warum Caching 429 indirekt verhindert
Viele 429-Fälle entstehen nicht durch „zu viele Bots“, sondern durch zu wenig Reserve. Wenn Seiten schnell und häufig aus dem Cache kommen, sinkt die Last am Origin deutlich. Dadurch müssen Rate-Limits weniger aggressiv sein. Sinnvoll sind:
- Server-/Proxy-Cache für HTML (wenn möglich) oder zumindest für statische Assets.
- Saubere Cache-Header und klare Regeln für Ausnahmen (z. B. Warenkorb).
- Monitoring: Wird der Cache getroffen (Hit) oder wird ständig durchgereicht (Miss)?
Wenn „Sicherheitsfeatures“ mehr Schaden als Schutz bringen
Manche Bot-Schutz-Mechanismen erzeugen zusätzliche Requests (z. B. Challenges, Redirects, mehrfaches Laden von Skripten). Das kann eine Situation verschärfen, die eigentlich entschärft werden sollte. In solchen Fällen hilft eine klare Trennung:
- Strenge Regeln für sensible Bereiche (Login, Admin, API).
- Unauffällige Regeln für normale Inhalte (Kategorie, Produkt, Artikel).
- Messung: Wie viele Requests entstehen pro Seitenaufruf wirklich?
Praktische Schritte für die Umsetzung
Kurzer Ablauf, der in der Praxis funktioniert
- Logs prüfen: Welche URLs, welche Zeiten, welche Clients bekommen 429?
- Betroffene Bereiche clustern: Inhalte, Suche, Filter, API, Login getrennt betrachten.
- Rate Limiting anpassen: pro Endpoint, pro Regel, mit realistischen Limits statt pauschaler Sperre.
- Cache verbessern: besonders für häufig gecrawlte HTML-Seiten und statische Dateien.
- URL-Flut eindämmen: Parameter, Filter, Suchseiten steuern und intern weniger „unnötig“ verlinken.
- Kontrolle: Crawling-Verlauf beobachten und erneut Logs prüfen, ob 429 signifikant sinkt.
Einordnen und priorisieren: Was ist dringend, was ist „nice to have“?
Je nach Website-Typ ist die Reihenfolge der Maßnahmen unterschiedlich. Die Tabelle hilft, typische Ursachen schnell zu sortieren und die nächsten Schritte zu wählen.
| Symptom | Wahrscheinliche Ursache | Erste sinnvolle Maßnahme |
|---|---|---|
| 429 fast nur auf /wp-login, /admin, /api | Angriffe oder zu strenge Schutzregel | Limits pro Endpoint getrennt setzen, sensible Bereiche härter schützen |
| 429 auf vielen Content-URLs (Kategorie/Artikel/Produkt) | Globales Limit zu niedrig oder Cache greift nicht | Cache-Hits prüfen, Limit lockern, Origin entlasten |
| 429 stark zu bestimmten Uhrzeiten | Jobs/Backups/Feeds/Importe erzeugen Lastspitzen | Zeitpläne entzerren, Last reduzieren, Limits temporär anpassen |
| 429 konzentriert auf Parameter- oder Filter-URLs | Zu viele URL-Varianten werden gecrawlt | Parameter/Filter steuern, interne Links bereinigen |
Häufige Fragen, die in Projekten immer wieder auftauchen
Ist 429 für Google „schlimmer“ als 404?
Es sind unterschiedliche Signale. Eine 404 sagt: „Diese Seite gibt es nicht.“ Ein 429 sagt: „Es gibt sie, aber gerade nicht für dich.“ Wenn 429 regelmäßig auf wichtigen Seiten passiert, bremst das Crawling. 404 ist nicht automatisch „besser“, aber oft leichter zu interpretieren. Bei 429 ist die Gefahr größer, dass wichtige Inhalte nicht zuverlässig abgerufen werden.
Sollte 429 lieber als 503 ausgeliefert werden?
Nur wenn tatsächlich eine Wartung oder temporäre Überlast kommuniziert werden soll. 429 passt, wenn es um Drosselung geht. 503 passt eher, wenn der Dienst kurzfristig nicht verfügbar ist. Entscheidend ist weniger der „bessere“ Code, sondern dass das Verhalten zur Realität passt und die Ursache behoben wird.
Kann ein hoher Crawl die Ursache sein, oder ist es immer ein Angriff?
Beides ist möglich. Viele Websites erzeugen unabsichtlich extrem viele URLs (Filter, Suche, Parameter). Dann reichen schon normale Bot-Aktivitäten, um Limits zu triggern. Erst Logfiles zeigen, ob es ein Angriff ist oder ein internes URL-/Caching-Problem.
Wie lässt sich prüfen, ob Googlebot betroffen ist?
Am zuverlässigsten über Logfiles: Dort steht, welche Requests 429 bekamen und welcher Client dahinterstand. Zusätzlich hilft es, Muster zu prüfen: Wenn 429 genau auf typischen Crawl-Pfaden auftaucht (z. B. Kategorie → Produkt → Paginierung), ist ein Bot-Einfluss plausibel. Wichtig ist, User-Agents nicht blind zu vertrauen.
Welche Rolle spielen Core Web Vitals dabei?
Core Web Vitals messen Nutzererlebnis, nicht Serverlimits. Trotzdem hängt beides indirekt zusammen: Schlechte Performance bedeutet oft höhere Serverarbeit pro Request, was Limits schneller auslöst. Wer gleichzeitig UX und Stabilität verbessern möchte, kann ergänzend hier weiterlesen: Core Web Vitals optimieren.
Saubere Zielsetzung: Schutz, aber ohne SEO-Bremse
Eine Website braucht Schutz vor Missbrauch und Lastspitzen. Gleichzeitig soll sie für Suchmaschinen zuverlässig erreichbar bleiben. Der Kern ist ein balanciertes Setup: Limits dort, wo es nötig ist, und genügend Spielraum dort, wo Inhalte gecrawlt werden. Besonders wirksam ist die Kombination aus besserem Cache, kontrollierter URL-Erzeugung und einer botfreundlichen Konfiguration der Schutzregeln.
