Crawl-Budget im SEO: Wie Googlebot entscheidet, was er crawlt und was du daran ändern kannst

Crawl Rate und Crawl Demand

Das Crawl Budget setzt sich aus zwei Komponenten zusammen: der Crawl Rate und dem Crawl Demand.

Die Crawl Rate ist das technische Limit: Wie viele parallele Verbindungen kann Googlebot aufbauen, ohne deinen Server zu überlasten? Google versucht sich dabei als "good citizen of the web" zu verhalten, ein Begriff, den Gary Illyes (Google) selbst verwendet hat. Der Googlebot will keine Server lahmlegen, weshalb er auf langsame Response-Zeiten und überlastete Infrastruktur mit reduzierten parallelen Requests reagiert.

Der Crawl Demand ist die inhaltliche Komponente: Was hält Google für interessant genug, um es regelmäßig erneut zu crawlen? Seiten mit häufigen Aktualisierungen, starkem Backlink-Profil und nachgewiesener Nutzerinteraktion generieren einen höheren Crawl Demand.

Beide Faktoren zusammen ergeben, wie viel Crawling deine Website pro Tag tatsächlich erhält. Die genauen Gewichtungen kennt niemand außerhalb von Google. Aber die Stellschrauben sind gut dokumentiert und damit steuerbar.

Ein konkretes Beispiel: Ein Nachrichtenportal mit täglich neuen Artikeln und stabiler Serverinfrastruktur bekommt von Googlebot regelmäßig Besuch, weil sowohl die Crawl Rate (schnelle Ladezeiten, kein Server-Stress) als auch der Crawl Demand (aktuelle Inhalte mit hoher Verlinkungsdichte) stimmen. Ein Onlineshop mit veralteten Produktbeschreibungen, langsamer Technik und tausenden Filter-URLs, die inhaltlich alle dasselbe zeigen, bekommt weniger, obwohl er deutlich mehr Seiten hat.

Abgrenzung zum Index Budget

Das Crawl Budget und das Index Budget sind zwei verschiedene Dinge, die häufig durcheinandergeworfen werden.

Gecrawlt ist nicht gleich indexiert. Google crawlt eine URL, bewertet sie und entscheidet dann, ob sie es in den Index schafft. Seiten mit dünnem Inhalt, redundanten Inhalten oder einem expliziten noindex-Tag werden gecrawlt, aber nicht indexiert. Das ist wichtig für die Optimierung, weil du Crawl-Ressourcen schonen kannst, ohne die Indexierung wertvoller Seiten zu gefährden.

Das Index Budget wird von Google nicht aktiv limitiert. Schlechte Qualität ist der häufigste Grund dafür, dass eine Seite gecrawlt, aber nicht aufgenommen wird. Wenn eine Website mit 10.000 URLs davon 30% fehlerhafte Weiterleitungsketten oder 404-Seiten enthält, verschwendet das einen erheblichen Teil des Crawl Budgets für URLs, die nie indexiert werden. Diese Ressourcen fehlen dann für die Inhalte, die tatsächlich relevant sind.

Technische Faktoren

Seitengeschwindigkeit und Serverperformance haben den direktesten Einfluss auf die Crawl Rate. Ein langsamer Server bedeutet weniger parallele Crawls. Tools wie Google PageSpeed Insights und die Google Search Console (Bereich Crawl-Statistiken) helfen, Engpässe zu identifizieren.

Interne Verlinkungsstruktur: Eine flache Architektur mit geringer Klicktiefe (idealerweise 3 bis 4 Klicks von der Startseite) ermöglicht es dem Crawler, wichtige Seiten schnell zu erreichen. Seiten ohne interne Verlinkung - sogenannte verwaiste Seiten - werden deutlich seltener gecrawlt, unabhängig davon, wie gut ihr Inhalt ist.

Duplicate Content und URL-Parameter: Session-IDs, Filterkombinationen, Tracking-Parameter, all das generiert neue URLs mit identischem oder nahezu identischem Inhalt. Googlebot crawlt diese URLs, findet keine neuen Informationen und verbraucht trotzdem Ressourcen. Das ist das klassische Crawl-Budget-Problem bei Onlineshops mit Faceted Navigation.

Core Web Vitals und Page Experience: Google hat bestätigt, dass Websites mit schlechten Nutzererfahrungswerten weniger Crawling-Ressourcen erhalten können. Seit der vollständigen Ablösung von FID durch INP (März 2024) gilt Interaction to Next Paint als Messgröße für Reaktionsfähigkeit. Das ist auch ein Signal, das in die Crawl-Rate-Gleichung einfließen kann.

Mobile-First-Indexierung: Google crawlt und bewertet primär die mobile Version einer Website. Seiten, die auf Mobilgeräten langsam laden oder schlecht strukturiert sind, haben entsprechend Nachteile, auch beim Crawl Budget.

Inhaltliche Faktoren

Aktualität steigert den Crawl Demand. Das ist kein Argument für Content um des Contents willen, aber ein guter Grund, bestehende Seiten zu pflegen, statt immer nur neue zu produzieren.

Backlinks: Seiten mit mehr externen Verlinkungen werden tendenziell häufiger gecrawlt. Das ist eine der Verbindungen zwischen Offpage SEO und technischem SEO, die in der Praxis oft unterschätzt wird.

Nutzerinteraktion: Häufig besuchte Seiten mit nachgewiesener Nutzerinteraktion generieren einen höheren Crawl Demand.

Das ist der Punkt, an dem viele Beiträge zum Thema zu viel Alarm schlagen. Für die meisten Websites ist das Crawl Budget kein praktisches Problem.

Für ein Beratungsunternehmen mit 50 Seiten, eine Arztpraxis mit einer lokalen Website oder einen freien Journalisten mit 200 Blogartikeln ist Crawl-Budget-Optimierung irrelevant. Das Budget ist dort in der Regel ausreichend für alle vorhandenen Inhalte.

Ab etwa 10.000 URLs - vor allem bei facettierter Navigation, vielen Sprachversionen oder regelmäßig ablaufenden Inhalten wie Events oder Stellenausschreibungen - lohnt sich ein genauerer Blick.

Technische Maßnahmen

Serverperformance verbessern: Caching-Mechanismen (z.B. Varnish, Redis), Bildkomprimierung, Minimierung von CSS/JS-Dateien erhöhen die Crawl Rate direkt, weil Googlebot mehr Seiten pro Zeiteinheit verarbeiten kann.

Canonical Tags und Parameter Handling: Duplicate Content durch korrekte Canonical Tags auszeichnen. URL-Parameter, die keinen eigenständigen Inhalt erzeugen (Tracking-Parameter, Session-IDs), gehören entweder per Canonical auf die kanonische URL verwiesen oder in der Google Search Console als unwichtig markiert.

Hreflang und internationale Websites: Fehlerhafte Hreflang-Tags führen zu unnötigen Crawls. Jede Sprachversion sollte korrekte Selbstreferenzierungen haben, x-default inklusive.

HTML-Dateigröße im Blick behalten: Im März 2026 hat Google im Search Central Blog offiziell bestätigt, dass Googlebot pro URL maximal 2 MB liest - exklusive PDFs, für die 64 MB gelten. Für die meisten Websites ist das kein Problem. Laut HTTP Archive Web Almanac 2025 liegt die mediane HTML-Dateigröße auf Mobilseiten bei rund 33 KB, also rund 60-mal unter diesem Limit. Wer jedoch stark aufgeblähte HTML-Seiten mit inline-eingebettetem JavaScript oder sehr langen Seiten mit viel Code hat, sollte prüfen, ob der relevante Inhalt innerhalb der ersten 2 MB steht.

Dazu kommt ein verwandtes Problem: Inhalte, die erst nach JavaScript-Ausführung sichtbar werden, haben schlechtere Chancen auf zuverlässige Indexierung. Googlebot crawlt zuerst, rendert nachgelagert – und manchmal gar nicht. Wer wichtige Inhalte hinter Lazy-Load-Konstrukten oder JS-Rendering versteckt, erschwert nicht nur die Indexierung durch Google, sondern auch durch AI-Crawler, die in der Regel kein JavaScript ausführen.

robots.txt vs. noindex: Ein häufiger Denkfehler

Hier passiert in der SEO-Praxis regelmäßig derselbe Fehler. Die beiden Mechanismen lösen unterschiedliche Probleme, und wer sie verwechselt, kann unbeabsichtigt das Gegenteil von dem erreichen, was er will.

robots.txt Disallow verhindert das Crawlen. Googlebot kommt gar nicht auf die Seite. Das spart Crawl Budget direkt. Es gibt jedoch eine wichtige Einschränkung: Eine per robots.txt gesperrte URL kann trotzdem im Index landen, wenn externe Seiten auf sie verlinken - weil Google die URL kennt, sie aber nicht crawlen kann, um den Inhalt zu prüfen. Das Ergebnis sind sogenannte URL-only-Einträge: Google zeigt die URL in den Suchergebnissen an, ohne Titel, ohne Description, ohne Snippet. Nicht schön, aber auch nicht leicht zu verhindern, solange externe Links auf diese URL zeigen.

noindex lässt Googlebot die Seite crawlen, verhindert aber die Aufnahme in den Index. Der Crawl-Aufwand entsteht trotzdem.

In der Praxis stellt sich die Frage meist nicht für frische URLs, sondern für Seiten, die längst im Index stehen - Filterkombinationen, Sortiervarianten, Parameter-URLs.

Für diese gilt eine klare Reihenfolge: Zuerst noindex setzen, warten bis Google de-indexiert hat, dann robots.txt Disallow ergänzen.

Andersherum funktioniert es nicht: Wenn robots.txt den Zugriff sperrt, bevor die Seite aus dem Index ist, sieht Googlebot das noindex-Tag nicht mehr und die Seite bleibt im Index stehen. Googles offizielle Crawl-Budget-Dokumentation empfiehlt robots.txt für wertlose URL-Varianten generell als das effizientere Mittel, aber eben erst dann, wenn die Seiten nicht mehr indexiert sind.

Inhaltliche und strukturelle Maßnahmen

Interne Verlinkung priorisieren: Wichtige Seiten sollten über Breadcrumbs, Footer-Links und kontextuelle Ankertexte erreichbar sein. Verwaiste Seiten - also Seiten ohne interne Verlinkung - werden deutlich seltener gecrawlt.

XML-Sitemap pflegen: In die Sitemap gehören ausschließlich indexierbare URLs. Keine Weiterleitungen, keine Canonical-Duplikate, keine noindex-Seiten, keine URLs mit 4xx- oder 5xx-Statuscodes. Tools wie Sitebulb oder Screaming Frog identifizieren solche Inkonsistenzen zuverlässig.

Content-Aktualisierungen einplanen: Bestehende Seiten mit aktualisiertem Datum und gepflegtem Inhalt (Statistiken, Produktpreise, Links) signalisieren Googlebot einen höheren Crawl Demand. Das gilt nicht nur für News-Seiten.

PubDate-Metadaten nutzen: Schema.org-Markup für Veröffentlichungs- und Aktualisierungsdaten gibt Googlebot und AI-Crawlern strukturierte Hinweise darauf, wann ein Inhalt zuletzt geändert wurde und erhöht damit den Crawl Demand für tatsächlich aktualisierte Seiten.

Monitoring

Die Google Search Console liefert die wichtigsten Metriken:

• Crawl-Statistiken (unter Einstellungen): Zeigt täglich gecrawlte Seiten und aufgetretene Fehler nach Crawler-Typ

• Indexabdeckungsbericht: Welche Seiten wurden gecrawlt, aber nicht indexiert?

• URL-Überprüfung: Liefert Informationen zu einzelnen URLs inklusive letztem Crawl-Zeitpunkt und gerenderte Seitenansicht

Für tiefergehende Analysen sind Server-Logfiles die direkteste Datenquelle. Der Screaming Frog Log File Analyser visualisiert Crawling-Muster und zeigt, welche URLs besonders häufig gecrawlt werden, welche Crawler Ressourcen verbrauchen und ob es ineffiziente Crawling-Pfade gibt. Für Enterprise-Websites empfehlen sich Splunk oder der ELK Stack. Die Google Search Analytics API bietet aggregierte Crawling-Daten als zusätzliche Analyseoption.

Das Crawl-Budget-Thema hat eine Dimension bekommen, die im SEO noch nicht überall angekommen ist.

Neben Googlebot crawlen inzwischen zahlreiche AI-Crawler regelmäßig das Web: GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot und andere. Laut Cloudflare-Daten ist der kombinierte AI- und Such-Crawler-Traffic von Mai 2024 bis Mai 2025 um 18% gestiegen. GPTBot allein wuchs in diesem Zeitraum um 305%. Diese Bots konkurrieren mit Googlebot um Serverressourcen - sie beanspruchen Kapazität, die nicht zum klassischen Google-Crawl-Budget beiträgt, aber die Serverperformance und damit die Crawl Rate für Googlebot beeinflussen kann.

Was das praktisch bedeutet: Wer viel AI-Crawler-Traffic hat und die Serverressourcen knapp sind, kann das Crawl Budget für Googlebot indirekt negativ beeinflussen. Die Steuerung erfolgt ebenfalls über robots.txt, mit separaten User-Agent-Einträgen für jeden Crawler. Google-Extended steuert das Crawling für Gemini-Training (unabhängig von Googlebot für die Search), GPTBot für OpenAI, Applebot-Extended für Apple Intelligence.

Das ist kein Aufruf, AI-Crawler pauschal zu sperren. Wer AI-Sichtbarkeit als Ziel hat, sollte diese Bots bewusst zulassen. Aber wer weiß, welche Crawler die eigene Website besuchen und welche Serverressourcen sie verbrauchen, kann gezielter steuern. Logfile-Analysen helfen dabei, Klarheit zu schaffen.

Die folgenden Daten stammen aus der Google Search Console eines Kunden - ein mittelgroßer Onlineshop, der nach technischen Umbauarbeiten wieder stabilisiert wird. Sitemaps mit fehlerhaften URLs, Filter ohne valide Endpunkte, viele URL-Änderungen durch eine zwischengeschaltete WaWi - das Übliche, wenn mehrere Systeme gleichzeitig angefasst werden. Der Shop ist noch nicht vollständig aufgeräumt, aber die Arbeit läuft.

Vier Auswertungen aus der GSC zeigen, wie sich das in den Daten niederschlägt.

Sitemap und Indexierung

Die Sitemap enthält 305.119 erkannte URLs. Tatsächlich indexiert sind 127.552 - das entspricht einer Indexierungsrate von rund 42%. Google kennt insgesamt 463.094 weitere URLs, hat sie gecrawlt, aber aus 13 verschiedenen Gründen nicht in den Index aufgenommen. Das ist ein direktes Abbild der technischen Situation: Fehlerhafte URLs in der Sitemap, Filtervarianten ohne eigenständigen Inhalt, Weiterleitungsprobleme aus der Umbauphase.

Dieser Abstand zwischen erkannten und indexierten URLs ist auch ein gutes Argument gegen die verbreitete Annahme, dass mehr URLs in der Sitemap automatisch mehr Indexierung bedeuten. Sie signalisieren nur, wo eine Suchmaschine hinschauen soll. Google entscheidet selbst, was davon übernommen wird.

Crawling-Statistiken und Reaktionszeit

Die Crawling-Statistiken zeigen 1,09 Millionen Crawling-Anfragen im betrachteten Zeitraum bei einer durchschnittlichen Reaktionszeit von 604 ms. Das ist der aktuelle Stand nach der Stabilisierung, nicht die schlechteste Phase während der Umbauarbeiten.

604 ms ist zu langsam. Googles eigene Empfehlungen liegen unter 200 ms. Im Chart ist die Konsequenz direkt ablesbar: Die Crawling-Anfragen gehen über den gesamten Zeitraum zurück. Google drosselt die Crawl Rate als Reaktion auf die Serverperformance - genau der Mechanismus, der oben unter „Crawl Rate" beschrieben ist.

Warum ist die Reaktionszeit so hoch? Der Shop wurde mehrfach angegriffen. Als Reaktion laufen restriktive Firewall-Regeln, und das gesamte Security-Setup kostet Performance. Das ist ein Trade-off, den viele Shop-Betreiber kennen: Sicherheit gegen Crawl-Geschwindigkeit. Es gibt keine einfache Antwort - aber wer den Zusammenhang kennt, kann wenigstens eine bewusste Entscheidung treffen, statt beide Probleme getrennt zu betrachten und sich zu wundern, warum der Googlebot seltener kommt.

Indexierungsverlauf

Der Indexierungsverlauf zeigt über den gesamten Zeitraum eine leicht sinkende Kurve bei den indexierten Seiten.

Das ist die langfristige Folge aus reduziertem Crawling, technischen Fehlern in der Umbauphase und einer Sitemap, die URLs enthielt, die Google nicht sinnvoll verarbeiten konnte.

Crawling-Detailauswertung: Weiterleitungen, Dateitypen, Ressourcen

Die Detailauswertung nach Antworttypen, Dateitypen, Zweck und Googlebot-Typ liefert weitere konkrete Hinweise auf offene Baustellen.

93% der Crawling-Anfragen werden mit 200 beantwortet - das ist erstmal in Ordnung.

Aber 5% der Non-200 Antworten sind 302-Weiterleitungen (vorübergehend verschoben). Bei 1,09 Millionen Gesamtanfragen entspricht das rund 54.500 Anfragen, bei denen Google eine temporäre Weiterleitung sieht. Das Problem: 302 signalisiert, dass die Verschiebung vorübergehend ist, Google also die ursprüngliche URL lange Zeit weiter für relevant hält und crawlt. Bei dauerhaften URL-Änderungen - wie hier durch das Setup verursacht - sollten das 301-Weiterleitungen sein. Die Lösung ist bekannt, die technische Umsetzung läuft.

Auffälliger ist der Dateityp-Split: 46% HTML, 45% JSON. Auf einem Shop entspricht das einer faktischen Gleichverteilung zwischen Seiteninhalt und JSON-Ressourcen.

Das deutet auf offen zugängliche API-Endpunkte oder JSON-Datenfeeds hin, die Googlebot mitcrawlt, ohne dass das irgendeinen Indexierungsnutzen hat. Ob es sich um Warenwirtschafts-Feeds, eine JavaScript-lastige Frontend-Architektur oder offen erreichbare API-Routen handelt, wird gerade in Abstimmung mit dem technischen Dienstleister geklärt - in der Praxis eine Aufgabe, bei der man auf vollständige Informationen angewiesen ist, die nicht immer schnell fließen. Die Konsequenz jedenfalls ist klar: Fast die Hälfte des Crawl Budgets fließt in Ressourcen ohne Indexierungsrelevanz.

Der Googlebot-Typ-Split bestätigt das: 45% Smartphone, 44% Laden der Seitenressource. Google gibt annähernd gleich viel Budget für das Crawlen von Seiteninhalten und das Laden von Ressourcen für das Rendering aus.

Das hängt stark von der Shop-Plattform ab und ist strukturell schwer zu ändern. Es zeigt aber, warum das Verschlanken des Templating, das parallel geprüft wird, am Ende mehr bewirken könnte als einzelne Performance-Maßnahmen.

Die Arbeit läuft: Sitemap bereinigt, fehlerhafte URL-Strukturen werden schrittweise korrigiert, 302- in 301-Weiterleitungen umgestellt, JSON-Endpunkte unter die Lupe genommen. Realistischer Zeithorizont bis zur vollständigen Bereinigung: Ende des Jahres. So sieht technisches SEO in der Praxis aus - manchmal leider kein Quick Fix, sondern ein strukturierter Prozess über mehrere Monate.

Technische Schulden dieser Art erledigen sich nicht von alleine. Solange der Shop läuft und der Umsatz stimmt, fühlt sich das Thema nicht dringend an - es ist aber eine unsichtbare Bremse, die weitere Fortschritte kosten kann. Ranking-Potenzial, das nicht ausgeschöpft wird, weil Google schlicht nicht oft genug hinschaut.

Das Crawl Budget ist kein abstrakt-technisches Konzept, das nur für Großkonzerne relevant ist. Aber es ist auch kein Thema, das jede Website betrifft. Die ehrliche Einordnung: Für Websites unter 1.000 bis 2.000 Seiten ohne technische Duplikat-Probleme gibt es größere Baustellen im SEO. Ab 10.000 URLs, vor allem bei E-Commerce mit facettierter Navigation oder Portalen mit laufend ablaufenden Inhalten, kann ein schlecht genutztes Crawl Budget direkte Folgen für die Indexierungstiefe haben.

Die wichtigsten Maßnahmen in der Zusammenfassung:

1. Regelmäßige technische Audits: Wo verbraucht Googlebot Ressourcen, die nichts bringen?

2. Interne Verlinkung: Wichtige Seiten müssen erreichbar sein – nicht nur theoretisch vorhanden

3. robots.txt und Canonical richtig einsetzen: Der Unterschied zwischen beiden ist entscheidend und wird zu oft falsch gemacht

4. Serverperformance: Schnelle Server werden öfter gecrawlt – das ist so einfach, wie es klingt

5. Monitoring: Search Console und Logfiles zeigen, was wirklich passiert

Und seit Anfang 2026 kommt eine weitere Aufgabe dazu: AI-Crawler im Blick behalten, ihre Serverbelastung einschätzen und die Steuerung via robots.txt aktiv angehen. Das ist kein Krisenmanagement, sondern Teil einer sauberen technischen SEO-Grundlage.

Crawl-Budget-Probleme fallen oft erst auf, wenn Rankings wegbrechen. Ich schaue mir an, wo dein Googlebot-Budget tatsächlich hinfließt. Erstgespräch buchen →