Crawl Budget: was es wirklich bedeutet und wann es laut Google überhaupt relevant wird

Das Crawl Budget einer Domain hängt von zwei unabhängigen Größen ab, die Google kombiniert. Die erste ist das Crawl-Rate-Limit, eine technische Kennzahl dafür, wie viele gleichzeitige Anfragen der Server verträgt, ohne langsamer zu werden. Google berechnet sie anhand von Antwortzeiten und Fehlerrate: Ein langsamer Server oder einer, der viele 5xx-Fehler ausliefert, bekommt weniger Anfragen, nicht mehr, selbst wenn tausende Seiten auf ein Crawling warten.

Die zweite Größe ist die Crawl-Demand, also wie sehr Google überhaupt Interesse hat, eine Website häufig zu besuchen. Sie hängt von der Popularität der Seiten ab, davon, wie oft sich Inhalte tatsächlich ändern, und davon, ob Google die Website insgesamt als relevant genug einstuft. Ein Blog mit einem Artikel im Monat erzeugt eine andere Crawl-Demand als ein Newsportal mit hundert Artikeln am Tag.

Die Crawl-Demand reagiert außerdem auf konkrete Ereignisse: Ein Domainwechsel, eine Migration von HTTP zu HTTPS oder eine große Umstrukturierung der URLs können Googles Interesse, die gesamte Website zu überprüfen, vorübergehend deutlich steigern, während eine Website, die seit Monaten nichts Neues veröffentlicht, meist erlebt, dass Google die Besuchsfrequenz nach und nach reduziert. Keine der beiden Größen lässt sich direkt steuern, man beeinflusst sie nur indirekt, über bessere Serverleistung und über Inhalte, die sich tatsächlich verändern.

Beide Größen ergeben nur dann ein echtes Problem, wenn das Crawling, die Vorstufe zur Indexierung, nicht ausreicht, um alle relevanten Seiten zu erfassen. Deshalb liest sich dieser Artikel am besten zusammen mit dem Glossareintrag zur Indexierung: Ohne ausreichendes Crawling entscheidet Google gar nicht erst, ob eine Seite in den Index gehört.

In SEO-Communitys liest man ständig, man müsse das Crawl Budget "optimieren", als wäre das eine universelle Pflicht. Googles eigene Dokumentation widerspricht dem direkt. Der Leitfaden zur Verwaltung von Crawl Budget für große Websites richtet sich ausdrücklich unter anderem an Websites mit über einer Million eindeutiger Seiten, die sich moderat ändern, ungefähr wöchentlich, oder an mittelgroße bis große Websites, über zehntausend eindeutige Seiten, deren Inhalt sich sehr schnell ändert, also täglich.

Und Google fügt einen Satz hinzu, der beim Zitieren dieses Leitfadens außerhalb des Kontexts gern unterschlagen wird: "Wenn deine Website keine große Anzahl an Seiten hat, die sich schnell ändern, oder wenn deine Seiten offenbar noch am Tag ihrer Veröffentlichung gecrawlt werden, musst du diesen Leitfaden nicht lesen." Google betont zudem, diese Zahlen seien "eine grobe Schätzung, keine exakten Schwellenwerte." Dieses Zitat ist direkt gegen die offizielle Google-Search-Central-Dokumentation geprüft, aufgerufen am 08.08.2026, keine Paraphrase aus zweiter Hand.

Ein weiterer Mythos, der sich mit derselben offiziellen Quelle entkräften lässt: Viele glauben, die Felder <priority> und <changefreq> in der XML-Sitemap würden Google mitteilen, welche Seiten wichtiger sind. Google erklärt ausdrücklich, dass beide Werte ignoriert werden. Das einzige Feld, das Google überhaupt nutzen kann, und auch nur wenn es präzise und verifizierbar ist, ist <lastmod>. Ein korrektes Sitemap-Beispiel, so wie Google es selbst dokumentiert:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.deinedomain.de/produkt/laufschuhe.html</loc>
    <lastmod>2026-07-15</lastmod>
  </url>
</urlset>

lastmod hilft nur, wenn es echte inhaltliche Änderungen widerspiegelt, nicht wenn es sich bei jeder automatischen Sitemap-Generierung von selbst aktualisiert, ohne dass sich an der Seite etwas geändert hat. Google erkennt dieses Muster und verliert dann das Vertrauen in das Feld für die gesamte Domain.

Für viele CMS-Betreiber ist genau das die eigentliche Falle: Zahlreiche Sitemap-Plugins setzen lastmod standardmäßig auf das Datum der letzten Sitemap-Generierung statt auf das echte Änderungsdatum des Inhalts. Wer das nicht manuell korrigiert, sendet über Monate ein falsches Signal an Google und wundert sich dann, warum lastmod offenbar keine Wirkung mehr zeigt.

Laut Googles eigenem Leitfaden wird Crawl Budget dann zu einem echten Problem, wenn im Search-Console-Bericht zur Seitenindexierung viele URLs mit dem Status "Gefunden, derzeit nicht indexiert" auftauchen, ein Zeichen dafür, dass Google die URLs kennt, sie aber nicht priorisiert crawlt. Das passiert typischerweise bei Online-Shops mit Facettennavigation, bei denen jede Filterkombination eine neue URL erzeugt und so Millionen technisch unterschiedlicher URLs entstehen, bei Newsportalen mit tausenden neuen Artikeln am Tag und bei großen Websites mit langen Weiterleitungsketten oder Soft-404-Seiten, die zwar 200 zurückgeben, aber leer sind, und damit Crawling auf URLs verschwenden, die nichts bringen.

Außerhalb dieser Szenarien, bei einer Firmenwebsite, einem Blog oder einem kleinen Onlineshop mit ein paar hundert bis wenigen tausend URLs, ist Crawl Budget so gut wie nie der limitierende Faktor für die Indexierung. Wenn eine neue Seite nicht indexiert wird, liegt das meist an der Content-Qualität, an fehlender interner Verlinkung oder an Canonical-Fehlern, nicht daran, dass Google kein Crawl Budget mehr übrig hätte, um überhaupt bis zur Seite vorzudringen.

Der Bericht Statistiken zum Crawling, in den Einstellungen der Search Console, ist genau für diesen Fall gedacht: damit man nicht raten muss. Er zeigt die Zahl der Crawling-Anfragen über die Zeit, aufgeschlüsselt nach Antwortcode, nach Dateityp, nach Zweck des Crawlings, Entdeckung neuer URLs gegenüber Aktualisierung bereits bekannter, und nach Googlebot-Typ. Ein anhaltender Anstieg von 5xx-Fehlern oder langsamen Antworten in diesem Bericht ist ein deutlich verlässlicheres Signal für ein Crawl-Budget-Problem als jede Vermutung, die sich allein an der Website-Größe orientiert.

Wichtig ist außerdem, ein echtes Crawl-Budget-Problem von einem Architekturproblem zu unterscheiden. Crawlt Google normal, entscheidet sich aber, das Gefundene nicht zu indexieren, liegt der Engpass nicht am Crawling-Budget, sondern an Content-Qualität oder Duplicate Content, und keine robots.txt- oder Server-Optimierung wird das beheben. Bevor man Zeit in die Optimierung von Crawl Budget steckt, lohnt sich zuerst der Ausschluss der gängigsten Indexierungsprobleme, beschrieben im Artikel zur Indexierung. Diese Reihenfolge spart in der Praxis am meisten Zeit, weil technische Maßnahmen am Crawl Budget ins Leere laufen, solange das eigentliche Problem woanders liegt.

• Sperre URLs mit Filter- und internen Suchparametern per robots.txt, wenn sie keinen eigenständigen Inhalt liefern.
• Behebe lange Ketten von 301-Weiterleitungen und entferne Soft-404-Seiten, beide verschwenden Crawling ohne Gegenwert.
• Halte die Antwortzeiten des Servers niedrig; ein schneller Server bekommt mehr Anfragen von Googlebot, nicht weniger.
• Setze lastmod in der Sitemap nur, wenn es eine echte inhaltliche Änderung abbildet, nie als automatisches Datum.
• Konsolidiere doppelten Content per Canonical oder Weiterleitung, bevor er tausende redundante URLs erzeugt.
• Prüfe in der Search Console die als "Gefunden, derzeit nicht indexiert" markierten URLs, um echte Engpässe zu erkennen.
• Setze interne Links gezielt auf die wichtigsten Seiten; Google wertet diese Links als Relevanzsignal.
• Sieh dir den Bericht Statistiken zum Crawling regelmäßig an, nicht erst, wenn du bereits ein Problem vermutest.
• Dokumentiere technische Änderungen an robots.txt und Sitemap mit Datum, damit sich Effekte im Nachhinein zuordnen lassen.

• Sich bei einer Website mit ein paar hundert Seiten in Crawl Budget verrennen, wo es fast nie das eigentliche Problem ist.
• Glauben, das Ausfüllen von priority und changefreq in der Sitemap beeinflusse das Crawling: Google ignoriert beide vollständig.
• Aus Versehen wichtige Seiten sperren, weil man mit zu aggressiven robots.txt-Regeln Crawling sparen wollte.
• Facettennavigation oder Session-Parameter unkontrolliert endlose Kombinationen crawlbarer URLs erzeugen lassen.
• Die Serverfehlerrate als Ursache für schlechtes Crawling ignorieren, obwohl sie meist der erste Verdächtige sein sollte.
• Crawl Budget mit Indexierung verwechseln: Genug Crawl Budget zu haben garantiert nicht, dass eine URL im Index landet.
• Crawl Budget optimieren, bevor man Qualitäts- oder Duplicate-Content-Probleme ausschließt, die meistens die eigentliche Ursache sind.
• Nach einer Serveränderung oder einem Hosting-Wechsel nicht prüfen, ob sich Antwortzeiten oder Fehlerrate verändert haben.