Statuscode 429 Too Many Requests
Was bedeutet HTTP 429 Too Many Requests?
HTTP 429 Too Many Requests ist eine Serverantwort, die eine vorübergehende Begrenzung der Anfragen signalisiert. Der Client hat innerhalb eines definierten Zeitraums mehr Requests gesendet, als das Rate Limit zulässt. Ein Retry-After-Header kann angeben, nach wie vielen Sekunden oder ab welchem Zeitpunkt ein neuer Versuch vorgesehen ist.
HTTP 429 Too Many Requests bedeutet auf Deutsch „zu viele Anfragen“ und gehört zur Klasse der 4xx-Statuscodes. Der Server ist grundsätzlich erreichbar, weist den Client aber wegen einer überschrittenen Anfragerate vorübergehend zurück. Das Limit kann sich auf eine IP-Adresse, einen API-Schlüssel, ein Benutzerkonto oder einen User-Agent beziehen.
So entsteht HTTP 429 Too Many Requests
HTTP 429 Too Many Requests wird durch Rate Limiting ausgelöst. Dabei zählt eine Anwendung Requests innerhalb eines Zeitfensters und lehnt weitere Zugriffe ab, sobald ein festgelegter Schwellenwert erreicht ist. Die Begrenzung schützt Server, APIs, Login-Bereiche und Shops vor Überlastung, automatisiertem Missbrauch oder ungewöhnlich vielen Abfragen.
Der Grenzwert ist nicht durch den HTTP-Standard festgelegt. Ein Anbieter kann beispielsweise zehn API-Aufrufe pro Minute erlauben, während eine andere Anwendung mehrere hundert Requests akzeptiert. Entscheidend sind die Konfiguration des Webservers, des Content Delivery Networks, der Web Application Firewall und möglicher Sicherheitsmodule.
Retry-After richtig auswerten
Der Response-Header Retry-After teilt dem Client mit, wann ein erneuter Request sinnvoll ist. Der Wert kann als Anzahl von Sekunden oder als konkretes HTTP-Datum angegeben werden. Fehlt der Header, muss der Client die Wartezeit selbst bestimmen und weitere Zugriffe vorsichtig staffeln.
Retry-After: 120 bedeutet, dass der Client 120 Sekunden warten soll. Ein automatisierter Prozess sollte nach Ablauf dieser Zeit nicht sofort wieder zahlreiche parallele Requests senden, sondern die Frequenz schrittweise erhöhen. Ein Exponential Backoff verlängert die Pause nach jedem weiteren Fehler. Ein Client kann beispielsweise nach dem ersten fehlgeschlagenen Versuch kurz warten und die Wartezeit bei jedem erneuten Statuscode 429 verdoppeln. Eine Obergrenze und zufällige Abweichungen verhindern, dass viele Clients exakt gleichzeitig erneut auf den Server zugreifen.
Folgen des Statuscodes für SEO
Ein einzelner Statuscode 429 verursacht normalerweise kein unmittelbares Rankingproblem. Wiederholte Antworten an Suchmaschinen-Crawler verhindern jedoch, dass Inhalte zuverlässig abgerufen, aktualisiert und bewertet werden. Die Suchmaschine kann ihre Crawl-Frequenz reduzieren, wenn eine Domain regelmäßig signalisiert, dass weitere Requests derzeit unerwünscht sind.
Bei großen Onlineshops und umfangreichen Unternehmensseiten trifft eine zu strenge Begrenzung häufig neue oder geänderte URLs zuerst. Produktaktualisierungen, neue Kategorien und geänderte Canonical Tags gelangen dann später in den Suchmaschinenindex. Bleibt eine indexierte URL über längere Zeit nicht abrufbar, kann auch ihre organische Auffindbarkeit beeinträchtigt werden.
HTTP 429 Too Many Requests betrifft auch GEO, also Generative Engine Optimization. Werden vertrauenswürdige KI-Crawler oder Systeme zur Quellenanalyse dauerhaft begrenzt, können sie aktuelle Inhalte seltener abrufen. Bei SEA entstehen direkte Auswirkungen, wenn echte Besucher nach einem Anzeigenklick eine 429-Antwort statt der Landingpage erhalten.
429-Antworten zuverlässig messen
Messbar ist das zum Beispiel so: Filtere Server-, CDN- und Firewall-Logs nach dem Statuscode 429 und gruppiere die Treffer nach URL, IP-Adresse, User-Agent und Zeitpunkt. So wird sichtbar, ob ein einzelner Bot, eine bestimmte Schnittstelle oder eine allgemeine Lastspitze das Limit auslöst. Ein Technik-Crawler für automatisierte SEO-Checks kann ergänzend prüfen, welche URLs beim Crawling nicht erreichbar sind.
Ein technisches SEO-Audit sollte außerdem klären, auf welcher Ebene der Statuscode erzeugt wird. Eine 429-Antwort kann bereits am CDN entstehen, obwohl der eigentliche Webserver ausreichend Kapazität besitzt. Prüfe deshalb Response-Header und Logs aller beteiligten Systeme, statt nur die Anwendung oder das CMS zu untersuchen.
Unterschied zwischen 429, 403 und 503
Der Unterschied zwischen den Statuscodes liegt in der Ursache der Ablehnung. HTTP 429 Too Many Requests bezeichnet eine überschrittene Anfragerate. Ein Statuscode 403 verweigert den Zugriff aufgrund einer Berechtigung oder Sicherheitsregel. Ein Statuscode 503 meldet, dass der Server den Request vorübergehend nicht bearbeiten kann, etwa wegen Wartung oder Überlastung.
| Statuscode | Bedeutung | Typische Ursache | Geeignete Reaktion |
|---|---|---|---|
| 429 | Anfragerate überschritten | Rate Limit für IP, Nutzer oder API | Retry-After beachten und Frequenz senken |
| 403 | Zugriff verweigert | Berechtigung, Firewall oder Sicherheitsregel | Freigaben und Zugriffsregeln prüfen |
| 503 | Dienst vorübergehend nicht verfügbar | Wartung, Überlastung oder Ausfall | Serverzustand prüfen und später erneut anfragen |
HTTP 429 Too Many Requests beheben
Die Behebung beginnt mit der betroffenen Systemebene. Prüfe zuerst, ob der Webserver, das CDN, eine Firewall, ein Sicherheits-Plugin oder die Anwendung selbst die Antwort erzeugt. Response-Header und Zeitstempel in den Logs helfen dabei, die auslösende Regel einem konkreten Request zuzuordnen.
Für technische Crawls können längere Pausen und eine geringere Parallelität erforderlich sein. Die Dokumentation der Performance Suite nennt als mögliche Ausgangswerte einen Abstand von 1.500 bis 3.000 Millisekunden sowie höchstens ein bis zwei gleichzeitige Verbindungen. Solche Werte sind keine allgemeingültigen Grenzwerte, sondern müssen an Serverleistung und Sicherheitskonfiguration angepasst werden.
Nach einer Anpassung sollte ein erneuter Crawl kontrollieren, ob betroffene URLs wieder einen Statuscode 200 liefern. Ein kostenloser SEO-Check kann zusätzliche technische Fehler auf ausgewählten Unterseiten aufdecken. Bei umfangreichen Websites sollte die Prüfung durch Logfile-Auswertungen und ein kontinuierliches technisches Monitoring ergänzt werden.
Häufige Fragen zu HTTP 429
Wie lange dauert ein Fehler 429?
Die Dauer hängt von der festgelegten Rate-Limit-Regel ab. Der Retry-After-Header kann die Wartezeit in Sekunden oder einen konkreten Zeitpunkt nennen. Ohne diese Angabe lässt sich die Dauer nicht zuverlässig aus dem Statuscode ableiten.
Ist der Statuscode 429 ein Serverfehler?
Nein. HTTP 429 gehört zur Klasse der 4xx-Statuscodes und kennzeichnet eine Anfrage, die wegen ihrer Häufigkeit zurückgewiesen wurde. Die auslösende Begrenzung wird dennoch auf der Server-, CDN-, Firewall- oder Anwendungsebene konfiguriert.
Kann Googlebot einen Statuscode 429 erhalten?
Ja. Eine Firewall oder ein Rate Limit kann auch Requests von Googlebot begrenzen. Wiederholte 429-Antworten können dazu führen, dass Google die Website vorsichtiger und seltener crawlt.
Was mache ich, wenn kein Retry-After-Header vorhanden ist?
Reduziere die Request-Frequenz und verlängere die Wartezeit nach jedem weiteren Fehler. Prüfe gleichzeitig die Server- und Firewall-Logs, um das konkrete Limit und die betroffene Komponente zu ermitteln.
Kann ein Browser den Fehler 429 verursachen?
Ein einzelner normaler Seitenaufruf löst den Fehler selten aus. Viele Aktualisierungen, automatisierte Browser-Erweiterungen oder mehrere Nutzer hinter derselben öffentlichen IP-Adresse können gemeinsam ein Limit überschreiten.
Sollte man Rate Limits für SEO-Crawler deaktivieren?
Eine vollständige Deaktivierung ist meist nicht erforderlich. Sinnvoller sind angemessene Grenzwerte, eine reduzierte Crawl-Geschwindigkeit und gezielte Ausnahmen für eindeutig identifizierte Crawler.
Wenn wiederkehrende 429-Antworten Crawling und Indexierung beeinträchtigen, sollte die technische Ursache über alle beteiligten Systeme hinweg geprüft werden.
Sie haben noch Fragen?
