Glossar Fehler 429
Fehler 429 (Too Many Requests) ist der HTTP-Statuscode, mit dem ein Server einem Client antwortet, der in einer bestimmten Zeit zu viele Anfragen geschickt hat. Er betrifft diesen Client, nicht den ganzen Server. Die Antwort kann den Header Retry-After enthalten, der sagt, wie lange der Client vor dem nächsten Versuch warten soll.
Fehler 429: Der Server bremst einen Client mit zu vielen Anfragen. Warum Google ihn wie einen 5xx behandelt und wie du bremst, ohne URLs zu verlieren.
In den ersten Fassungen von HTTP gab es den 429 nicht. Eingeführt hat ihn RFC 6585, „Additional HTTP Status Codes“, den die IETF im April 2012 veröffentlichte, zusammen mit den Codes 428, 431 und 511. Das Verfahren dahinter heißt auf Englisch Rate Limiting: Der Server begrenzt, wie viele Anfragen er von jedem Client annimmt. RFC 9110 von 2022 definiert den 429 nicht neu, maßgeblich bleibt RFC 6585.
Eine Stelle zählt die Anfragen jedes Clients und antwortet ab dem Grenzwert mit 429 statt mit der Seite, bis die Wartezeit vorbei ist. Diese Stelle kann die Anwendung selbst sein, ein Gateway für eine API oder ein CDN mit Firewall.
Wie der Client erkannt und wie gezählt wird, lässt der RFC offen. Die Grenze kann je Ressource gelten, für den ganzen Server oder für eine Gruppe von Servern, und der Client lässt sich über Zugangsdaten oder ein Cookie erkennen. Laut MDN wird meist nach IP-Adresse begrenzt. Zwei weitere Regeln aus dem RFC: Eine 429-Antwort darf nicht im Cache landen, und der Server muss den Code nicht verwenden; bei einem Angriff kann es sinnvoller sein, die Verbindung zu kappen, als jede Anfrage zu beantworten.
Für Google ist der 429 die Ausnahme unter den Client-Fehlern. Die Google-Doku zu Statuscodes behandelt alle 4xx gleich, außer 429: Bei einem 404 oder 403 wird die URL nicht indexiert und, falls sie schon im Index war, entfernt. Ein 429 gilt dagegen als Zeichen für einen überlasteten Server, „it's considered a server error“. Deshalb wirkt er wie ein 5xx:
Google empfiehlt den 429 neben 500 und 503, um sein Crawling für einige Stunden oder ein, zwei Tage zu bremsen. 403 und 404 rät es dafür ab.
Für die robots.txt gelten eigene Regeln. Googles robots.txt-Doku behandelt jeden 4xx so, als gäbe es die Datei nicht, außer 429. Die Search-Console-Hilfe zur Crawling-Statistik führt „HTTP 429/5XX“ unter den erfolglosen Abrufen der robots.txt. Ein 429 an dieser Stelle zählt also als Verbindungsproblem.
Bei KI-Crawlern fehlt die Grundlage. Die Seiten von OpenAI, Anthropic und Perplexity zu ihren Crawlern, abgerufen am 12.11.2026, sagen nicht, wie diese auf einen 429 oder auf Retry-After reagieren. Anthropic unterstützt immerhin die Anweisung Crawl-delay in der robots.txt. Zum Steuern bleiben die robots.txt und, wenn du nicht vom guten Willen des Crawlers abhängen willst, die Sperre auf dem Server. Und Pay per Crawl antwortet mit einem 402 und verlangt eine Zahlung; mit dem 429 hat es nichts zu tun.
RFC 6585 nennt selbst dieses Beispiel, für eine Website, die angemeldeten Nutzern 50 Anfragen pro Stunde erlaubt:
HTTP/1.1 429 Too Many Requests Content-Type: text/html Retry-After: 3600
Die 3600 sind Sekunden, also eine Stunde.
Eine CDN-Regel gegen Scraper kann auch Googlebot treffen, wenn er in kurzer Zeit viele Filter-URLs crawlt. Antwortet die Regel mit 429, crawlt Google den ganzen Host langsamer. Antwortet sie mit 403, versteht Google, dass es diese URLs nicht gibt.
Den Code einer URL zeigt dir eine Anfrage im Terminal: curl -I https://www.example.com/. Die erste Zeile nennt den Code, darunter steht Retry-After, falls gesetzt. Hängt die Grenze von IP oder User-Agent ab, musst du von derselben Stelle aus testen wie der betroffene Client.
In der Google Search Console zeigt der Bericht zur Crawling-Statistik die Antworten, die Google bekommen hat, nach Typ und den Hoststatus mit der Verfügbarkeit der robots.txt. Die Server-Logs zeigen, wen die Grenze getroffen hat: welcher User-Agent, welche IP, wie viele Anfragen.
Der 429 sagt genau, was los ist: zu viele Anfragen, nicht eine fehlende Seite oder ein fehlendes Recht. Für Google heißt das, langsamer zu crawlen statt URLs zu entfernen, und mit Retry-After nennt der Server eine konkrete Wartezeit.
Der Preis ist ein gebremstes Crawling. Google warnt, dass es dann weniger neue Seiten findet und bestehende seltener aktualisiert, sodass Preise und Verfügbarkeit von Produkten später in der Suche erscheinen können. Bleibt der 429 mehrere Tage auf denselben URLs, können sie aus dem Index fallen. Und eine schlecht eingestellte Grenze je IP sperrt auch Menschen aus, die sich ein Netz teilen.
| Code | Was der Server sagt | Wofür er da ist |
|---|---|---|
| 429 Too Many Requests | Dieser Client hat zu viele Anfragen gestellt | Einen Client begrenzen; bei Google das Crawling bremsen |
| 503 Service Unavailable | Ich kann gerade niemanden bedienen | Wartung und Überlastung des ganzen Servers |
| 403 Forbidden | Ich verstehe die Anfrage, bediene sie aber nicht | Zugriff verweigern; bei Google wie ein 404, bremst das Crawling nicht |
Quelle: RFC 6585 (April 2012), Abschnitt 4; RFC 9110 (Juni 2022), Abschnitte 15.5.4 und 15.6.4; Googles Doku zu Statuscodes (abgerufen am 12.11.2026).
Wie lange ein absichtlicher 429 dauern darf, sagen Googles Quellen nicht einheitlich. Die Anleitung zum Senken der Crawling-Frequenz, aktualisiert am 6. Oktober 2026, rät, nicht länger als „1-2 days“ zu bleiben. Die Search-Console-Hilfe zur Crawling-Statistik, ohne sichtbares Datum, nennt „höchstens zwei oder drei Tage“. Zur Entfernung aus dem Index schreibt Googles Seite zu Crawling-Fehlern, aktualisiert am 18. Dezember 2025, dass 503 oder 429 über mehr als zwei Tage dazu führen, dass Google diese URLs entfernt („will cause Google to drop those URLs from the index“), während die Anleitung zum Senken der Crawl-Rate nur sagt, die URL könne nach mehreren Tagen herausfallen.
Der Blogbeitrag von Google aus dem Februar 2023, der die 429-Ausnahme bekannt machte, empfahl außerdem, das Tempo in der Search Console zu drosseln. Dieses Werkzeug wurde am 8. Januar 2024 abgeschaltet, wie Google im November 2023 ankündigte.
Einen Standard, um die Grenze vorher anzukündigen, gibt es auch nicht. Header wie X-RateLimit-Remaining sind Konventionen einzelner Dienste, und die RateLimit-Header der IETF sind im November 2026 noch ein Entwurf.
Dieser Eintrag entstand im November 2026 mit Unterstützung von KI. Die Angaben stammen aus RFC 6585 und RFC 9110, aus Googles Doku zu Statuscodes, Crawling-Frequenz, robots.txt und Überprüfung der Crawler, aus der Search-Console-Hilfe, aus dem Google-Blog, von MDN und aus der Doku von Cloudflare, OpenAI, Anthropic, Perplexity und der IETF. Er wurde vor der Veröffentlichung geprüft und enthält keine Kundendaten.
Eine technische Prüfung sieht sich das und alles Weitere in einem Durchgang an.
Audit anfragenSo lange, wie der Server festlegt. Schickt er Retry-After, ist das die Wartezeit, in Sekunden oder als Datum. Der RFC schreibt keine Dauer vor.
Zum Teil. Der Server hat zu viele Anfragen von deiner Verbindung, deinem Konto oder deinem Schlüssel gezählt. In einem geteilten Netz, etwa im Büro oder über ein VPN, können das auch andere gewesen sein.
Ja. Google empfiehlt ihn neben 500 und 503 für einige Stunden oder ein, zwei Tage. Das Crawling sinkt auf dem ganzen Host und steigt wieder, wenn die Fehler verschwinden.
Das ist nicht dokumentiert. Die Crawler-Seiten von OpenAI, Anthropic und Perplexity erwähnen den 429 nicht. Steuern lassen sie sich über die robots.txt und, ohne vom guten Willen des Crawlers abzuhängen, über eine Sperre auf dem Server.
Ein paar Minuten warten und es dann noch einmal versuchen, ohne die Aktion ständig zu wiederholen, denn jeder Versuch zählt mit. Bleibt der Fehler, liegt die Grenze beim Dienst, und nur dessen Support kann sie prüfen.