Irgendwo auf Seite 47.000 eines Crawl-Reports habe ich ernsthaft über einen Karrierewechsel nachgedacht. Die Website, ein großer britischer E-Commerce-Katalog mit etwa 91.000 indexierbaren URLs, war für sechs Monate bei ungefähr 34.000 indizierten Seiten stehen geblieben. Kein Wachstum. Der Mandant war überzeugt, dass etwas "kaputtgegangen" sei. Ich sagte ihm, dass nichts kaputt war. Ich hatte halb recht.
Wichtigste Erkenntnis: Bei einer 91.000-Seiten-Website crawlt Googlebot das, was deine Architektur ihm vorgibt: interne Verlinkung, Sitemap-Disziplin und die Beseitigung von Verschwendung entscheiden, welche Seiten indexiert werden.
Dieses Projekt hat verändert, wie ich über Crawl-Budget denke. Nicht die Theorie – ich hatte die Google-Dokumentation gelesen, ich hatte die Search-Central-Videos angesehen, ich wusste, was Crawl-Budget war. Aber es zu kennen und es tatsächlich im großen Maßstab zu verwalten, sind zwei völlig unterschiedliche Dinge. Was folgt, ist alles, was ich mir selbst gesagt hätte, wenn ich zu jenem Dienstagmorgen im März 2022 zurückgehen könnte, als ich zum ersten Mal die Crawl-Statistiken in Google Search Console abrief und mir der Magen umdrehte.
Was Crawl-Budget wirklich bedeutet (und was nicht)
Das ist das, das Menschen ständig verwirrt: Crawl Budget bedeutet nicht „die Anzahl der Seiten, die Google je für dich indexiert". Es bedeutet ungefähr die Anzahl der URLs, die Googlebot innerhalb eines bestimmten Crawl-Fensters abruft, wobei Google selbst diesen Zeitraum als Kombination aus Crawl-Ratelimit und Crawl-Nachfrage definiert.
Crawl-Ratenlimit ist, wie schnell Googlebot crawlen kann, ohne deinen Server zu überlasten. Crawl-Nachfrage ist, wie viel Google crawlen möchte, angetrieben von der Beliebtheit deiner URLs und wie oft sie sich ändern. Multipliziere diese beiden Hebel miteinander und du hast einen groben Eindruck davon, wie viel Crawl-Aufmerksamkeit deine Website erhält.
Für die meisten Sites mit unter 1.000 Seiten ist das irrelevant. Google wird alles crawlen. Aber sobald du im Zehntausender-Bereich bist, und absolut sobald du sechsstellig wirst, trifft Googlebot Entscheidungen. Es wird priorisieren. Es wird ignorieren. Und wenn du es nicht darauf eingestellt hast, die richtigen Dinge zu priorisieren, wird es sich fröhlich die Zeit nehmen, deine Session-ID-Parameter-URLs und deine gefilterten Facetten-Seiten zu crawlen, während deine neuen Produktstarts wochenlang unbemerkt bleiben.
Das ist keine Hypothese. Das ist genau das, was bei dem 91.000-Seiten-Projekt passiert ist.
Das Faceted-Navigation-Problem, das mir niemand gewarnt hat
Faceted Navigation ist der größte Crawl-Budget-Killer, dem ich bei großen Websites begegnet bin. Konsistent. Jedes Mal.
Die Katalog-Website hatte ein facettiertes Filtersystem – Farbe, Größe, Material, Marke – ohne irgendwo konfiguriertes URL-Parameter-Handling. Jede Filterkombination generierte eine einzigartige URL. Du konntest "blau", "mittel", "Baumwolle" und "BrandX" auswählen und bekamst /shop?colour=blue&size=medium&material=cotton&brand=brandx. Dann drehte jemand die Reihenfolge um und bekam /shop?size=medium&colour=blue&brand=brandx&material=cotton. Unterschiedliche URL, identischer Inhalt.
Ich führte einen Screaming Frog-Crawl durch (Version 18, die JavaScript-Rendering viel besser handhabt als ältere Versionen) und fand über 200.000 URLs, die allein vom Filtersystem generiert wurden. Googlebot besuchte diese. Ständig. Während tausende legitime Produktseiten nicht indexiert waren.
Die Lösung, die tatsächlich funktionierte
Wir haben das in zwei Phasen angepackt. Zuerst habe ich das URL-Parameter-Handling in Google Search Console konfiguriert und die Filter-Parameter als "Ändert nicht den Seiteninhalt" gekennzeichnet, um Googlebot zu signalisieren, dass es konsolidieren soll. Zweiten und wichtiger: Das Entwickler-Team implementierte eine richtige Canonical-Strategie, die alle Filterkombinationen zurück auf die Basis-Kategorieseite verweist. Wir haben auch noindex zu niedrigwertigen gefilterten Seiten hinzugefügt, die nicht praktisch kanonisiert werden konnten.
Nach etwa acht Wochen begann die Anzahl der indizierten Seiten zu wachsen. Nicht explosiv, sondern stetig. Was eigentlich das ist, das du willst. Ein plötzlicher Anstieg bei indizierten Seiten kann manchmal eine Neubewertung durch Google auslösen, anstelle eines klaren Erfolgs.
Crawl-Statistiken in der Search Console: Die Daten, die die meisten Menschen ignorieren
Ich habe in den letzten drei Jahren knapp 80 Sites speziell auf Crawl-Probleme überprüft. Vielleicht 15% der Leute, die mir diese Sites anvertraut haben, hatten je den Crawl Stats Report in Search Console angeschaut. Diese Quote sollte viel höher sein.
Der Crawl-Stats-Report zeigt dir durchschnittliche Crawl-Anfragen pro Tag, durchschnittliche Antwortzeit und vor allem, was Googlebot wirklich crawlt, aufgeschlüsselt nach Zweck (Discovery vs. Refresh). Wenn deine "Refresh"-Crawls dominieren und Discovery-Crawls kaum vorkommen, verbringt Google seine Zeit damit, bekannte Seiten erneut zu überprüfen. Nicht damit, neue zu finden. Das deutet darauf hin, dass deine interne Verlinkung wahrscheinlich schlecht strukturiert ist oder deine XML-Sitemap nicht funktioniert.
Bei dem 91.000-Seiten-Projekt lag ich bei ungefähr 2.400 Crawl-Anfragen pro Tag. Für eine Website dieser Größe bedeutet das, dass Google theoretisch etwa 38 Tage bräuchte, um alles einmal zu crawlen, angenommen jede Anfrage träfe auf eine einzigartige, nützliche Seite. Das war nicht der Fall. Ungefähr 40% der Crawl-Anfragen trafen auf Umleitungsketten oder parameter-aufgeblähte Duplikate.
Durchschnittliche Antwortzeit ist wichtiger als du denkst
Eine Sache, die ich früher in meiner Karriere unterschätzt habe: Googlebot reagiert wirklich empfindlich auf Server-Geschwindigkeit. Nicht in einer Ranking-Art (naja, nicht direkt), sondern in einer Crawl-Bereitschafts-Art. Langsame Server führen dazu, dass Googlebot abbaut. Google reduziert seine Crawl-Rate, um zu vermeiden, dass ein kämpfender Server belastet wird.
Die Katalog-Website hatte eine Time to First Byte von ungefähr 1,8 Sekunden auf Kategorieseiten während Spitzenverkehr. Nachdem der Kunde von Shared Hosting zu einem dedizierten VPS mit ordnungsgemäßem Caching umzog (WP Rocket für Page Caching, Redis für Object Caching), fiel die TTFB unter 400ms. Die Crawl-Anfragen pro Tag stiegen über die folgenden sechs Wochen merklich an. Korrelation natürlich, aber ich habe dieses Muster zu oft gesehen, um es abzutun.
XML-Sitemaps: Behandle sie nicht wie eine Formalität
Die meisten Sitemaps, die ich übernehme, sind falsch. Nicht dramatisch falsch, nur ruhig, nutzlos falsch.
Häufige Probleme, die ich sehe:
- Seiten in der Sitemap, die 404s oder 301-Weiterleitungen zurückgeben
- Noindexierte Seiten in der Sitemap enthalten (das verwirrt Googlebot – du sagst gleichzeitig „crawle das" und „indexiere das nicht")
- <lastmod>Daten, die statisch oder einfach falsch sind
- Sitemaps mit 70.000+ URLs in einer einzelnen Datei (das Limit liegt bei 50.000 pro Datei, und große Dateien verlangsamen die Verarbeitung)
- Keine Sitemap-Index-Datei, nur ein monolithischer XML-Blob
Bei dem großen Katalog-Projekt enthielt die Sitemap 91.000 URLs in einer einzelnen Datei. Sie enthielt auch jede gefilterte URL, die je generiert worden war – über 40.000 davon waren noindexiert. Googlebot verarbeitete diese riesige Datei und stellte dann fest, dass die meisten URLs ohnehin nicht gecrawlt werden sollten. Verschwendetes Signal auf beiden Seiten.
Wir haben die Sitemap-Architektur als richtige Sitemap-Index umgebaut, die auf segmentierte untergeordnete Sitemaps verweist: eine für Kernkategorie-Seiten, eine für Produktseiten (aufgeteilt in zwei Dateien aufgrund des Volumens), eine für redaktionelle Inhalte. Jede Datei unter 40.000 URLs. <lastmod>Werte werden dynamisch aus dem tatsächlichen Änderungsdatum in der Datenbank generiert. Keine noindexierten Seiten, keine Weiterleitungen.
Die Daten aus Bing Webmaster Tools (ja, es lohnt sich zu prüfen – Bing zeigt dir manchmal Crawl-Verhaltensmuster, die auf Strukturprobleme hindeuten, die Google auch hat) zeigten eine Verringerung der Sitemap-Verarbeitungszeit um über 60%.
Interne Verlinkung: Der Hebel, den du tatsächlich kontrollierst
Das ist etwas, das ich wirklich erst zu schätzen wusste, als Seahawk 2020 eine große Content-Website mit etwa 65.000 Artikeln für einen Media-Kunden übernahm. Die Website hatte Crawl-Budget-Probleme, obwohl sie eine korrekt formatierte Sitemap und eine saubere URL-Struktur hatte. Das Problem war die interne Verlinkungstiefe. Tausende von Artikeln waren praktisch verwaist – es führten keine internen Links von einer gecrawlten Seite auf sie hin.
Googlebot folgt nicht nur Sitemaps. Es folgt Links. Wenn eine Seite nur durch einen Sitemap-Eintrag auffindbar ist und null interne Links hat, wird sie deprioritisiert. Das ist nicht offiziell in klaren Begriffen dokumentiert, aber Googles eigene Richtlinien zum Internal Linking machen deutlich, dass crawlbare Links von wichtigen Seiten das sind, wie Googlebot die Entdeckung priorisiert.
Bei jenem Medien-Client haben wir interne Links mit dem Site Audit Tool von Ahrefs geprüft und etwa 12.000 Artikel identifiziert, auf die drei oder weniger interne Links verwiesen. Wir haben einen automatisierten "Ähnliche Artikel"-Block in das CMS (WordPress, Custom Gutenberg Block) integriert, der kontextuell ähnliche Inhalte heranzog. Im darauffolgenden Quartal stieg die Anzahl der indexierten Seiten auf dieser Domain von 41.000 auf über 58.000. Gleiche Domain Authority. Gleiche Content-Produktionsrate. Nur bessere interne Verlinkung.
Der nummerierte Ansatz, den ich jetzt bei jedem großen Site Audit verwende:
- Einen vollständigen Screaming Frog Crawl durchführen und interne Link-Daten exportieren
- Jede Seite identifizieren, die weniger als drei eingehende interne Links hat
- Kreuztabelliere mit Seiten, die gut verlinkt sind, um thematische Cluster zu identifizieren
- Kontextuelle interne Links von hochfrequentierten Seiten hinunter zu den schwach verlinkten Seiten aufbauen
- Validiere im URL-Inspektions-Tool der Search Console, dass neu verlinkte Seiten vom Status „Entdeckt, wird derzeit nicht indexiert" zu „Gecrawlt" wechseln
Dieser Status „Entdeckt, wird derzeit nicht indexiert" in der Search Console ist dein Kanarienvogel. Das bedeutet, Google kennt die Seite, hat das Abrufen aber nicht priorisiert. Die Verbesserung interner Links ist normalerweise der schnellste Weg, das zu beheben.
Log-Datei-Analyse: Unbequem, aber notwendig
Ehrlich gesagt habe ich Log-Datei-Analyse Jahre lang vermieden. Es wirkte wie unnötige Tiefe, wenn Crawl-Tools dir ohnehin das meiste gaben. Ich lag daneben.
Log-Dateien zeigen dir, was Googlebot tatsächlich getan hat – nicht was du aus deiner Sitemap oder deinem Crawl-Tool ableitest. Bei einem Projekt mit einer SaaS-Firma mit etwa 8.000 Seiten zur Produktdokumentation enthüllte die Log-Analyse, dass Googlebot fast 30% seiner Crawl-Zeit auf /wp-admin/-adjacent URLs und Admin-seitige Assets verschwendete, die in robots.txt hätten blockiert werden sollen. Niemand hatte das ordnungsgemäß eingerichtet. Dokumentationsseiten, die vier Monate lang nicht gecrawlt worden waren.
Screaming Frog's Log File Analyser ist das Tool, das ich nutze. Es ist nicht elegant, aber zuverlässig. Importiere deine Server-Logs, filtere nach dem Googlebot-User-Agent und sortiere nach URL-Zugriffshäufigkeit. Die Muster, die sich zeigen, sind fast immer aufschlussreich – und enthalten fast immer etwas, das crawlt, was nicht crawlen sollte.
Wann du dir Sorgen machen solltest und wann du es sein lässt
Nicht jede große Website braucht aggressives Crawl-Budget-Management. Wenn du 10.000 Seiten hast und 9.800 indexiert sind, fange nicht an, Hebel umzulegen. Du wirst Probleme schaffen, wo es keine gibt.
Crawl-Budget-Management wird wirklich wertvoll für dich, wenn:
- Du mehr als ~15.000 indexierbare Seiten hast
- Deine indexierte Anzahl ist trotz neuer hinzugefügter Inhalte stagniert
- Crawl Stats zeigt durchschnittliche Crawl-Anfragen, die deutlich unter dem liegen, was du für dein Seiten-Volumen erwartest
- Du siehst Tausende von URLs im Status „Entdeckt, derzeit nicht indexiert" oder „Gecrawlt, derzeit nicht indexiert"
Dieser zweite Status, „Gecrawlt, derzeit nicht indexiert", ist anders und verdient es, separat betrachtet zu werden. Er bedeutet, dass Google die Seite abgerufen hat und sich entschied, sie nicht zu indexieren, meist wegen dünnem Inhalt oder ähnlichen Inhalten. Keine noch so gute Crawl-Budget-Optimierung behebt ein Qualitätsproblem.
---
FAQ
Wirkt sich das Crawl-Budget auf kleine Websites aus?
Selten auf sinnvolle Weise. Wenn deine Website weniger als 1.000 Seiten hat und schnell lädt, wird Google sie fast sicher vollständig crawlen, unabhängig davon. Crawl-Budget wird zu einem echten Problem in größerem Maßstab, typischerweise ab 10.000 bis 15.000 Seiten, oder auf Websites, wo ein großer Teil der URLs dynamisch generiert wird.
Behebt das direkte Einreichen einer Sitemap die Crawl-Budget-Probleme?
Nein. Eine Sitemap hilft bei der Entdeckung, sie sagt Google, dass diese URLs existieren. Aber wenn deine Website strukturelle Probleme hat (Faceted-Navigation-Spam, langsame Server-Antwort, flache interne Verlinkung), wird eine Sitemap diese Signale nicht überschreiben. Denk an eine Sitemap als Vorschlag, nicht als Befehl.
Wie überprüfe ich, ob Googlebot Crawl-Budget für Junk-URLs verschwendet?
Beginne mit dem Bericht „Crawl-Statistiken" in Google Search Console und schau dir an, welche URL-Typen die meisten Anfragen erhalten. Überprüfe dann den Screaming Frog-Crawl, um hochvolumige URL-Muster zu identifizieren, die Duplikate sind, noindex haben oder wenig Wert bieten. Eine Log-Datei-Analyse gibt dir das präziseste Bild, wenn du Zugriff auf Server-Logs hast.
Sollte ich `noindex` oder `robots.txt disallow` verwenden, um das Crawl-Budget zu sparen?
Unterschiedliche Tools für unterschiedliche Aufgaben. Disallow in robots.txt hindert Googlebot daran, die Seite überhaupt zu fetchen, spart Crawl-Budget, aber Google kann keine Signale auf dieser Seite lesen. Noindex erlaubt Google, die Seite zu fetchen, sagt ihr aber, die Seite nicht in die Suchergebnisse aufzunehmen. Für Crawl-Budget speziell ist disallow effektiver bei wirklich minderwertigen URLs (Admin-Pfade, interne Suchergebnisse). Für gefilterte Facet-Seiten, bei denen du möchtest, dass Google den Inhalt versteht, aber nicht indexiert, ist noindex mit einem Canonical meist die richtige Wahl.
Was ist ein realistischer Zeitrahmen, um Verbesserungen nach der Behebung von Crawl-Budget-Problemen zu sehen?
Ehrlich gesagt hängt es von deiner Crawl-Rate ab. Bei dem 91.000-Seiten-Projekt dauerte es etwa sechs bis acht Wochen, bis sinnvolle Bewegungen in den indexierten Seitenzahlen nach der Bereitstellung der großen Fixes sichtbar wurden. Erwarte keine Änderungen über Nacht, Googlebot muss neu crawlen, neu bewerten, und die Indexierungs-Pipeline hat ihre eigene Latenz obendrauf.
---
Das 91.000-Seiten-Projekt endete gut. Die indexierten Seiten stiegen innerhalb von fünf Monaten von 34.000 auf knapp 71.000. Nicht perfekt, es gab wirklich dünne Produktseiten, die nicht indexiert werden sollten, aber der Inhalt, der zählte, wurde gefunden. Der Klient stellte auf, zu fragen, ob etwas kaputt war. Und ich hörte auf, Karrierewechsel um Seite 47.000 der Crawl-Reports ins Auge zu fassen. Größtenteils.
Weiterführende Lektüre: KI-gestützte Keyword-Recherche 2026: was es ist, warum traditi, 301 vs 302 Redirects: Welche Art ist für SEO wichtig, und LSI-Keywords 2026: was sie sind, was sie nicht sind, was.