429 Zu viele Anfragen

TL;DR — Eine 429 Too Many Requests bedeutet, dass Ihr Server einem Besucher oder Bot sagt: „Sie fordern zu viele Seiten zu schnell an — bremsen Sie.“ Das nennt man Rate-Limiting. Für SEO ist 429 der eine Fehler dieser Familie, den Google schonend behandelt: Googlebot crawlt eine Weile langsamer, statt Seiten zu entfernen. Problematisch wird es erst bei 429s über mehrere Tage.

Was eine 429 tatsächlich aussagt

Jedes Mal, wenn ein Browser, Skript oder Suchmaschinen-Crawler Ihren Server nach einer Seite fragt, antwortet der Server mit einem Statuscode. 200 bedeutet „hier ist die Seite“. Eine 429 bedeutet: „Sie haben in kurzer Zeit zu viele Anfragen gestellt; versuchen Sie es später erneut.“

Server verwenden 429 absichtlich zum Selbstschutz. Eine gut behandelte 429-Antwort enthält auch einen Retry-After-Header, der dem Client sagt, wie viele Sekunden er warten soll. Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

Warum 429 der „freundliche“ SEO-Fehler ist

429 gehört zur Gruppe der „4xx-Clientfehler“, neben 403 Forbidden und 404 Not Found. Wenn Google 403 oder 404 immer wieder sieht, entfernt es die betreffenden Seiten schließlich aus der Suche.

429 ist die Ausnahme. Google liest sie als „Der Server ist beschäftigt, bremsen Sie“, wie bei einem 503- oder 500-Serverfehler. Google empfiehlt 429 ausdrücklich zum Drosseln von Crawlern und warnt davor, dafür 403 oder 404 zu verwenden. Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

Wann eine 429 zum Problem wird

Eine gelegentliche 429 ist normal und heilt von selbst. Sobald Ihr Server keine mehr sendet, beschleunigt Google das Crawling eigenständig wieder.

Wenn Googlebot dieselben Seiten länger als ein oder zwei Tage mit 429 sieht, kann Google sie aus dem Index entfernen, weil die Website dann tagelang defekt und nicht verfügbar wirkt. 429 ist ein kurzfristiges Werkzeug, keine dauerhafte Einstellung.

Was Sie dagegen tun sollten

• Wenn Sie 429s nicht absichtlich senden, suchen Sie nach zu aggressivem Rate-Limiting durch Sicherheits-Plugin, WAF, Hosting oder CDN und lockern Sie das Limit für echte Suchmaschinen. - Wenn Sie diese absichtlich senden, etwa bei hoher Serverlast, begrenzen Sie die Dauer und setzen Sie einen Retry-After-Header. Schalten Sie es innerhalb von ein oder zwei Tagen ab.

Möchten Sie die Serverkonfiguration, Googles genauen Wortlaut und verbreitete Mythen? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — 429 ist der einzige 4xx-Code, den Google wie einen 5xx behandelt: Eine erhebliche Zahl von 500/503/429-Antworten signalisiert Serverüberlastung, sodass Googlebot hostnameweit langsamer crawlt, statt Inhalte zu entfernen. Googles Notfallhinweis lautet „ein paar Stunden oder 1–2 Tage“ — kein garantiert sicheres Zeitfenster. Anhaltende 429s für dieselben URLs können zu ihrer Entfernung aus dem Index führen. RFC 6585 sagt, eine 429 SOLLTE die Bedingung erklären und DARF Retry-After enthalten; das ist empfohlene Praxis, keine Compliance-Pflicht. Begrenzen Sie den richtigen Datenverkehr und verifizieren Sie die Crawler-Identität.

Was 429 auf Protokollebene bedeutet

MDN formuliert die Spezifikation so: „Der HTTP-Statuscode 429 Too Many Requests für Clientfehler bedeutet, dass der Client in einer bestimmten Zeit zu viele Anfragen gesendet hat. Dieser Mechanismus wird allgemein Rate-Limiting genannt.“ Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

RFC 6585 §4 sagt, eine 429 SOLLTE die Bedingung erklären und DARF einen Retry-After-Header mit einer Wartezeit in Sekunden enthalten; RFC 9110 erlaubt auch ein HTTP-Datum. Die Spezifikation legt nicht fest, wie Clients identifiziert oder Anfragen gezählt werden. Eine 429 darf nicht von einem Cache gespeichert werden.

In meinem Leitfaden zu HTTP-Statuscodes und ihren SEO-Auswirkungen habe ich 429 als „eine Form von Rate-Limiting zum Schutz des Servers, weil der Client zu viele Anfragen zu schnell gesendet hat“ beschrieben. Nominell ist es ein Clientfehler; genau hier weicht die SEO-Einordnung von der Spezifikation ab.

Die eine Ausnahme unter den 4xx-Codes

Die wichtigste Tatsache: Google behandelt 429 nicht wie den Rest der 4xx-Familie. Gary Illyes schrieb im Februar 2023 darüber, weil Websites und CDNs 404s missbrauchten, um Googlebot zu drosseln.

429 bedeutet „zu viele Anfragen“ und signalisiert jedem gut erzogenen Roboter, einschließlich Googlebot, wegen Serverüberlastung langsamer zu werden. 401 und 403 sollen nicht zum Begrenzen der Crawl-Rate verwendet werden; 4xx-Codes außer 429 haben darauf keinen Einfluss.

Während 403 und 404 Inhalte aus der Suche entfernen, sorgt 429 für eine vorübergehende Verlangsamung. Google ordnet sie den Serverfehlern zu: „Googles Crawler behandeln 429 als Signal für einen überlasteten Server, und er gilt als Serverfehler.“ Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

429 ist das nützliche Geschwister von 503 Service Unavailable, dem traditionellen Wartungs- und Nichtverfügbarkeitssignal, und das Gegenteil von 403 Forbidden, dem falschen Werkzeug für Rate-Limiting.

Die Crawl-Rate wirkt hostnameweit — ab einem Schwellenwert

Wie Sie ein Limit pro IP, Sitzung, API-Key, Ressource oder Server zählen, ist Ihre Richtlinie; die HTTP-Spezifikation definiert es nicht. Googles Verhalten hängt vom Volumen ab: “Google’s crawling infrastructure reduces your site’s crawling rate when it encounters a significant number of URLs with 500, 503, or 429 HTTP response status codes.” (Übersetzung) „Googles Crawling-Infrastruktur reduziert die Crawl-Rate Ihrer Website, wenn sie auf eine erhebliche Anzahl von URLs mit den Statuscodes 500, 503 oder 429 trifft.“ Danach betrifft die reduzierte Rate den gesamten Hostnamen, nicht nur die Fehler-URLs, sondern auch URLs mit Inhalten. Das entspricht der dokumentierten Reichweite: “the reduced crawl rate affects the whole hostname of your site (for example, subdomain.example.com), both the crawling of the URLs that return errors, as well as the URLs that return content.” (Übersetzung) „Die reduzierte Crawl-Rate betrifft den gesamten Hostnamen Ihrer Website (zum Beispiel subdomain.example.com), sowohl die URLs mit Fehlern als auch die URLs, die Inhalte zurückgeben.“

Wenn Sie eine Teilmenge von Seiten bei echtem Volumen mit 429 beantworten, verlangsamt Googlebot das Crawling des gesamten Hostnamens, auch für Seiten mit 200. Eine einzelne 429 beweist diese Wirkung jedoch nicht; Googles Wortlaut bezieht sich auf „eine erhebliche Anzahl“ von Fehlerantworten. Evidence for this claim When Google encounters a significant number of 500, 503, or 429 responses, its documented crawl-rate reduction affects the whole hostname, including error URLs and URLs still returning content; one isolated 429 does not establish that site-wide effect. Scope: hostname crawl-load incidents Confidence: high · Verified: 2026-07-16 Reduce Google crawl rate

Die 1–2-Tage-Leitlinie — wann 429 riskant wird

429 ist ein kurzfristiges Signal, kein garantiert sicheres Zeitfenster. Aus den Google-Dokumenten: “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (Übersetzung) „Wenn Sie die Crawl-Rate dringend für kurze Zeit reduzieren müssen (beispielsweise ein paar Stunden oder 1–2 Tage), geben Sie bei den Crawl-Anfragen statt 200 den HTTP-Statuscode 500, 503 oder 429 zurück.“

Über diesen Zeitraum hinaus wird es riskanter: “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.” (Übersetzung) „Wir empfehlen nicht, dies über einen längeren Zeitraum zu tun (also länger als 1–2 Tage), weil sich dies negativ darauf auswirken kann, wie Ihre Website in Google-Produkten erscheint … wenn Googlebot diese Statuscodes mehrere Tage lang bei derselben URL beobachtet, kann die URL aus Googles Index entfernt werden.“ Die Statuscode-Referenz sagt für 5xx und 429 dasselbe: “already indexed URLs are preserved in the index, but eventually dropped.” (Übersetzung) „Bereits indexierte URLs bleiben im Index erhalten, werden aber schließlich entfernt.“

Kurzfristige 429s liegen im empfohlenen Notfallfenster; anhaltende 429s für dieselben URLs über mehrere Tage sind ein dokumentiertes Risiko, aber kein garantiertes Ergebnis. Es ist dieselbe Dynamik wie bei einer lang anhaltenden 503.

Die Crawl-Rate erholt sich automatisch

Sobald die Fehler zurückgehen, sagt Google: “the crawl rate will automatically start increasing again.” (Übersetzung) „Die Crawl-Rate beginnt automatisch wieder zu steigen.“ Es gibt keine Strafe und keinen erneuten Antrag. Die genaue Formulierung lautet “starts increasing,” (Übersetzung) „beginnt zu steigen,“ nicht “instantly returns to your prior rate.” (Übersetzung) „sofort zu Ihrer früheren Rate zurückkehrt.“ Der Zeitpunkt und das Endniveau sind nicht garantiert. Evidence for this claim Google says crawl rate automatically starts increasing after the number of overload responses falls; this describes direction, not an immediate return, fixed recovery time, or guaranteed prior crawl rate. Scope: hostname crawl-load incidents Confidence: high · Verified: 2026-07-16 Reduce Google crawl rate

Wenn das Ausliefern von Fehlern nicht praktikabel ist, nennt Google “file a special request to report a problem with unusually high crawl rate” (Übersetzung) „einen Sonderantrag stellen, um ein Problem mit ungewöhnlich hoher Crawl-Rate zu melden“; dieser manuelle Weg kann Tage dauern und ist nicht garantiert.

Wie Bing 429 behandelt

Es wird berichtet, dass Bingbot ähnlich reagiert — 429/500/503 signalisieren Überlastung und Bingbot fährt zurück. Den aktuellen Wortlaut konnte ich in Bings JS-gerenderten Hilfeseiten nicht unabhängig bestätigen. Behandeln Sie die Parität als Branchenbericht, nicht als aktuelle Bing-Verifikation.

• Crawl Control in den Bing Webmaster Tools legt Bingbots Anfragen pro Sekunde nach Tageszeit fest. - Die crawl-delay-Direktive in robots.txt. Die aktuelle Bing-Webmaster-Anleitung dokumentiert 1–20 Sekunden. Dies ist Bing-spezifisch und drosselt Googlebot nicht.

Bei Bing können Sie mit crawl-delay oder Crawl Control proaktiv drosseln, statt reaktiv Statuscodes einzusetzen. Google hat seinen manuellen Crawl-Rate-Schieberegler 2024 eingestellt.

Wann Sie absichtlich eine 429 senden würden

Legitime Gründe, absichtlich 429 zurückzugeben:

• Notfall bei der Serverlast — Verkehrsspitze, missglückte Migration oder Ausfall, bei dem Googlebot einige Stunden zurückfahren soll. - APIs und Nicht-HTML-Endpunkte schützen — Suchmaschinen-Crawler, SEO-Crawler von Drittanbietern (Ahrefs, Screaming Frog) und Scraper treffen auf Rate-Limits gegen Missbrauch.

Wofür 429 nicht gedacht ist: Bots dauerhaft zu blockieren. Wenn etwas nie gecrawlt werden soll, ist das eine robots.txt-Disallow-Aufgabe, keine 429. Wenn eine Seite erhalten, aber nicht indexiert werden soll, verwenden Sie noindex. 429 bedeutet „später“, nicht „nie“.

Unbeabsichtigte 429s — die üblichen Ursachen

Wenn 429s im GSC-Bericht zur Seitenindexierung oder in Crawl-Statistiken auftauchen, obwohl Sie diese nicht eingerichtet haben, behandeln Sie diese Kandidaten als Dinge, die Sie bestätigen oder ausschließen müssen, nicht als Diagnose:

• Fehlerhafte WAF-/Firewall-Regeln, die legitime Crawler-IP-Bereiche treffen. - Zu enge Standardlimits von Shared Hosting oder CDN für einen echten Crawl. - Bot-Management-Tools, die Googlebot oder Bingbot fälschlich als missbräuchlich einstufen. - Aggressive Rate-Limiting-Middleware, die Ihre eigenen Crawler erfasst.

Prüfen Sie vor jeder Regeländerung rohe Antwort-Header, exakte Logzeilen, Regel-ID, Client-Schlüssel (IP, Sitzung, API-Key), Route, CDN-PoP/Edge und Zeitfenster. So sehen Sie, welche Schicht die 429 ausgab. Verifizieren Sie die Crawler-Identität mit Reverse- und Forward-DNS, nicht allein per User-Agent — gefälschte „Googlebot“-User-Agents sind häufig. Im Tab Scripts stehen die Befehle.

Die Kurzfassung des Playbooks

1. Verwenden Sie 429 oder 503 mit Retry-After, um einen Crawler zu bremsen — niemals 403 oder 404. 2. Beschränken Sie es auf Stunden oder 1–2 Tage; Googles Dokumentation nennt “a couple of hours, or 1–2 days.” (Übersetzung) „ein paar Stunden oder 1–2 Tage“. 3. Die Drosselung gilt hostnameweit und erholt sich automatisch. 4. Begrenzen Sie das Limit auf den richtigen Datenverkehr und verifizieren Sie die Crawler-Identität. Googles Einordnung lautet: “server overloaded, slow down” (Übersetzung) „Server überlastet, langsamer werden“.

KI-Zusammenfassung

Eine verkürzte Fassung der Advanced-Version:

• 429 Too Many Requests bedeutet zu viele Anfragen zu schnell und ist nominell ein 4xx-Clientfehler. - Protokoll: RFC 6585 sagt, eine 429 SOLLTE die Bedingung erklären und DARF Retry-After enthalten; sie DARF NICHT von einem Cache gespeichert werden. - Ausnahme: Google behandelt 429 wie einen 5xx-Serverfehler und drosselt statt zu entfernen. Es liest dies als “server overloaded, slow down” (Übersetzung) „Server überlastet, langsamer werden“. - Google empfiehlt 429 sowie 500/503 zum Bremsen, niemals 403 oder 404. - Hostnameweit: Der ganze Hostname wird erst ab „einer erheblichen Anzahl“ gedrosselt; auch weiterhin 200 liefernde Seiten sind betroffen. - 1–2 Tage: Anhaltende 429s können dieselben URLs aus dem Index entfernen. - Erholung: Nach dem Ende der 429s beginnt die Crawl-Rate wieder zu steigen. - Wiederholungen: Gültiges Retry-After beachten; sonst begrenztes Backoff mit Jitter, Versuchslimit und Idempotenzprüfung verwenden. - Den Datenverkehr begrenzen und Crawler per Reverse-/Forward-DNS verifizieren. - Bing fährt Berichten zufolge ebenfalls zurück; crawl-delay und Crawl Control sind proaktive Alternativen. - 429 ≠ Block: Verwenden Sie robots.txt und noindex.

Offizielle Dokumentation

Primärquellen der Suchmaschinen und der HTTP-Spezifikation.

Google - Keine 403- oder 404-Codes für Rate-Limiting verwenden — Gary Illyes’ Beitrag vom Februar 2023. - Google-Crawl-Rate reduzieren — 500/503/429-Leitlinie, 1–2-Tage-Fenster, hostnameweite Drosselung und Erholung. - HTTP-Statuscodes, Netzwerk- und DNS-Fehler — Googles Behandlung der Codes; 429 wird den Serverfehlern zugeordnet (auch über den älteren Pfad search/docs/crawling-indexing/http-network-errors). - Google-Crawl-Rate reduzieren — Sonderantrag — manueller Weg bei ungewöhnlich hoher Crawl-Rate.

Bing / Microsoft - Crawl Control — Bingbots Anfragen-pro-Sekunde-Planer. - Bingbot-Anleitung — aktuelle Anleitung zu crawl-delay (1–20 Sekunden).

HTTP-Spezifikation - MDN — 429 Too Many Requests — Protokolldefinition, Retry-After und Rate-Limiting-Grundlagen.

Zitate aus der Quelle

Dokumentierte Aussagen von Google, Bing und der HTTP-Spezifikation. Jeder Link führt als Deep-Link direkt zur zitierten Passage auf der Quellseite.

Google — Gary Illyes, „Keine 403s oder 404s für Rate-Limiting verwenden“ (Februar 2023)

• “Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate.” (Übersetzung) „In den vergangenen Monaten haben wir festgestellt, dass immer mehr Websitebetreiber und einige Content Delivery Networks (CDNs) versuchen, 404 und andere 4xx-Clientfehler (aber nicht 429) zu verwenden, um die Crawl-Rate von Googlebot zu reduzieren.“ Zum Zitat springen
• “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (Übersetzung) „Die eine Ausnahme ist 429, was für ‚zu viele Anfragen‘ steht. Dieser Fehler ist für jeden gut erzogenen Roboter, einschließlich unseres geliebten Googlebot, ein klares Signal, langsamer zu werden, weil er den Server überlastet.“ Zum Zitat springen
• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (Übersetzung) „Alle 4xx-HTTP-Statuscodes (mit Ausnahme von 429) führen dazu, dass Ihre Inhalte aus der Google-Suche entfernt werden.“ Zum Zitat springen
• “Use Search Console to temporarily reduce crawl rate. Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (Übersetzung) „Verwenden Sie die Search Console, um die Crawl-Rate vorübergehend zu reduzieren. Geben Sie Googlebot beim zu schnellen Crawlen den HTTP-Statuscode 500, 503 oder 429 zurück.“ Zum Zitat springen

Google — Crawl-Rate reduzieren / Statuscode-Referenz

• “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (Übersetzung) „Wenn Sie die Crawl-Rate dringend für kurze Zeit reduzieren müssen (beispielsweise ein paar Stunden oder 1–2 Tage), geben Sie bei den Crawl-Anfragen statt 200 den HTTP-Statuscode 500, 503 oder 429 zurück.“ Zum Zitat springen
• “The reduced crawl rate affects the whole hostname of your site… Once the number of these errors is reduced, the crawl rate will automatically start increasing again.” (Übersetzung) „Die reduzierte Crawl-Rate betrifft den gesamten Hostnamen Ihrer Website … Sobald die Anzahl dieser Fehler sinkt, beginnt die Crawl-Rate automatisch wieder zu steigen.“ Zum Zitat springen
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days)… the URL may be dropped from Google’s index.” (Übersetzung) „Wir empfehlen nicht, dies länger als 1–2 Tage zu tun … die URL kann aus Googles Index entfernt werden.“ Zum Zitat springen
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (Übersetzung) „Googles Crawler behandeln den Statuscode 429 als Signal für einen überlasteten Server, und er gilt als Serverfehler.“ Zum Zitat springen
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (Übersetzung) „Verwenden Sie 401 und 403 nicht zur Begrenzung der Crawl-Rate. 4xx-Codes außer 429 haben keinen Einfluss auf die Crawl-Rate.“ Zum Zitat springen

MDN — die Protokolldefinition

• “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting’.” (Übersetzung) „Der HTTP-Statuscode 429 Too Many Requests für Clientfehler bedeutet, dass der Client in einer bestimmten Zeit zu viele Anfragen gesendet hat. Dieser Mechanismus wird allgemein Rate-Limiting genannt.“ Zum Zitat springen

Bing — aktuelle Webmaster-Anleitung

• Die Bingbot-Anleitung dokumentiert crawl-delay-Werte von 1–20 Sekunden. Behandeln Sie dies als Bing-spezifische Anleitung und nicht als allgemeine Crawler-Drosselung.

Branchenbelege für Googles Aussage

• Der Illyes-Beitrag vom Februar 2023 wurde von Search Engine Land, Search Engine Roundtable und Search Engine Journal aufgegriffen — alle drei stellen 429 als „die eine Ausnahme“ dar. Diese Berichte behandeln denselben Google-Beitrag; die Primärquelle ist der oben zitierte Illyes-Blogbeitrag.

Eine korrekte 429 senden — mit Retry-After

Der wichtigste Bestandteil einer gut behandelten 429 ist der Retry-After-Header. Er teilt jedem konformen Client — auch Googlebot — mit, wie lange er warten soll. Er kann Sekunden oder ein HTTP-Datum enthalten:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
Content-Type: text/html

<html><body>Too many requests. Please retry later.</body></html>

HTTP/1.1 429 Too Many Requests
Retry-After: Wed, 01 Jul 2026 12:00:00 GMT

Das Weglassen von Retry-After verletzt die Compliance nicht, aber ihn einzuschließen ist Best Practice und gibt Crawlern ein konkretes Signal zum Zurückfahren.

nginx — Rate-Limiting mit 429-Antwort

Standardmäßig gibt nginx mit limit_req den Status 503 zurück. Für crawlerfreundliche Semantik überschreiben Sie dies mit 429 und fügen Sie einen Retry-After-Header hinzu. Dieses Beispiel erlaubt 10 Anfragen pro Sekunde und IP mit einem kleinen Burst:

# In the http {} block: define a shared memory zone keyed by client IP
limit_req_zone $binary_remote_addr zone=crawl_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=crawl_limit burst=20 nodelay;

        # Return 429 (not the default 503) when the limit is exceeded
        limit_req_status 429;
    }

    # Attach a Retry-After header to 429 responses
    error_page 429 = @too_many;
    location @too_many {
        add_header Retry-After 3600 always;
        return 429;
    }
}

Apache — Rate-Limiting mit mod_ratelimit / mod_evasive

Apaches mod_ratelimit begrenzt standardmäßig die Bandbreite, nicht die Anzahl der Anfragen; für Rate-Limiting greifen Sie typischerweise zu mod_evasive oder einer WAF. Damit eine gedrosselte Antwort 429 mit Retry-After zurückgibt, setzen Sie dies ausdrücklich:

# Send a 429 with Retry-After for a chosen condition (e.g. a rate-limit env var)
<If "%{ENV:RATE_LIMITED} == '1'">
    Header always set Retry-After "3600"
    Redirect 429 /
</If>

# mod_evasive: throttle abusive request bursts (returns 429 in recent versions;
# older builds default to 403 — override where possible)
<IfModule mod_evasive20.c>
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSBlockingPeriod   60
</IfModule>

Beachten Sie den Vorbehalt: Ältere mod_evasive-Builds setzen die Blockantwort standardmäßig auf 403 — genau den Code, den Google nicht für Rate-Limiting verwenden will. Bestätigen Sie, dass Ihr Build 429 zurückgibt oder schalten Sie ein CDN/eine WAF davor.

Cloudflare / CDN — Rate-Limit auf 429

Legen Sie auf der CDN-Schicht die Aktionsantwort Ihrer Rate-Limit-Regel auf 429 fest; viele Voreinstellungen verwenden 403 oder eine Challenge. In Cloudflares Regeln ist der Antwortstatus konfigurierbar — wählen Sie 429 und fügen Sie, sofern unterstützt, Retry-After hinzu. Dasselbe gilt für Fastly, Akamai oder ein API-Gateway: Die Aktion bei überschrittenem Limit sollte 429 Too Many Requests sein, nicht 403 Forbidden.

Clientseitig: Nach einer 429 ohne Formel erneut versuchen

Der RFC gibt eine harte Regel, aber keinen Fallback-Algorithmus vor: Respektieren Sie einen gültigen Retry-After, wenn er vorhanden ist. Fehlt er, schreibt RFC 6585 weder Intervall, Backoff-Formel, Jitter, Versuchszahl noch Erfolgsbedingung vor. Stellen Sie keine einzelne Formel als HTTP-Gesetz dar; sie ist nur ein vernünftiger begrenzter Standard.

on 429 response:
    if Retry-After header present and valid:
        wait = parse(Retry-After)          # seconds or HTTP-date
    else:
        wait = min(cap, base * 2^attempt) + random_jitter(0, jitter_window)

    if attempt >= max_attempts or wait > cap:
        stop and surface the failure        # don't retry forever
    if request is not idempotent (e.g. a POST that isn't safe to repeat):
        confirm idempotency (idempotency key, or a safe no-op check) before retrying
    sleep(wait)
    attempt += 1
    retry request

Wichtig sind eine Obergrenze für gesamte Wartezeit und Versuchsanzahl, Jitter gegen synchronisierte Wiederholungen und eine Idempotenzprüfung, bevor etwas unsicher Wiederholbares erneut gesendet wird; ein nicht idempotentes POST braucht einen Deduplizierungsschlüssel.

Einen Bot als echten Googlebot verifizieren, bevor Sie ihn ausnehmen

Wenn Sie Rate-Limit-Ausnahmen für Suchmaschinen schreiben, bestätigen Sie die Identität mit Reverse- und Forward-DNS — gefälschte „Googlebot“-User-Agents sind häufig, und der UA-String allein beweist nichts.

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Wenn die Reverse-Suche nicht auf einer Google-Domain endet oder die Forward-Suche nicht zur ursprünglichen IP passt, ist es nicht Googlebot. Sie können außerdem mit Googles veröffentlichten IP-Bereichen abgleichen (googlebot.json).

Häufige Mythen über 429 und SEO

Mythos: „Jede 429 schadet meiner SEO oder führt zur Deindexierung.“ Nein. Google hat 429 als sicheres, erwartbares Drosselungssignal entwickelt. Kurzfristige oder gelegentliche 429s sind normal und korrigieren sich selbst; das Risiko entsteht erst bei anhaltenden 429s für dieselben URLs über mehrere Tage.

Mythos: „429 und 503 sind für SEO austauschbar.“ Für die Crawl-Rate behandelt Google sie ähnlich, aber sie bedeuten Unterschiedliches: 503 Service Unavailable signalisiert vorübergehende Nichtverfügbarkeit oder Wartung, 429 eine Überlastung durch Rate oder Menge. Der semantisch richtige Code ist für Überwachung und Werkzeuge wichtig.

Mythos: „Man kann Googlebot mit 403 oder 404 genauso bremsen wie mit 429.“ Illyes widerlegte dies 2023 direkt. 403/404 haben keinen Einfluss auf die Crawl-Rate und entfernen Inhalte aus dem Index. 429 ist der einzige 4xx-Code, der drosselt.

Mythos: „Rate-Limiting von Such-Bots kürzt das Crawl-Budget dauerhaft.“ Die Reduzierung ist vorübergehend und erholt sich automatisch, sobald das Fehlervolumen sinkt; Googles Dokumentation sagt, die Crawl-Rate beginnt wieder zu steigen.

Mythos: „Wenn Googlebot eine 429 erhält, gibt er die URL für immer auf.“ Google versucht es später erneut. Die Sorge gilt anhaltenden 429s über mehrere Tage, nicht einer gelegentlichen Begrenzung.

Häufig gestellte Fragen

Schadet ein 429-Fehler meiner SEO? Nicht von selbst. Kurzfristige oder gelegentliche 429s verlangsamen Googlebot nur vorübergehend und heilen von selbst. Das Risiko entsteht erst, wenn dieselben URLs mehrere Tage lang 429 zurückgeben.

Wie lange kann ich 429 zurückgeben, bevor Google meine Seiten deindexiert? Googles Dokumentation nennt “a couple of hours, or 1–2 days.” (Übersetzung) „ein paar Stunden oder 1–2 Tage.“ Darüber hinaus gilt: “the URL may be dropped from Google’s index.” (Übersetzung) „die URL kann aus Googles Index entfernt werden.“ Behandeln Sie 1–2 Tage als Obergrenze, nicht als Ziel.

Was ist der SEO-Unterschied zwischen 429 und 503? Google drosselt bei beiden ähnlich. 503 bedeutet „vorübergehend nicht verfügbar / Wartung“, 429 bedeutet „zu viele Anfragen“. Verwenden Sie den semantisch richtigen Code.

Soll ich Googlebot mit 429 blockieren, wenn er dauerhaft weniger crawlen soll? Nein — 429 ist kurzfristig. Für dauerhafte Reduzierung nennt Google einen Sonderantrag; verwenden Sie robots.txt zum Aussperren und noindex zum Entfernen aus dem Index.

Respektiert Bingbot 429 genauso wie Googlebot? Bingbot fährt bei Überlastungssignalen wie 429/500/503 ebenfalls zurück. Bing bietet zusätzlich crawl-delay und ein Crawl-Control-Raster in den Webmaster Tools.

Was ist der Retry-After-Header und brauche ich ihn? Retry-After teilt dem Client Sekunden oder ein HTTP-Datum bis zum nächsten Versuch mit. Er ist nicht zwingend, aber Best Practice.

Nimmt Google normales Crawling wieder auf, wenn ich keine 429 mehr zurückgebe? Ja, automatisch. Sobald das Fehlervolumen sinkt, “the crawl rate will automatically start increasing again.” (Übersetzung) „Die Crawl-Rate beginnt automatisch wieder zu steigen.“ Keine erneute Anfrage und keine bleibende Strafe.

Können WAF- oder CDN-Tools Googlebot versehentlich mit 429 beantworten? Sehr häufig. Firewall-Regeln, Standardlimits und Bot-Management können Googlebot oder Bingbot falsch einstufen. Verifizieren Sie die Crawler-Identität per Reverse-/Forward-DNS.

Ist 429 ein Client- oder ein Serverfehler? Technisch ist es ein 4xx-Clientfehler. Für das Crawling behandelt Google ihn als Serverfehler — den einen 4xx-Code, der den 5xx zugeordnet wird.

Was soll mein Client bei einer 429 ohne Retry-After-Header tun? Es gibt keine HTTP-Formel. Verwenden Sie begrenztes exponentielles Backoff mit Jitter, eine harte Obergrenze für Wartezeit und Versuche sowie eine Idempotenzprüfung.

Was soll ich bei einer 429 tun?

Häufige 429-Probleme

Googlebot erhält 429, normale Besucher jedoch nicht

Symptom: Crawler-Berichte zeigen 429, Browserprüfungen 200. Wahrscheinliche Ursache: Bot-Management, UA-Regel oder IP-basiertes Rate-Limiting. Behebung: WAF-Ereignisse mit verifizierten Crawler-IPs abgleichen und die verantwortliche Regel eingrenzen; keinen User-Agent allein erlauben.

Die Crawl-Rate des gesamten Hostnamens sinkt

Symptom: Das Crawling wird auch außerhalb der 429-URLs langsamer. Wahrscheinliche Ursache: Google wendet das Überlastungssignal hostnameweit an. Behebung: Unbeabsichtigte 429s stoppen, stabile Antworten wiederherstellen und die automatische Erholung abwarten.

429-Antworten bleiben nach dem Vorfall bestehen

Symptom: Der Server ist gesund, URLs geben aber weiterhin 429 zurück. Wahrscheinliche Ursache: CDN-Cache, Edge-Regel oder Limiter-Zustand. Behebung: Temporäre Regel deaktivieren oder ablaufen lassen, falsch gecachte Antworten löschen und repräsentative Pfade und Regionen prüfen.

Retry-After fehlt oder ist unbrauchbar

Symptom: Clients wissen, dass sie begrenzt wurden, aber nicht, wann sie es erneut versuchen sollen. Wahrscheinliche Ursache: Generische Sicherheitsregel. Behebung: Die ausstellende Schicht einen gültigen Delay oder ein HTTP-Datum senden lassen und den rohen Header testen.

Prompt: Eine Rate-Limit-Regel prüfen

Review this 429 rate-limit configuration for search-crawler safety. Identify its key,
scope, threshold source, Retry-After behavior, hostname-wide SEO impact, and any
user-agent-only exceptions. Separate deliberate short-term overload protection from
permanent crawl control. Return a minimal safe revision, test matrix, monitoring
signals, and rollback conditions. Do not invent provider syntax.

[PASTE CONFIGURATION AND SANITIZED SAMPLE LOGS]

Prompt: Ungeklärte 429s diagnostizieren

Use these headers, access-log rows, WAF events, and timestamps to determine which
layer generated the 429 and which traffic dimension triggered it. Give competing
hypotheses ranked by evidence, the next exact check for each, and a fix that does not
trust claimed crawler user agents. Do not infer missing logs.

[PASTE EVIDENCE]

Werkzeuge zum Untersuchen von 429s

• Bulk HTTP Status Code Checker: Repräsentative URLs testen und exportieren, welche Pfade 429 zurückgeben. - HTTP Header Checker: Retry-After, CDN-Fingerprints und Weiterleitungs-Hops untersuchen. - Googlebot Verifier: IP-Belege vor einer Crawler-Ausnahme prüfen. - Log File Analyzer: Statuscode-Verschwendung nach Bot und Bereich segmentieren. - Search-Console-Crawl-Stats: Den Zeitpunkt der 429s mit Crawl-Anfragen und Host-Antwortverhalten vergleichen.

Eine 429-Konfiguration validieren

Test des Antwortvertrags

Auszuführender Test: Das Limit kontrolliert auslösen und die rohe Antwort prüfen. Erwartetes Ergebnis: 429 mit gültigem Retry-After und ohne Weiterleitung oder Erfolgsstatus. Fehlschlag: Falsche Schicht oder Fehlervorlage besitzt die Antwort. Überwachung: sofort. Rollback: Normale Anfragen werden begrenzt oder der Test destabilisiert den Dienst.

Geltungsbereichstest

Auszuführender Test: Begrenzten Client, normale Nutzer und verifizierten Crawler über repräsentative URL-Klassen testen. Erwartetes Ergebnis: Nur definierter Datenverkehr überschreitet das Limit. Fehlschlag: Rate-Limit-Schlüssel oder Geltungsbereich ist zu breit. Überwachung: kontrollierter Test und Edge-Verteilung. Rollback: Unbeteiligte Routen, Nutzer oder Hosts erhalten 429.

Erholungstest

Auszuführender Test: Auslöser stoppen, Retry-Intervall abwarten und Anfragen wiederholen. Erwartetes Ergebnis: Normale Antworten kehren ohne URL-Workaround zurück. Fehlschlag: Gecachte 429s oder Limiter-Zustand bleiben bestehen. Rollback: Hostname bleibt begrenzt, obwohl die Last verschwunden ist.

Test der Cache-Speicherung

Auszuführender Test: Einen Cache oder CDN-Edge vor die Route setzen, eine 429 auslösen und dieselbe URL nach Ende der Bedingung erneut anfordern. Erwartetes Ergebnis: Frische Auswertung, keine gecachte oder wiedergegebene 429. Fehlschlag: Ein Vermittler speichert eine laut RFC 6585 nicht cachebare Antwort; Cache-Control und Edge-Regel prüfen. Rollback: Eine gecachte 429 wird nach Erholung des Origins ausgeliefert.

Test der Client-Wiederholungsrichtlinie

Auszuführender Test: Einen Client mit und ohne gültigen Retry-After durch eine 429 führen. Erwartetes Ergebnis: Mit Header wartet er das Intervall; ohne Header nutzt er begrenztes Backoff mit Jitter, Versuchslimit und Idempotenzprüfung. Fehlschlag: Sofortige, unbegrenzte oder blinde Wiederholungen sind eine fehlerhafte Richtlinie. Rollback: Wiederholungen lösen das Limit erneut aus.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Texte - HTTP-Statuscodes und ihre SEO-Auswirkungen — mein Leitfaden zu Statuscodes und SEO, einschließlich 429. - Der Einsteigerleitfaden für technisches SEO — Crawl-Steuerung und Statuscodes im größeren Zusammenhang. - Die Geschichte, wie zwei hoch rankende Seiten durch Robots.txt blockiert wurden — mein Experiment zum Aussperren von Crawlern.

Meine Vorträge - Wie die Suche funktioniert (SlideShare) — mein Überblick über Crawling, Rendering, Indexierung und Ranking sowie Server-Signale zum Bremsen von Crawlern. (Mein Hinweis: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „Das ist mein Verständnis der Systeme … nicht zu 100 % vollständig oder korrekt.“)

Aus der Branche - Keine 403s oder 404s für Rate-Limiting verwenden (Google Search Central, Gary Illyes) — die maßgebliche Aussage, dass 429 die Ausnahme ist. - Google-Crawl-Rate reduzieren (Google) — 1–2-Tage-Fenster, hostnameweite Drosselung und Erholung. - Google warnt vor 403/404 für die Googlebot-Crawl-Rate (Search Engine Land). - Google sagt: Keine 403s oder 404s zur Reduzierung der Googlebot-Crawl-Raten (Search Engine Roundtable). - Google: 403/404 nicht für Rate-Limiting von Googlebot verwenden (Search Engine Journal). - MDN — 429 Too Many Requests — Protokolldefinition und Retry-After. - Bingbot-Anleitung — Anleitung zu crawl-delay.

Testen Sie Ihr Wissen: 429 Too Many Requests

Fünf kurze Fragen dazu, wie 429 funktioniert und wie Google damit umgeht. Wählen Sie jeweils eine Antwort und prüfen Sie anschließend Ihre Auswahl.

Änderungsprotokoll