Was Crawl Budget ist
Google beschreibt Crawl Budget als Zusammenspiel aus Crawling-Kapazität und Crawling-Bedarf für die URLs einer Website. Optimierbar ist vor allem der angebotene und intern verlinkte URL-Bestand, nicht eine garantierte tägliche Zahl.
Google richtet seinen Leitfaden vor allem an sehr große, häufig aktualisierte Websites sowie Sites mit einem hohen Anteil „Discovered, currently not indexed“. Wenn neue oder geänderte Seiten zeitnah gecrawlt werden, ist ein eigenes Crawl-Budget-Projekt oft nicht die wichtigste Arbeit.
Wann das Thema relevant wird
- Wichtige neue oder geänderte URLs werden deutlich später abgerufen als der Business-Prozess erwartet.
- Logfiles zeigen große Request-Flächen auf Duplikaten, Parametern oder niedrigwertigen Zuständen.
- Facetten, Suche, Kalender oder Varianten erzeugen sehr große crawlbare Räume.
- Migrationen oder systemweite Änderungen erhöhen den notwendigen Recrawl.
- Serverfehler oder langsame Antworten begrenzen die sichere Abrufkapazität.
Keines dieser Signale beweist allein eine Ursache. Search Console, Logs, URL-Inventar und interne Linkstruktur müssen gemeinsam gelesen werden.
Crawling, Indexierung und Ranking trennen
Crawl Budget beschreibt den Abruf von URLs. Es sagt nicht, ob eine abgerufene URL indexiert wird, und noch weniger, ob sie für eine Query rankt. Eine URL kann häufig gecrawlt und trotzdem nicht indexiert werden. Eine andere kann selten neu gecrawlt werden und weiterhin stabil im Index stehen. Deshalb ist „mehr Crawling“ kein sinnvolles Ziel ohne benannten Bestand und erwartete Aktualität.
Vor jeder Maßnahme sollte die operative Frage lauten: Welche URL-Klasse wird zu spät entdeckt oder aktualisiert, welche Evidence zeigt das, und welche konkurrierenden URL-Räume werden tatsächlich abgerufen? Erst dann lässt sich beurteilen, ob technische Kapazität, interne Discovery, unnötige URL-Produktion oder schlicht eine falsche Erwartung das Problem ist.
Mit Logs statt Bauchgefühl messen
Serverlogs zeigen, welche Bot-Identität welche URL zu welchem Zeitpunkt mit welchem Status abgerufen hat. Vor der Auswertung müssen Bot-Verifikation, Zeitzone, Log-Abdeckung, Caching/CDN und der betrachtete Zeitraum geklärt werden.
Segmentiere Requests nach URL-Klasse und Zustand: gewünschte indexierbare Seiten, nicht indexierbare Nutzerseiten, Parameter, Facetten, Redirects, Fehler und statische Ressourcen. Kategorien dürfen nicht überlappen, wenn Prozentanteile addiert werden.
Typische Abflüsse
Parameter und Facetten
Unbegrenzte Kombinationen können immer neue URLs anbieten. Die Lösung beginnt bei der Entscheidung, welche Zustände als stabile Landingpage betrieben werden. Der Faceted-Navigation-Guide beschreibt diese Trennung.
Redirect-Ketten und entfernte URLs
Interne Links und Sitemaps sollten auf den finalen Zielzustand zeigen. Dauerhaft weitergeleitete oder entfernte URLs können in Logs lange sichtbar bleiben, besonders wenn interne oder externe Referenzen fortbestehen.
Low-Value- und Duplicate-Bestände
Ein Canonical kann Duplikatsignale konsolidieren und den Crawl nicht sofort verhindern. Wenn ein URL-Raum nicht für Search benötigt wird, sollte seine Erzeugung, Discovery und Crawl-Regel als Ganzes überprüft werden.
Unpräzise Sitemaps und interne Links
Sitemaps sollten bevorzugte Canonical-URLs enthalten. Interne Links sollten wichtige Seiten direkt referenzieren. Beide sind Hinweise auf beabsichtigte Priorität, keine Indexierungsgarantie.
Eine sinnvolle Reihenfolge
- Relevanz und Datenqualität klären.
- Request-Verteilung pro URL-Klasse messen.
- größte unbeabsichtigte URL-Produzenten stoppen oder begrenzen.
- interne Links und Sitemaps auf den Zielbestand ausrichten.
- Serverfehler und unnötige Ketten beseitigen.
- Discovery und Recrawl wichtiger Klassen über mehrere Perioden beobachten.
Diese Reihenfolge passt zur bestehenden Perspektive auf SEO-Entropie: Erst wird unkontrolliertes Wachstum begrenzt, dann wird der verbleibende Bestand präziser gesteuert.
Fortschritt belastbar prüfen
Ein Vorher-nachher-Vergleich braucht dieselbe Bot-Definition, dieselben URL-Klassen und ausreichend vergleichbare Zeitfenster. Beobachte, ob wichtige neue oder geänderte URLs früher abgerufen werden, ob sich Requests von unbeabsichtigten Räumen wegbewegen und ob Fehler- oder Redirect-Anteile sinken. Saison, Migrationen und größere Releases gehören in die Interpretation.
Der Crawl Budget Calculator hilft, eine gemessene Request-Verteilung transparent zu beschreiben. Er berechnet keine Google-Grenze und ersetzt keine Logfile-Analyse.