Googles Crawl-Budget-Doku: mehr als die angekündigte Politur

Am 22. Juli 2026 hat Google seine Crawl-Budget-Dokumentation überarbeitet. Im Changelog der Crawling-Doku steht dazu ein Eintrag von zwei Sätzen, und der verspricht Sprachpflege: „to improve clarity, terminology consistency, and flow“. Wer das liest, klickt weiter.

Gelesen habe ich davon zuerst im Search Engine Journal. Der Beitrag greift drei Formulierungsänderungen heraus und zieht daraus eine Lehre fürs Texten. Der Winkel hat mich überzeugt, die Auswahl neugierig gemacht: Drei Beispiele zeigen ein Muster, den Umfang zeigen sie nicht. Also habe ich mich selbst auf die Suche gemacht, die archivierte Fassung vom Vortag neben die heutige gelegt und beide Texte satzweise verglichen.

Es war mehr. Aus drei Beispielen wurden zehn geänderte Stellen, und an dreien davon steht neue Sachinformation. Die kommt im Changelog-Eintrag nicht vor und fehlt bislang auch in meinem eigenen Crawl-Budget-Guide. Dazu später mehr.

Der Vergleich ist reproduzierbar, weil beide Fassungen öffentlich sind und beide Adressen weiter unten stehen. Welche Änderung als sprachlich und welche als sachlich zählt, ist meine Einteilung. Die Wortlaute daneben stehen zum Nachlesen. Hier die Übersicht, sortiert nach Art der Änderung.

Erstens: hostload. Das crawl capacity limit trägt jetzt offiziell einen zweiten Namen. Ganz neu ist das Wort auf der Seite nicht, denn die Fassung vom Vortag kannte es bereits als Fehlermeldung: „you’re getting Hostload exceeded in the URL inspection tool“. Neu ist, dass Google es als Bezeichnung des Limits selbst führt. Wichtiger als der Name ist ohnehin die neue Definition. Bisher las sich das Limit wie eine Obergrenze für gleichzeitige Verbindungen, jetzt begrenzt es „the total amount of time your server spends holding connections open for Google“. Gemeint ist die Verbindungszeit insgesamt, gerechnet aus Anzahl und Dauer. Ein Server, der langsam antwortet, verbraucht das Budget nach dieser Lesart schneller als ein flotter, und das war vorher bestenfalls zu erahnen.

Zweitens: 429 und 5xx stehen jetzt ausdrücklich da. Die alte Fassung sprach allgemein von „server errors“ und die neue benennt „server errors (5xx HTTP status codes) or rate-limiting signals (such as HTTP 429)“. Wer eine aggressive Rate-Limiting-Regel auf dem Server oder in der Web Application Firewall laufen lässt, drosselt damit nach dieser Formulierung sein eigenes Crawl-Budget. Diese Konsequenz war vorher nicht ablesbar.

Drittens: das Limit gilt crawler-übergreifend. Neu im Text steht: „the crawl capacity limit is shared across all crawlers. This means that high demand from one crawler can reduce the capacity available for others.“ Beispiele nennt Google nicht. Meine Lesart: Holt AdsBot oder der Shopping-Crawler viel ab, bleibt für den Googlebot weniger übrig. Von den drei inhaltlichen Neuerungen halte ich diese für die praktisch folgenreichste.

Dazu kommt ein Abschnitt, der konkret geworden ist. „Make your pages efficient to load“ stand schon am Tag davor da, wörtlich gleich und ohne einen einzigen Handgriff darunter. Jetzt stehen zwei darunter: Antwortzeiten und Ressourcen optimieren, und HTTP-Caching per 304 Not Modified unterstützen. Der 304 ist dabei die eigentliche Neuerung, denn dieser Statuscode kam auf der alten Seite kein einziges Mal vor. Was daraus praktisch folgt, steht in meinem Guide zum Crawl Budget optimieren. Wie Crawling und Indexierung überhaupt ineinandergreifen, erkläre ich in den Grundlagen zu Crawling und Indexierung.

Angekündigt ist der Rewrite, nur nicht dort wo ich zuerst gesucht habe. Im Juli-Abschnitt der Search-Central-Änderungsliste stehen Einträge für den 1., 7., 10., 14., 24. und 29. Juli. Für den 22. Juli steht dort nichts. Stand 5. August 2026.

Der Grund ist ein Umzug. Am 18. Dezember 2025 hat Google mehrere Crawling-Dokumente auf eine eigene Infrastruktur-Site verschoben und darunter war auch „Optimize your crawl budget“. Diese Site führt ihr eigenes Änderungsprotokoll unter developers.google.com/crawling/docs/changelog, samt eigenem RSS-Feed. Dort steht der Eintrag zum 22. Juli, und dort steht auch der Umzug selbst.

Dann ist da noch die Sprache. Ruf dasselbe Änderungsprotokoll mit ?hl=de auf, und der Juli 2026 fehlt vollständig. Der jüngste deutsche Eintrag stammt vom 4. Mai 2026, aus einer Zeit also, in der es den Rewrite noch gar nicht gab. Der Oktober 2025 fehlt ebenfalls, ein einmaliger Ausrutscher ist das nicht. Ich habe beide Fassungen am 5. August 2026 im selben Moment abgerufen: achtzehn Einträge in der englischen, kein einziger aus dem Juli in der deutschen.

Die Doku selbst ist davon nicht betroffen, und dieser Unterschied ist wichtig. Die deutsche Fassung der Crawl-Budget-Seite trägt den kompletten Rewrite, samt 429, 304 und geteiltem Kapazitätslimit. Nur heißt hostload dort „Hostlast“, ein Wort, das dir sonst nirgends begegnet. Hinterher hinkt allein das Änderungsprotokoll, also ausgerechnet die Seite, deren einzige Aufgabe es ist, dich auf Änderungen hinzuweisen.

Wer nur eine der beiden Listen abonniert hat, bekommt die andere Hälfte nicht. Und selbst wer den richtigen Eintrag liest, erfährt nicht alles: Er verspricht Klarheit, einheitliche Begriffe und besseren Lesefluss. Von 429, von 304 und vom geteilten Kapazitätslimit steht darin kein Wort. Ein Changelog beschreibt, was der Autor vorhatte. Was tatsächlich im Text gelandet ist, steht nur im Text.

Wie sich eine solche Detailänderung im Crawling auswirkt, habe ich beim 2-MB-Crawl-Limit des Googlebot aufgeschrieben. Praktisch heißt das zweierlei: Beide Feeds gehören in den Reader, und die zwei oder drei Dokus, auf denen deine wichtigsten Artikel stehen, gehören zusätzlich in eine eigene Überwachung.

1. Ersetze vage Zusagen durch die tatsächliche Bedingung

„Responds quickly for a while“ klingt hilfreich und sagt nichts. Wie schnell? Wie lange? Die neue Fassung nennt stattdessen die Bedingung: gleichbleibende Antwort, stabile oder sinkende Antwortzeiten, Latenz und Time to First Byte inbegriffen. Das ist prüfbar. Suche in deinen eigenen Texten nach Formulierungen wie „in der Regel“ oder „relativ schnell“ und ersetze jede davon durch die Bedingung, die du tatsächlich belegen kannst. Findest du keinen Beleg, streiche die Aussage. Vage machen ist keine Alternative.

2. Streiche Wörter, die dasselbe zweimal sagen

„Simultaneous parallel connections“ ist ein Paar, das sich selbst wiederholt, denn gleichzeitig und parallel bedeuten dasselbe. Solche Paare kosten beim Schreiben nichts und bremsen beim Lesen jedes Mal. Deutsche Klassiker sind „vorab im Voraus“, „jeweils einzeln“ und „bereits schon“. Beim Schreiben fallen sie selten auf und beim Vorlesen sofort.

3. Beschreibe, was ein System tut, nicht was es will

Aus „Google’s crawlers might decide that it’s not worth the time“ wurde „Google’s crawlers might not explore“. Ein Crawler entscheidet nichts und findet nichts der Mühe unwert, sondern er ruft eine URL ab oder eben nicht. Die Vermenschlichung wirkt anschaulich und verschiebt in Wahrheit den Fokus vom beobachtbaren Verhalten auf eine unterstellte Absicht. Genau dort fangen SEO-Texte an, Google Motive anzudichten.

4. Ein Gedanke pro Satz

Die alte Fassung packte Crawl-Budget-Definition und Hostname-Regel in einen Satz, jetzt sind es drei Sätze und die Hostname-Regel steht eigenständig. Das Kriterium ist nicht die Satzlänge, der neue Text hat durchaus lange Sätze. Entscheidend ist, ob ein Satz einen Gedanken trägt oder zwei gegeneinander laufende. Ein Nebensatz, der die Hauptaussage wieder einkassiert, gehört abgetrennt.

5. Nutze denselben Begriff für dieselbe Sache

Zweimal stand in der alten Fassung ein Begriff, den die Seite selbst nicht definierte: einmal „serving limit“ für das Kapazitätslimit und einmal „Index Coverage report“ für ein Werkzeug, das in der Search Console längst „Seitenindexierung“ heißt. Beides ist jetzt korrigiert. Der zweite Fall ist der lehrreichere, denn hier stand in Googles eigener Doku ein Name, den Googles eigenes Produkt schon nicht mehr trug. Wenn das dort passiert, passiert es in deinen Artikeln erst recht. Suche nach Werkzeugnamen, Menüpfaden und Feature-Bezeichnungen. Sie altern still.

Bevor ich hier Regeln aufschreibe, gehört der Blick in die eigene Ablage. Mein Guide zum Crawl Budget ist zuletzt am 25. April 2026 aktualisiert worden, also gut drei Monate vor dem Rewrite. Dort steht: „Crawl Rate Limit (Crawling-Kapazität): Dies ist die technische Grenze, wie viele Anfragen der Googlebot an deinen Server senden kann.“

Das sind zwei Probleme in einem Satz. „Crawl Rate Limit“ hieß in Googles Doku schon vor dem Rewrite „crawl capacity limit“, und die Definition über die Anzahl der Anfragen ist genau das Modell, das die neue Fassung gerade ersetzt hat. Es geht um Verbindungszeit und Anfragen sind davon nur ein Faktor. Von hostload, 429 und 304 steht in meinem Artikel bislang gar nichts.

Das ist unangenehm zu schreiben und genau der Grund, warum dieser Beitrag existiert. Ein Artikel veraltet selten deshalb, weil jemand ihn schlecht geschrieben hat, sondern weil sich die Quelle unter ihm bewegt hat und ich nicht nachgesehen habe. Der Guide bekommt in den nächsten Tagen sein Update. Wer prüfen will, ob ein eigener Text überhaupt noch etwas Eigenes sagt, findet dafür hier im Blog den Selbsttest auf austauschbaren Content.

Der übliche Reflex bei „Artikel aktualisieren“ ist ein neuer Abschnitt unten dran und eine frische Jahreszahl im Titel. Google hat das Gegenteil gemacht: Vage Zusagen wurden konkret, ein Wortpaar verschwand, eine Vermenschlichung wich einer Verhaltensbeschreibung und zwei Begriffe wurden vereinheitlicht. Nach meiner Zählung ist die Seite dabei von rund 1.220 auf rund 1.360 Wörter gewachsen. Das sind elf Prozent mehr Text für drei zusätzliche Sachverhalte, und keine einzige neue Überschrift.

Die zweite Lehre steckt im Changelog-Eintrag. Google hat Bescheid gesagt und dabei Klarheit, einheitliche Begriffe und Lesefluss versprochen. Dass drei Sachverhalte dazugekommen sind, stand da nicht. Eine Änderungsmeldung sagt dir zuverlässig, dass etwas passiert ist. Beim Was verlässt du dich auf die Selbsteinschätzung dessen, der die Änderung geschrieben hat.