Crawl Budget. Diese zwei Wörter werden in SEO-Kreisen ungefähr so behandelt wie eine Urbane Legend. Man hat davon gehört – aber man wills nicht anfassen, weils klebrig ist.
Ich bin heute die Person mit Handschuhen. Wir schauen gleich gemeinsam in die Crawl Stats der Google Search Console und klären, was Purpose, Dateityp und Response wirklich über eure Seite verraten.
Und wenn ihr euch schon mal gefragt habt, warum Google eure frisch veröffentlichte Seite ignoriert, aber gleichzeitig hunderttausend Mal dieselbe Parameter-URL abklappert: Willkommen beim Thema Crawl Budget.
Was ist Crawl Budget?
Crawl Budget bezeichnet grob die Menge an URLs, die Google auf eurer Website in einem Zeitraum crawlen kann und will.
Google beschreibt das als Zusammenspiel aus
- Crawl Capacity Limit (Wie viel eure Server hergeben, ohne zu weinen)
- Crawl Demand (Wie interessant eure Inhalte für Googles wirken)
Wichtig: Crawl Budget ist host-basiert. Das heißt, dass www und subdomain unterschiedliche Hostnames sind – und unterschiedliche Hostenames haben separate Crawl Budgets.
Bevor jemand schreit: Google sagt auch ziemlich klar, dass viele Websites dieses Advanced-Thema gar nicht brauchen. Ja, stimmt. Relevant wird’s vor allem bei sehr großen oder sehr dynamischen Seiten oder wenn ihr viele URLs habt, die zwar entdeckt, aber nicht indexiert werden.
Warum Crawl Budget überhaupt existiert
Das Web ist praktisch unendlich, Googles Ressourcen sind es aber nicht. Deshalb limitiert Google, wie viel Zeit Crawler auf einer einzelnen Site verbringen.
Stellt euch den Googlebot dabei wie einen sehr fleißigen Inventar vor, der mit einem Clipboard durch eure Website läuft. Wenn eure Seite beim Aufmachen schon stöhnt – zum Beispiel durch lange Ladezeiten oder 5xx-Fehler –, dann öffnet dieser Inventar weniger Türen pro Stunde. Er folgt weniger Links. Und er notiert sie nicht im Clipboard.
Crawl Stats: Nackte Zahlen
Die Crawl Stats in der Google Search Console sind Googles Blick in eure Server-Kommunikation: wie viele Requests, welche Download-Größen, welche Antwortzeiten – plus Aufschlüsselung nach Response, Dateityp, Purpose und Googlebot-Typ.
Google hat diese Version des Reports offiziell als vorgestellt und genau diese Gruppierungen genannt.
Wenn ihr Crawl Stats ignoriert, ist das ungefähr so, als würdet ihr ein Auto fahren und euch weigern, aufs Armaturenbrett zu schauen, weil „Die Lampe macht mir Angst“.
Glaubt mir. Mir doch auch. Ändert aber nichts daran, dass das trotzdem ziemlich schlecht ist.
Die drei Kernmetriken
- Total requests: Wie viele Crawl-Anfragen in einem Zeitraum stattgefunden haben.
- Total download size: Wie viele Daten Google dabei insgesamt gezogen hat.
- Average response time: Wie lange eure Server im Schnitt brauchen, um zu antworten.
Diese drei Werte sind euer „Gesamtzustand“.
Die Dimensionen Purpose, File Type und Response sind dann die Diagnose: An welcher Stelle genau ihr Energie verbrennt und warum der Googlebot irgendwann sagt: „Ich komm später wieder. Vielleicht.“
Passend zum Thema
Purpose: Warum Google überhaupt anklopft
Die Purpose-Dimension beantwortet nicht „welche URL“, sondern „welche Absicht hatte der Crawl“.
Discovery vs. Refresh
In der Praxis wird Purpose häufig so verstanden:
Discovery steht für Crawls, bei denen Google neue, noch nicht bekannte, URLs entdecken will.
Wenn Discovery hoch ist, dann hat Google viel Neues gefunden –
oder auch viel neuen Müll gefunden. Sowas wie Parameter-URLs, Facetten, Session-IDs, interne Suchseiten.
Refresh ist das Wieder-Crawlen bereits bekannter URLs, um Änderungen mitzunehmen.
Wenn Refresh hoch ist, crawlt Google vor allem Bestand – was sowohl gut sein kann, als auch schlecht.
Gut: Wichtige Seiten werden frisch gehalten.
Schlecht: Google verschwendet Zeit auf redundante Seiten
Was Purpose euch verrät
- Hoher Discovery-Anteil: Häufig ein Signal für URL-Explosion, also dass Google versucht, euer gesamtes bekanntes URL-Inventar abzugrasen – inklusive Duplikaten.
- Hoher Refresh-Anteil: Entweder eure Inhalte sind relevant und ändern sich oft, oder ihr produziert ständig kleine Änderungen an vielen URLs und der Googlebot spielt „Und täglich grüßt das Murmeltier“.
- Purpose-Sprünge nach Relaunch/Migration: Site-weite Events wie Site Moves können Crawl Demand erhöhen, weil Google neu verarbeiten will.
Dateitypen: Wofür ihr Crawl Budget verballert
Die File-Type-Dimension zeigt, welche Dateitypen Google beim Crawlen zurückbekommt: HTML, JS, CSS, Bilder, PDFs und so weiter.
Wenn euer Crawl-Anteil in „JS“ oder „Image“ hoch ist, heißt das nicht automatisch „schlecht“. Es heißt: Googlebot lädt viele Ressourcen – und das beeinflusst die Download-Size und Response-Time, also eure Crawl Capacity.
Interpretation: Typische Muster und die Bedeutung
- HTML dominiert: Meist normal, besonders bei Content-Seiten. Wenn aber HTML-Requests hoch sind und gleichzeitig viele 3xx/4xx auftauchen: Ihr habt Navigations- oder Canonical-Chaos.
- JS/CSS auffällig hoch: Kann bei JS-lastigen Frontends normal sein, aber es ist ein Hinweis, dass Rendering-Ressourcen mit im Spiel sind und eure Seiten „teurer“ zu crawlen werden.
- Bilddateien auffällig hoch: Häufig bei sehr bildlastigen Seiten, oder wenn ihr unabsichtlich massig Bild-Varianten/Parameter erzeugt.
- PDF auffällig hoch: Klingt erst mal harmlos, ist aber oft ein Hinweis auf riesige Downloads oder doppelte Inhalte, wie PDF und HTML-Version parallel ohne klare Steuerung.
Die fiese Wahrheit über Download Size
Google zeigt in den Crawl Stats „Total Download Size“ als zentrale Metrik über Zeit.
Große Downloads bedeuten nicht nur „Bandbreite“. Sie bedeuten: Jede URL kostet mehr. Und wenn jede URL mehr kostet, wird aus „Google crawlt 50.000 URLs pro Tag“ plötzlich „Google crawlt 5.000“, einfach nur, weil euer HTML so aufgeblasen ist, dass es als Luftschiff durchgeht.
Response: Die Antwortcodes
Response als Dimension heißt: Welche Antwort Googlebot auf seine Requests bekommt.
Viele 200er sind nicht automatisch gut, viele 404er nicht automatisch schlecht. Entscheidend ist: Welche Responses verschwenden Crawling-Zeit und welche helfen, Googles Crawl-Queue zu aufräumen.
404, 410, Soft-404 und warum Blocken oft dümmer ist als Löschen
Google sagt sehr klar: Für dauerhaft entfernte Seiten solltet ihr 404 oder 410 zurückgeben; ein 404 ist ein starkes Signal, diese URL nicht mehr zu crawlen.
Und jetzt der Teil, den viele nicht hören wollen: Wenn ihr URLs stattdessen per robots.txt blockt, bleiben sie laut Google viel länger in der Crawl-Queue und werden wieder recrawlt, sobald ihr die Blockade entfernt.
Soft-404s (Seiten, die wie „nicht gefunden“ wirken, aber mit 200 antworten) sind laut Google pures Budget-Leak: Sie werden weiter gecrawlt und verschwenden Ressourcen. Am besten sofort eliminieren!
3xx: Redirects sind okay – Ketten sind Folter
Redirects sind manchmal nötig (Migrationen, Canonicalisierung, http→https, trailing slash – ihr kennt den Zoo). Aber Google empfiehlt explizit, lange Redirect-Ketten zu vermeiden, weil sie das Crawling negativ beeinflussen.
Ich übersetze: Ein Redirect ist eine höfliche Wegbeschreibung. Eine Redirect-Kette ist ein Escape-Room, in dem Googlebot irgendwann den Notausgang nimmt. Und „Notausgang“ heißt: weniger Crawls, weniger Vertrauen in eure Crawl Health.
Technische Maßnahmen: So holt ihr euch Crawl Budget zurück
Das ist jetzt der Moment, in dem ich gedanklich die Axt 2000 aus dem imaginären Werkzeugkoffer hole, weil manche URL-Strukturen nur noch mit liebevoller Gewalt zu retten sind.
1) URL-Inventar entschlacken
Google nennt „Perceived Inventory“ als einen der wichtigsten Faktoren für Crawl Demand – und gleichzeitig als den Faktor, den ihr am stärksten positiv beeinflussen könnt.
- Duplikate konsolidieren: Gleiche Inhalte auf mehrere URLs? Zusammenführen, Canonicals sauber setzen, Parameter-Strategie definieren.
- Unwichtige URLs nicht crawlen lassen: Google empfiehlt, wenn Konsolidierung nicht geht, unwichtige Varianten per robots.txt zu blocken.
- Aber: Für entfernte Inhalte lieber 404/410 statt robots.txt, damit Google die URL schneller vergisst.
2) Crawl Capacity erhöhen
Wenn eine Seite eine Weile schnell antwortet, kann das Crawl Capacity Limit steigen; wenn sie langsamer wird oder Serverfehler liefert, sinkt es und Google crawlt weniger.
- Serverfehler reduzieren: 5xx sind Crawl-Budget-Killer, weil sie Crawl Health verschlechtern und damit die Kapazität drücken.
- Antwortzeiten stabilisieren: Caching, Datenbank-Tuning, CDN, saubere Timeouts, weniger „ich generiere HTML live aus 17 Microservices“-Akrobatik.
- Seiten effizienter machen: Google empfiehlt explizit, Seiten effizient zu laden; schnelleres Laden kann dazu führen, dass Google mehr Content von eurer Site lesen kann.
3) Sitemap und Signale
Google empfiehlt, Sitemaps aktuell zu halten und bei aktualisierten Inhalten das lastmod-Tag zu nutzen.
- Nur indexierbare URLs in die Sitemap: Keine 404, keine Weiterleitungen, keine Noindex-Opfer.
- lastmod ernst nehmen: Nicht „immer heute“, sondern tatsächliche Änderungen; sonst stumpft das Signal ab (und ja, das ist eine menschliche Metapher, aber ihr versteht).
4) Redirect- und Fehlerhygiene
- Redirect-Ketten kürzen: Keine langen Ketten. Maximal ein Hop.
- Soft-404 eliminieren: Soft-404s verschwenden Budget und sollten behoben werden.
- Richtig löschen: Für dauerhaft entfernte Seiten 404/410 – statt „ich block das mal schnell in robots.txt“.
Ein pragmatischer Crawl-Stats-Workflow
Ihr wollt nicht mehr crawl. Ihr wollt: besser crawl. Und zwar so, dass Google seine Zeit auf die URLs verwendet, die euch Geld, Leads, Reputation oder wenigstens eure innere Ruhe bringen.
Schrittfolge: So lese ich Crawl Stats
- Over-time Charts checken: Total Requests, Download Size, Average Response Time – gibt es Peaks oder Trends?
- Breakdown nach Response: Sind 5xx/4xx auffällig? Gibt es viele 3xx? Dann zuerst Stabilität und Weiterleitungen fixen.
- Breakdown nach File type: Was frisst Download Size? HTML? Bilder? JS? Dann optimiert ihr Payload und Rendering-Kosten.
- Breakdown nach Purpose: Viel Discovery? Dann habt ihr meist URL-Wildwuchs. Viel Refresh? Dann prüft ihr, ob Google auf die richtigen und wichtigen URLs fokussiert.
- Beispiel-URLs öffnen: Der Report bietet Beispiel-URLs je Gruppe; nutzt die als Tatortliste.
Fazit
Wenn ihr euch nach diesem Artikel nur eine Sache merkt, dann bitte diese: Crawl Budget ist nicht Magie. Es ist die Summe eurer technischen Entscheidungen – und eurer Bequemlichkeiten. Und Bequemlichkeit ist in Tech selten kostenlos.
Macht eure URL-Landschaft kleiner, eure Server schneller und eure Signale klarer. Dann kommt der Googlebot nicht nur öfter vorbei – er bleibt auch nicht an der Tür stehen und flüstert „Hostload exceeded“.
Schreibe einen Kommentar