Das Crawl-Budget bezeichnet die Menge an Ressourcen, die der Googlebot für das Crawlen einer Website aufwendet – also wie viele URLs er in einem gegebenen Zeitraum abruft und wie häufig er wiederkommt. Der Begriff stammt aus Googles eigener Dokumentation und setzt sich aus zwei Faktoren zusammen: dem Crawling-Kapazitätslimit, das die Website technisch verkraftet, und dem Crawling-Bedarf, den Google an den Inhalten hat. Für kleine Websites ist das Crawl-Budget praktisch nie ein Problem; für große Onlineshops mit vielen tausend URLs kann es darüber entscheiden, wie schnell neue Produkte, Preisänderungen oder ein kompletter Relaunch im Index ankommen.
Lange war „Crawl Budget" ein schwammiger Szene-Begriff, bis Google ihn 2017 in einem Blogbeitrag von Gary Illyes („What Crawl Budget Means for Googlebot") offiziell definierte. Heute ist das Konzept fester Bestandteil der Google-Dokumentation für Website-Betreiber, inklusive eines eigenen Leitfadens für die Verwaltung des Crawl-Budgets großer Websites.
Die zwei Komponenten des Crawl-Budgets
Google beschreibt das Crawl-Budget als Zusammenspiel zweier Größen, die man getrennt verstehen sollte, weil sie sich an unterschiedlichen Stellschrauben beeinflussen lassen.
Crawling-Kapazitätslimit: Was der Server verkraftet
Der Googlebot will Websites crawlen, ohne sie zu überlasten. Er beobachtet deshalb, wie schnell und stabil ein Server antwortet, und passt seine Abrufrate laufend an. Antwortet die Website zügig, erhöht Google die Zahl paralleler Verbindungen; häufen sich Serverfehler (5xx-Statuscodes) oder steigen die Antwortzeiten, drosselt der Bot. Das Kapazitätslimit ist also keine feste Quote, sondern ein dynamischer Regelkreis. Praktische Konsequenz: Ein schneller, stabiler Server ist nicht nur eine Nutzererfahrungs-Frage, sondern vergrößert direkt das technische Crawl-Fenster. Umgekehrt kann ein schwächelndes Hosting das Crawling einer großen Website wochenlang ausbremsen, ohne dass irgendwo eine Fehlermeldung aufleuchtet.
Crawling-Bedarf: Was Google überhaupt holen will
Die zweite Komponente ist die Nachfrageseite: Wie wichtig und wie veränderlich schätzt Google die URLs einer Website ein? Beliebte, gut verlinkte Seiten werden häufiger gecrawlt; Seiten, die sich oft ändern, ebenfalls. Eine Produktdetailseite, die seit zwei Jahren unverändert ist und kaum interne Links erhält, besucht der Bot entsprechend selten. Der Crawling-Bedarf erklärt auch, warum nach einer Migration plötzlich massiv gecrawlt wird: Tausende Redirects und neue URLs erzeugen einen Verarbeitungsstau, den Google abarbeiten will. Wichtig ist die Trennung von Crawling und Indexierung – gecrawlt zu werden ist die Voraussetzung, aber keine Garantie dafür, dass eine Seite in den Index aufgenommen wird oder rankt.
Wann Crawl-Budget wirklich relevant ist
Die unbequeme Wahrheit zuerst: Für die meisten Websites ist Crawl-Budget kein Thema. Google selbst zieht die Grenze in seiner Dokumentation ungefähr so: Relevant wird die Budget-Frage für Websites ab etwa einer Million eindeutiger URLs mit wöchentlich wechselnden Inhalten – oder ab etwa zehntausend URLs, deren Inhalte sich täglich ändern. Ein Corporate-Blog mit 300 Artikeln wird vollständig und regelmäßig gecrawlt, egal wie unaufgeräumt er ist. Wer dort „Crawl-Budget-Optimierung" betreibt, poliert eine Stellschraube, die nichts bewegt.
Onlineshops rutschen allerdings schneller über diese Schwelle, als die reine Produktzahl vermuten lässt. Denn die URL-Menge eines Shops ist nicht die Zahl seiner Produkte – sie ist die Zahl der erreichbaren URL-Varianten. Und die explodiert durch Technik, die aus Nutzersicht völlig sinnvoll ist:
- Facettierte Navigation: Jede Filterkombination aus Farbe, Größe, Marke und Preis erzeugt eine eigene URL. Aus 200 Kategorien werden so schnell Hunderttausende crawlbare Adressen.
- Parameter-URLs: Sortierungen (
?sort=price), Tracking-Parameter, Session-IDs und Paginierung vervielfachen jede Seite. - Interne Suche: Indexierbare Suchergebnisseiten sind ein Fass ohne Boden – jede denkbare Sucheingabe ist eine URL.
- Duplikate: Produkte, die über mehrere Kategoriepfade erreichbar sind, existieren ohne sauberes Canonical-Konzept mehrfach.
- Redirect-Ketten und Fehlerseiten: Jede Weiterleitungsstation und jede gecrawlte 404-Seite verbraucht einen Abruf, der einer echten Seite fehlt.
Genau diese Mechanik macht das Crawl-Budget zum E-Commerce-Thema: Der Bot verbringt seine Zeit mit Filter-Varianten und Sortier-Parametern, während die neue Produktlinie tagelang auf ihren ersten Crawl wartet.
Crawl-Budget messen und optimieren
Messen: Crawling-Statistiken und Logfiles
Der erste Blick gehört dem Bericht „Crawling-Statistiken" in der Google Search Console (unter Einstellungen). Er zeigt für die letzten 90 Tage, wie viele Anfragen der Googlebot gestellt hat, wie sich die Antwortzeiten entwickeln, welche Statuscodes er bekam und wie sich die Abrufe auf Dateitypen und Zwecke (Aktualisierung vs. neue URLs) verteilen. Auffällige Muster – etwa ein hoher Anteil an 404- oder Redirect-Antworten – sind hier auf einen Blick sichtbar.
Wer es genauer braucht, kommt an einer Logfile-Analyse nicht vorbei. Die Server-Logs zeigen jede einzelne Bot-Anfrage: welche URLs der Googlebot tatsächlich abruft, wie oft, und welche Bereiche er ignoriert. Werkzeuge wie der Screaming Frog Log File Analyser verschneiden diese Daten mit einem Crawl der Website und beantworten die entscheidende Frage: Deckt sich das, was Google crawlt, mit dem, was ranken soll? In der Praxis ist das Ergebnis oft ernüchternd – ein zweistelliger Prozentsatz der Bot-Zugriffe entfällt nicht selten auf Parameter-URLs, die nie ranken sollten.
Optimieren: Die wirksamen Hebel
Die Optimierung folgt einer einfachen Logik: dem Bot weniger Müll anbieten und die wichtigen Seiten leichter erreichbar machen.
| Maßnahme | Wirkung |
|---|---|
| Filter- und Parameter-URLs per robots.txt sperren | Verhindert das Crawlen unendlicher URL-Räume an der Quelle |
| Sauberes Canonical-Konzept für Duplikate | Bündelt Signale, reduziert redundantes Crawling |
| Redirect-Ketten auf ein direktes Ziel verkürzen | Spart pro Aufruf eine oder mehrere Stationen |
| Gepflegte XML-Sitemaps mit korrekten lastmod-Daten | Lenkt den Bot gezielt auf neue und geänderte Inhalte |
| 404/410 für dauerhaft entfernte Inhalte | Google lernt schnell, diese URLs nicht mehr zu besuchen |
| Serverleistung und Antwortzeiten verbessern | Hebt das Kapazitätslimit, der Bot crawlt mehr pro Tag |
| Flache Informationsarchitektur, starke interne Verlinkung | Erhöht den Crawling-Bedarf der wichtigen Seiten |
Ein verbreiteter Irrtum gehört dabei ausgeräumt: noindex spart kein Crawl-Budget. Eine Seite mit noindex muss gecrawlt werden, damit Google die Anweisung überhaupt sieht. Wer Crawling verhindern will, braucht die robots.txt; wer Indexierung verhindern will, braucht noindex – die beiden Werkzeuge lösen verschiedene Probleme und stehen sogar im Konflikt, wenn man sie kombiniert: Eine per robots.txt gesperrte Seite kann ihr noindex nicht mehr ausspielen.
Ein Realbeispiel: facettierte Navigation im Modeshop
Das Lehrbuchbeispiel für Crawl-Budget-Verschwendung ist der Modeshop mit facettierter Navigation. 50.000 Produkte, Filter für Marke, Farbe, Größe, Material und Preisspanne – kombinierbar und jeweils als eigene URL erreichbar. Rechnerisch entstehen daraus zig Millionen URL-Kombinationen. Googles eigener Leitfaden zur facettierten Navigation beschreibt exakt diesen Fall und empfiehlt, Filter-URLs, die nicht ranken sollen, konsequent vom Crawling auszuschließen (robots.txt oder URL-Fragmente) und nur kuratierte, nachgefragte Filterseiten – etwa „Sneaker in Rot" – als indexierbare Landingpages auszubauen. Der Effekt einer solchen Aufräumaktion ist in den Crawling-Statistiken meist binnen Wochen sichtbar: Die Bot-Zugriffe verlagern sich von Parameter-Varianten auf Produkt- und Kategorieseiten, und neue Inhalte tauchen schneller im Index auf.
Crawl-Budget bei Relaunch und Migration
Eine Sonderrolle spielt das Crawl-Budget bei einem Plattformwechsel. Nach dem Go-live muss Google den kompletten alten URL-Bestand neu crawlen, um die 301-Weiterleitungen zu entdecken, und parallel den neuen Bestand aufnehmen – der Crawling-Bedarf verdoppelt sich faktisch für einige Wochen. Jede Altlast wirkt jetzt doppelt: Redirect-Ketten aus früheren Relaunches, vergessene Parameter-URLs und langsame Server verlängern die Übergangsphase, in der Rankings schwanken. Wer vor der Migration aufräumt – Ketten begradigt, das URL-Inventar bereinigt, die Serverleistung prüft – verkürzt messbar die Zeit, bis der Umzug verarbeitet ist. Auch deshalb gehört die temporäre Sitemap mit den alten URLs zum Standardwerkzeug: Sie lenkt das verfügbare Budget gezielt auf die URLs, deren Redirects Google finden muss.
Ausblick: Crawl-Budget in Zeiten der KI-Crawler
Das Konzept stammt aus einer Welt, in der im Wesentlichen ein Bot zählte: der Googlebot. Diese Welt gibt es so nicht mehr. Neben den klassischen Suchmaschinen-Crawlern rufen inzwischen KI-Crawler wie GPTBot (OpenAI), ClaudeBot (Anthropic) oder PerplexityBot Websites in erheblichem Umfang ab – teils fürs Training von Sprachmodellen, teils für die Live-Beantwortung von Nutzerfragen. Für den Server ist das schlicht zusätzliche Last, die auf dasselbe Kapazitätslimit einzahlt: Ein Hosting, das schon am Googlebot knabbert, bekommt durch den KI-Traffic ein messbar größeres Problem.
Gesteuert wird auch diese neue Bot-Generation über die robots.txt, in der sich die Crawler einzeln per User-Agent zulassen oder aussperren lassen. Die Entscheidung ist dabei längst strategisch, nicht nur technisch: Wer KI-Crawler komplett blockiert, schützt Serverressourcen und Inhalte – verzichtet aber darauf, in KI-Antworten als Quelle aufzutauchen. Für Shops, die Sichtbarkeit in ChatGPT, Perplexity und Co. anstreben, gilt deshalb dieselbe Logik wie beim klassischen Crawl-Budget: schnelle Server, saubere URL-Strukturen und keine unendlichen Parameter-Räume, in denen sich auch ein KI-Bot verlaufen kann. Die Hausaufgaben sind dieselben geblieben; nur die Zahl der Gäste, die davon profitieren, ist gewachsen.
Häufige Fragen zum Crawl-Budget
Ist Crawl-Budget ein Rankingfaktor?
Nein. Das Crawl-Budget beeinflusst, ob und wie schnell Seiten gecrawlt und damit indexiert werden können – nicht, wie sie bewertet werden. Eine Seite, die wegen verschwendeten Budgets wochenlang nicht gecrawlt wird, kann aber natürlich auch nicht ranken. Der Effekt ist indirekt, bei großen Shops trotzdem geschäftsrelevant.
Ab welcher Größe muss ich mich um mein Crawl-Budget kümmern?
Googles Faustregel: ab rund einer Million URLs mit wöchentlichen Änderungen oder ab etwa zehntausend URLs mit täglichen Änderungen. Onlineshops sollten dabei in erreichbaren URL-Varianten rechnen, nicht in Produkten – mit facettierter Navigation überschreitet auch ein mittelgroßer Shop diese Schwellen schnell.
Spart noindex Crawl-Budget?
Nein. Die noindex-Anweisung steht im HTML oder HTTP-Header der Seite – Google muss die Seite also crawlen, um sie zu lesen. Crawling verhindert nur die robots.txt. Langfristig crawlt Google dauerhaft auf noindex stehende Seiten zwar seltener, als Spar-Instrument taugt das aber nicht.
Kann ich das Crawling beschleunigen?
Direkt anfordern lässt sich nur wenig: Die URL-Prüfung der Search Console stößt einzelne URLs an, Sitemaps mit aktuellen lastmod-Werten signalisieren Änderungen im Bestand. Nachhaltig wirkt nur die Kombination aus schnellem Server, sauberer URL-Struktur und starker interner Verlinkung – also ein höheres Kapazitätslimit und ein klarer Bedarf.
Wie erkenne ich, dass Crawl-Budget bei mir ein Problem ist?
Typische Symptome: Neue Produkte oder Inhalte brauchen viele Tage bis zur Indexierung, der Bericht „Crawling-Statistiken" zeigt hohe Anteile an Parameter-URLs, Redirects oder 404ern, und in der Indexierungsübersicht wächst die Gruppe „Gecrawlt – zurzeit nicht indexiert". Bestätigen lässt sich der Verdacht sauber nur per Logfile-Analyse.