Google dokumentiert Retry-After zum Bremsen des Crawlers: was die Seite sagt und was weiter fehlt

Google hat am 6. Oktober 2026 eine Seite seiner Crawling-Dokumentation überarbeitet und Website-Betreibern damit etwas gegeben, das sie sich jahrelang selbst zusammengereimt haben: ein offizielles Beispiel dafür, wie man Googlebot sagt, wann er wiederkommen soll. Die Seite heißt Reduce the Google crawl rate und enthält jetzt den HTTP-Header Retry-After mit zwei Codebeispielen.

Sie enthält auch den Satz, den fast die gesamte Berichterstattung übersprungen hat. Googles eigene Obergrenze für diese Technik liegt bei ein bis zwei Tagen, und das Dokument sagt, was darüber hinaus passiert: „Wenn Googlebot diese Statuscodes mehrere Tage lang bei derselben URL beobachtet, kann die URL aus Googles Index entfernt werden“ (unsere Übersetzung, das Original ist englisch).

Vier Google-Dokumente regeln, was passiert, wenn ein Server anfängt, Googlebot abzuweisen. Am 7. Oktober 2026 live gelesen, erwähnt genau eines davon Retry-After, und genau eines nennt eine Zahl dafür, wie lange das sicher ist. Es ist dasselbe Dokument, und es ist das, was sich gestern geändert hat.

Was in Googles Dokument tatsächlich steht

Die Seite Reduce the Google crawl rate, gestempelt Last updated 2026-10-06 UTC, gibt eine einzige Notfallanweisung: „Um die Crawling-Frequenz für kurze Zeit dringend zu senken (zum Beispiel ein paar Stunden oder 1-2 Tage), gib den HTTP-Statuscode 500, 503 oder 429 statt 200 auf die Crawling-Anfragen zurück.“

Die Wirkung beschränkt sich nicht auf die URLs, die fehlschlagen. Dieselbe Seite hält fest, dass sie „die Crawling-Frequenz deiner Website für den gesamten Hostnamen senkt (zum Beispiel subdomain.example.com), und zwar sowohl für die URLs, die Fehler zurückgeben, als auch für die, die Inhalte zurückgeben. Sie erhöht die Crawling-Frequenz automatisch wieder, sobald die Zahl dieser Fehler zurückgeht.“

Neu ist der Header. „Wenn du einen Statuscode 503 oder 429 zurückgibst, kannst du zusätzlich einen HTTP-Header Retry-After mitschicken (wie in RFC 9110 HTTP Semantics definiert), um anzugeben, wann Googles Crawler die Anfrage erneut stellen können“, heißt es dort — mit beiden dokumentierten Formen, einer Verzögerung in Sekunden und einem absoluten Datum:

HTTP/1.1 503 Service Unavailable
Retry-After: 120

HTTP/1.1 503 Service Unavailable
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT

Und dann die Grenze: „Wir empfehlen nicht, das über einen längeren Zeitraum zu tun (also länger als 1-2 Tage), da es sich negativ darauf auswirken kann, wie deine Website in Google-Produkten erscheint.“ Die Suche steht dort als Beispiel, nicht als der ganze Geltungsbereich.

Die Änderung ist protokolliert. Googles Changelog der Crawling-Dokumentation trägt einen Eintrag vom 6. Oktober 2026: „Der Abschnitt zur dringenden Senkung der Crawling-Frequenz wurde umstrukturiert, und es wurden Informationen und Beispiele zum HTTP-Header Retry-After in der Dokumentation Reduce the Google crawl rate ergänzt.“

Was die Community beobachtet hat

Barry Schwartz hat die Änderung am 6. Oktober 2026 bei Search Engine Roundtable entdeckt und sie als Dokumentationsänderung dargestellt, nicht als Änderung im Verhalten von Googlebot: Google behandelte 500, 503 und 429 schon als Signale zur Crawling-Drosselung, bevor diese Seite Retry-After erwähnte. Diese Lesart deckt sich mit der Formulierung des Changelogs selbst, die von Umstrukturieren und Ergänzen von Beispielen spricht.

Eine Messung aus der Praxis hat die Änderung nicht begleitet. Niemand hat ein Vorher-Nachher des Crawling-Volumens mit und ohne Header veröffentlicht, und Google hat keine Zahl dazu veröffentlicht, wie genau seine Crawler einen Retry-After-Wert einhalten. Keine Quelle dieses Artikels ist eine Studie, also ist keine Stichprobengröße anwendbar: es sind Dokumente, und ihre Datumsstempel sind die Verifikation.

Vier Dokumente und was jedem davon fehlt

Die nützliche Frage ist nicht, was die neue Seite sagt, sondern was die anderen weiterhin nicht sagen. Alle vier wurden am 7. Oktober 2026 live gelesen.

Die zweite Zeile ist die Lücke, auf die es ankommt. How HTTP status codes affect Google’s crawlers ist die Seite, bei der eine Entwicklerin zuerst landet, weil sie erklärt, was ein 429 für Google bedeutet. Dort steht, dass „Googles Crawler den Statuscode 429 als Signal dafür behandeln, dass der Server überlastet ist, und er gilt als Serverfehler“, und dort steht: „Für die Google-Suche entfernt Googles Indexierungs-Pipeline URLs aus dem Index, die beharrlich einen Serverfehler zurückgeben.“ Was „beharrlich“ heißt, wird nicht definiert, und die Zeichenfolge Retry-After kommt auf der Seite überhaupt nicht vor. Zwei unabhängige Abrufe dieser Seite am 7. Oktober 2026 ergaben bei beiden Fragen dasselbe Ergebnis.

Googles einzige veröffentlichte Zahl dazu, wie lange das sicher ist, steht also auf einer anderen Seite als der Satz, den sie einschränkt — und die Seite mit der Konsequenz ist seit dem 4. Februar 2026 unverändert.

Die vierte Zeile dürfte den meisten entgangen sein. Das Changelog der Search-Central-Dokumentation ist die Seite, die diese Branche auf Dokumentationsänderungen hin beobachtet, und ihr einziger Eintrag aus dem Oktober 2026 stammt vom 1. Oktober und betrifft den Leitfaden zu generativen KI-Inhalten. Die Crawling-Änderung ist in einem anderen Changelog protokolliert, in einem anderen Dokumentationsbaum. Wer nur eine Seite beobachtet hat, beobachtete die falsche.

Was sich in der Praxis ändert

Am 6. Oktober hat sich am Verhalten von Googlebot nichts geändert. Geändert hat sich, dass eine Technik, die bisher auf gut Glück eingesetzt wurde, nun ein ausgearbeitetes Beispiel, einen RFC-Verweis und ein erklärtes Verfallsdatum hat — und dass sich die vier verfügbaren Schalter im Tempo um zwei Größenordnungen unterscheiden.

Ein 5xx oder 429 wirkt bei der nächsten Anfrage. Die Meldung einer ungewöhnlich hohen Crawling-Frequenz über die Search Console, auf die dieselbe Google-Seite verweist, trägt Googles eigene Verzögerung: „Du kannst keine Erhöhung der Crawling-Frequenz beantragen, und es kann mehrere Tage dauern, bis die Anfrage geprüft und umgesetzt ist.“

Und robots.txt steht gar nicht auf dieser Leiter. Die Seite Reduce the Google crawl rate bietet sie nicht als Tempo-Steuerung an, und How Google interprets the robots.txt specification, zuletzt aktualisiert am 2026-08-31 UTC, hält fest, dass Google den Inhalt der robots.txt „in der Regel bis zu 24 Stunden“ zwischenspeichert. Ein Disallow, das während eines Ausfalls ergänzt wird, kann einen Tag lang ungelesen bleiben. Genau deshalb ist der Notfallschalter ein Statuscode und keine Textdatei — eine Unterscheidung, die funktionierendes technisches SEO von Folklore trennt. Die Stufe, auf die sie wirkt, ist das Crawling, die erste der drei Stufen aus den SEO-Grundlagen.

Eine Einschränkung, bevor jemand das auf KI-Crawler überträgt: Das ist Googles Dokumentation über Googles Crawler. Sie sagt nichts darüber, ob irgendein anderer Betreiber einen Retry-After-Wert einhält, und die Crawler anderer Unternehmen zu steuern ist ein eigenes Problem mit eigenen Tokens, das der Kurs unter SEO mit KI behandelt.

Was diese Woche zu tun ist

1. Finde heraus, was dein Server heute unter Last zurückgibt. Liefert er 200 mit einer halb gerenderten Seite statt eines Fehlers, ist das die schlechteste verfügbare Antwort: Google crawlt in voller Frequenz weiter und indexiert den Schaden.
2. Gibt er 503 oder 429 zurück, ergänze den Header. Retry-After: 120 für eine Verzögerung in Sekunden oder ein HTTP-Datum wie Wed, 21 Oct 2026 07:28:00 GMT für einen absoluten Zeitpunkt. Beide Formen stehen jetzt in Googles Dokumentation.
3. Stelle einen Wecker auf 24 Stunden. Googles erklärte Obergrenze liegt bei 1-2 Tagen. Der typische Fehler ist nicht die bewusste Überschreitung, sondern ein Vorfall, der still über ein Wochenende offen bleibt.
4. Grenze die Fehler nicht auf einzelne URLs ein. Die Drosselung gilt ohnehin für den gesamten Hostnamen, und kaputte URLs sind genau das, wovon der Satz über das Entfernen aus dem Index handelt.
5. Ist die Überlastung strukturell und kein Ausschlag, nutze die Meldung in der Search Console und plane mehrere Tage ein.
6. Halte robots.txt aus dem Notfallhandbuch heraus. Bis zu 24 Stunden Cache machen daraus ein Instrument der Politik, keine Notbremse.

Wo die Branche wirklich uneins ist

Drei Fragen, die diese Geschichte berührt, haben keine geklärte Antwort, und diese Website tut nicht so, als gäbe es eine.

Sagt eine datierte Dokumentationsänderung etwas über Googles Crawling- oder Ranking-Systeme aus? Das eine Lager hält dagegen, dass Google seine Dokumentation schreibt, um zu beschreiben, was seine Systeme ohnehin tun, sodass eine datierte Änderung dem Nächsten kommt, was die Branche je an Release Notes bekommt. Das andere hält Leitfaden und Mechanismus für verschiedene Objekte, die mehrfach auseinandergelaufen sind. Dieser Fall liefert dem zweiten Lager sein sauberstes Beispiel: Der Changelog-Eintrag spricht vom Umstrukturieren eines Abschnitts und vom Ergänzen von Beispielen — Sprache über ein Dokument — und nichts darin behauptet, Googlebot verhalte sich anders als am 5. Oktober. Entscheiden kann das niemand, weil Google keine Zuordnung von Dokumentationsänderung zu Produktivänderung veröffentlicht.

Ist es sicher, Googlebot absichtlich Fehler zu liefern, und wie lange? Googles zwei einschlägige Dokumente geben eine Empfehlung („länger als 1-2 Tage“ wird nicht empfohlen) und eine undefinierte Schwelle („beharrlich“), und das ist nicht dasselbe. Das eine Lager nimmt eine dokumentierte Technik mit veröffentlichter Obergrenze genau so: nutzbar innerhalb dieser Grenze. Das andere hält absichtliches Fehlerliefern für ein Risiko, das keine Website eingehen sollte, solange ein sichererer Weg existiert, und weist darauf hin, dass die Konsequenz, die Google nennt, das Entfernen aus dem Index ist und nicht langsameres Crawling. Keine veröffentlichte Studie isoliert, wie viele Tage 5xx wie viele URLs kosten; beide Lager argumentieren aus derselben Datenlücke.

Ist eine Zahl, die ein Google-Mitarbeiter auf einer Konferenz nennt, ein Beleg über Googles Systeme? Das zählt hier, weil die naheliegende Anschlussfrage — wie lange die Erholung der Crawling-Frequenz dauert — keine dokumentierte Antwort hat und die kursierenden Zahlen zu Googles Entdeckungs- und Aktualisierungszyklen aus einem Konferenzbericht stammen, nicht aus einem Google-Dokument. Diese Website hat diese Zahlen am 4. Oktober 2026 mitsamt ihrer Herkunft veröffentlicht und sich geweigert, sie als Richtwert zu verwenden. An dieser Haltung hat sich nichts geändert, und was eine solche Zahl wert ist, bleibt hier offen.

Was der Autor dazu meint

Was ich verteidige, ist die dokumentarische Aussage und nichts Breiteres. Am 7. Oktober 2026 ist die einzige Google-Seite, die sowohl Retry-After als auch eine erklärte sichere Dauer trägt, die am 6. Oktober geänderte; die Seite, die definiert, was ein 429 für Google bedeutet, trägt keines von beidem; und das Changelog, das der Großteil dieser Branche beobachtet, erwähnt die Änderung nicht. Das kann jede und jeder anhand der Datumsstempel nachprüfen, und es hat vier Abrufe gekostet.

Was es praktisch bedeutet, ist enger als die Berichterstattung nahelegt. Die Änderung ist gut: Ein ausgearbeitetes Beispiel schlägt Folklore. Aber ich rechne damit, dass sie als Erlaubnis gelesen wird, und der Satz, der Verhalten ändern sollte, ist nicht der über den Header, sondern der über mehrere Tage und den Index.

Ich werde nicht sagen, dass es sicher ist, Googlebot Fehler zu liefern, denn Googles eigene zwei Seiten sind sich nicht einig, wo die Grenze liegt, und gemessen hat es niemand. Und ich werde nicht behaupten, die Änderung signalisiere irgendetwas zum Ranking: Google hat eine Seite geändert, und ob sich produktiv etwas geändert hat, kann Dokumentation nicht beantworten.

Was weiterhin unbekannt ist

• Wie lange die Erholung dauert. Die Seite sagt, die Crawling-Frequenz steige „automatisch wieder“, sobald die Fehler zurückgehen, und nennt dazu keine Dauer.
• Was Retry-After tatsächlich bringt. Google dokumentiert den Header und veröffentlicht keine Zahl dazu, wie genau seine Crawler den Wert einhalten — in keiner der beiden dokumentierten Formen.
• Wo „beharrlich“ liegt. Dieses Wort regelt die Entfernung aus dem Index seit dem 2026-02-04 UTC ohne Definition, und die 1-2-Tage-Angabe auf der anderen Seite ist eine Empfehlung zu deinem Verhalten, keine erklärte Schwelle der Indexierungs-Pipeline.
• Ob etwas außerhalb der Suche betroffen ist. Die Warnung spricht von „einer negativen Auswirkung darauf, wie deine Website in Google-Produkten erscheint“, und nennt die Suche nur als Beispiel.

Quellen

Keine der folgenden Quellen ist eine Studie. Es sind Dokumente und ein Fachartikel, also ist keine Stichprobengröße anwendbar; die Datumsstempel sind die Verifikation.

• Google, Reduce the Google crawl rate, Dokumentation der Crawling-Infrastruktur. Last updated 2026-10-06 UTC. Live gelesen am 7. Oktober 2026.
• Google, Changelog der Crawling-Dokumentation, Eintrag vom 6. Oktober 2026. Live gelesen am 7. Oktober 2026.
• Google, How HTTP status codes affect Google’s crawlers. Last updated 2026-02-04 UTC. Am 7. Oktober 2026 zweimal live gelesen.
• Google, How Google interprets the robots.txt specification. Last updated 2026-08-31 UTC. Live gelesen am 7. Oktober 2026.
• Google, Changelog der Search-Central-Dokumentation. Einziger Eintrag im Oktober 2026 vom 1. Oktober 2026. Am 7. Oktober 2026 zweimal live gelesen.
• Barry Schwartz, Google Search Crawl Rate Doc Adds Retry-After HTTP & More, Search Engine Roundtable, 6. Oktober 2026.
• Google, Search Status Dashboard, incidents.json am 7. Oktober 2026 live gelesen: kein Vorfall trägt einen Beginn-Zeitstempel im Oktober 2026.