Irgendwo um Seite 47.000 eines Crawl-Reports habe ich ernsthaft einen Jobwechsel in Betracht gezogen. Die Website – ein großer britischer E-Commerce-Katalog mit rund 91.000 indexierbaren URLs – war seit sechs Monaten bei etwa 34.000 indizierten Seiten stehen geblieben. Kein Wachstum. Der Kunde war überzeugt, dass etwas „kaputt" war. 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.On a 91,000-page site Googlebot crawls what your architecture tells it to: internal linking, sitemap discipline, and killing waste decide which pages get indexed.
Dieses Projekt hat meine Sicht auf Crawl Budget grundlegend verändert. Nicht die Theorie – ich hatte die Google-Dokumentation gelesen, ich hatte die Search Central Videos geschaut, 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. Das Folgende ist alles, was ich mir selbst sagen würde, wenn ich zu jenem Dienstagmorgen im März 2022 zurückgehen könnte, als ich die Crawl-Statistiken in Google Search Console das erste Mal abrief und mir das Herz in die Hose rutschte.was. But knowing it and actually managing it at scale are two wildly different things. What follows is everything I'd tell myself if I could go back to that Tuesday morning in March 2022 when I first pulled the crawl stats in Google Search Console and felt my stomach drop.
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.fetch within a given crawl window, which Google itself defines as a combination of crawl rate limit and crawl demand.
Crawl-Rate-Limit ist die Geschwindigkeit, mit der Googlebot crawlen kann, ohne deinen Server zu überlasten. Crawl-Demand ist, wie viel Google crawlen möchte – getrieben von der Beliebtheit deiner URLs und wie oft sie sich ändern. Multiplizierst du diese beiden Hebel miteinander, hast du einen groben Eindruck davon, wie viel Crawling-Aufmerksamkeit deine Website bekommt.wants to crawl -- driven by how popular your URLs are and how often they change. Multiply those two levers together and you have a rough sense of how much crawling attention your site gets.
Für die meisten Websites unter 1.000 Seiten ist das irrelevant. Google wird alles crawlen. Aber sobald du im fünfstelligen Bereich bist – und absolut, sobald du sechs Ziffern überschreitest – trifft Googlebot Entscheidungen. Es wird priorisieren. Es wird ignorieren. Und wenn du es nicht so eingerichtet hast, dass es die richtigen Inhalte priorisiert, wird es fröhlich seine Zeit damit verbringen, deine Session-ID-Parameter-URLs und deine gefilterten Facet-Seiten zu crawlen, während deine neuen Produkteinführungen 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.
Der Katalog hatte ein facettiertes Filtersystem – Farbe, Größe, Material, Marke – ohne irgendwo konfigurierte URL-Parameter-Behandlung. Jede Filterkombination erzeugte eine eindeutige URL. Du konntest „blau", „mittel", „Baumwolle" und „MarkX" auswählen und erhielt /shop?colour=blue&size=medium&material=cotton&brand=brandx. Dann vertauschte jemand die Reihenfolge und erhielt /shop?size=medium&colour=blue&brand=brandx&material=cotton. Andere URL, identischer Inhalt./shop?colour=blue&size=medium&material=cotton&brand=brandx. Then someone flipped the order and got/shop?size=medium&colour=blue&brand=brandx&material=cotton. Different URL, identical content.
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 lösten das in zwei Phasen. Zuerst konfigurierte ich die URL-Parameter-Behandlung in Google Search Console – ich kennzeichnete die Filter-Parameter als „Ändert den Seiteninhalt nicht", um Googlebot zu signalisieren, dass es konsolidieren soll. Zweitens, und wichtiger, implementierte das Dev-Team eine ordentliche Canonical-Strategie, die alle Filter-Kombinationen zurück auf die Basis-Kategorieseite wies. Wir fügten auch noindex zu gering-wertigen gefilterten Seiten hinzu, die nicht praktisch kanonisiert werden konnten.noindex to low-value filtered pages that couldn't practically be canonicalised.
Nach etwa acht Wochen begann die Anzahl der indizierten Seiten zu steigen. Nicht explosionsartig – stetig. Was ist eigentlich das, das du willst. Ein plötzlicher Anstieg der indizierten Seiten kann manchmal eine erneute Bewertung durch Google auslösen, statt einen sauberen Sieg zu erzielen.
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.Crawl Stats report in Search Console. That number should be much higher.
Der Crawl-Stats-Report zeigt dir die durchschnittliche Anzahl von Crawl-Anfragen pro Tag, die durchschnittliche Antwortzeit und – entscheidend – was Googlebot tatsächlich crawlt, aufgeschlüsselt nach Zweck (Discovery vs. Refresh). Wenn deine „Refresh"-Crawls dominieren und Discovery-Crawls minimal sind, verbringt Google seine Zeit damit, Seiten erneut zu überprüfen, die es bereits kennt. Nicht, um neue zu finden. Das ist ein Signal, dass deine interne Verlinkung wahrscheinlich flach ist oder deine XML-Sitemap nichts Nützliches tut.
Bei dem 91.000-Seiten-Projekt hatten wir etwa 2.400 Crawl-Anfragen pro Tag. Für eine Website dieser Größe bedeutet das, dass Google theoretisch etwa 38 Tage brauchen würde, um alles einmal zu crawlen – vorausgesetzt, jede Anfrage trägt eine eindeutige, nützliche Seite. Das war nicht der Fall. Etwa 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 leise, nutzlos falsch.
Häufige Probleme, die ich sehe:
- Seiten in der Sitemap, die 404s oder 301-Weiterleitungen zurückgeben
- Seiten mit Noindex in der Sitemap enthalten (das verwirrt Googlebot – du sagst gleichzeitig „crawl das" und „indexiere das nicht")
<lastmod>Daten, die statisch oder einfach falsch sinddates that are static or just wrong- 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 hatte die Sitemap 91.000 URLs in einer einzigen Datei. Sie enthielt auch jede gefilterte URL, die je generiert worden war – über 40.000 davon mit Noindex. 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.<lastmod>values dynamically generated from the actual last-modified date in the database. No noindexed pages, no redirects.
Die Bing Webmaster Tools Daten (ja, es lohnt sich zu prüfen – Bing zeigt dir manchmal Crawl-Verhaltensmuster, die auf strukturelle Probleme hindeuten, die Google auch hat) zeigten, dass die Sitemap-Verarbeitungszeit um über 60% sank.
Interne Verlinkung: Der Hebel, den du tatsächlich kontrollierst
Hier ist etwas, das ich wirklich erst schätzte, als Seahawk 2020 eine große Content-Website – etwa 65.000 Artikel – für einen Media-Client übernahm. Die Website hatte Crawl-Budget-Probleme, obwohl sie eine gut formatierte Sitemap und eine saubere URL-Struktur hatte. Das Problem war die interne Linking-Tiefe. Tausende von Artikeln waren faktisch verwaist – keine internen Links wiesen 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.only follow sitemaps. It follows links. If a page is only discoverable through a sitemap entry and has zero internal links, it gets deprioritised. That's not officially documented in crisp terms, but Google's own guidance on internal linking makes clear that crawlable links from important pages are how Googlebot prioritises discovery.
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.WordPress, custom Gutenberg block) that pulled contextually similar content. Over the following quarter, indexed pages on that site climbed from 41,000 to over 58,000. Same domain authority. Same content production rate. Just better internal linking.
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
- Abgleich mit gut verlinkten Seiten – finde thematische Clusterare well-linked -- find topical clusters
- Kontextuelle interne Links von hochfrequentierten Seiten hinunter zu den schwach verlinkten Seiten aufbauen
- Überprüfe in Search Console im URL-Inspektionstool, dass neu verlinkte Seiten von „Entdeckt – derzeit nicht indexiert" zu „Gecrawlt" wechseln
Dieser Status „Entdeckt – derzeit nicht indexiert" in Search Console ist dein Kanarienvogel. Er bedeutet, dass Google die Seite kennt, aber das Abrufen nicht priorisiert hat. Die Verbesserung interner Links ist normalerweise der schnellste Weg, um es zu beheben.
Log-Datei-Analyse: Unbequem, aber notwendig
Um ehrlich zu sein – Log-Datei-Analyse ist etwas, das ich Jahre lang vermied. Es fühlte sich wie unnötige Tiefe an, wenn Crawl-Tools dir das meiste gaben, das du brauchtest. Ich lag falsch.
Log-Dateien zeigen dir, was Googlebot tatsächlich getan hat, nicht was du aus deiner Sitemap oder deinem Crawl-Tool inferierst. Bei einem Projekt – ein SaaS-Unternehmen mit etwa 8.000 Product-Documentation-Seiten – zeigte Log-Analyse, dass Googlebot fast 30% seiner Crawl-Zeit auf /wp-admin/-angrenzende URLs und Admin-seitige Assets verbrachte, die in robots.txt hätten blockiert werden sollen. Niemand hatte das richtig eingerichtet. Documentation-Seiten, die vier Monate lang nicht gecrawlt worden waren.actually did, not what you infer it did from your sitemap or crawl tool. On one project -- a SaaS company with about 8,000 product documentation pages -- log analysis revealed Googlebot was spending nearly 30% of its crawl time on/wp-admin/adjacent URLs and admin-side assets that should have been blocked in robots.txt. Nobody had set that up properly. Documentation pages that hadn't been crawled in four months.
Screaming Frog's Log File Analyser ist das Tool, das ich nutze. Es ist nicht glamourös, aber zuverlässig. Importiere deine Server-Logs, filtere nach dem Googlebot User Agent und sortiere nach URL-Hit-Häufigkeit. Die Muster, die sich zeigen, sind fast immer aufschlussreich – und enthalten fast immer etwas, das crawlen sollte. is the tool I use. It's not glamorous but it's reliable. Import your server logs, filter by Googlebot user agent, and sort by URL hit frequency. The patterns that emerge are almost always illuminating -- and almost always include something crawling that shouldn't be.
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 „Discovered -- currently not indexed" oder „Crawled -- currently not indexed"
Dieser zweite Status – „Crawled -- currently not indexed" – ist anders und wert, separat behandelt zu werden. Das bedeutet, Google hat die Seite abgerufen und entschieden, sie nicht zu indexieren, meist wegen Thin Content oder Near-Duplicate-Problemen. Keine Menge an Crawl-Budget-Optimierung behebt ein Qualitätsproblem.
---
FAQ
Wirkt sich das Crawl-Budget auf kleine Websites aus?
Selten auf bedeutungsvolle Weise. Wenn deine Website unter 1.000 Seiten hat und schnell lädt, wird Google mit hoher Wahrscheinlichkeit alles crawlen, unabhängig davon. Crawl Budget wird zu einem echten Problem im großen Maßstab – typischerweise ab 10.000 bis 15.000 Seiten oder auf Websites, bei denen 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. Denke 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?
Verschiedene Tools für verschiedene Aufgaben. Disallow in robots.txt verhindert, dass Googlebot die Seite überhaupt abruft – spart Crawl Budget, bedeutet aber, dass Google keine Signale auf dieser Seite lesen kann. Noindex erlaubt Google, die Seite abzurufen, sagt ihr aber, dass sie nicht in die Suchergebnisse aufgenommen werden soll. Für Crawl Budget speziell ist disallow bei wirklich Junk-URLs (Admin-Pfade, interne Suchergebnisse) effektiver. Für gefilterte Facet-Seiten, bei denen du möchtest, dass Google den Inhalt versteht, aber nicht indexiert, ist noindex mit einem Canonical normalerweise die richtige Wahl.Disallow in robots.txt prevents Googlebot from fetching the page at all -- saving crawl budget but meaning Google can't read any signals on that page.Noindex allows Google to fetch the page but tells it not to include the page in search results. For crawl budget specifically,disallow is more effective on truly junk URLs (admin paths, internal search results). For filtered facet pages where you want Google to understand the content but not index it,noindex with a canonical is usually the right call.
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 eine aussagekräftige Bewegung bei den indexierten Seitenzahlen etwa sechs bis acht Wochen nach der Bereitstellung der großen Fixes. Erwarte keine Verä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 über fünf Monate von 34.000 auf knapp über 71.000. Nicht perfekt – es gab wirklich dünne Produktseiten, die nicht indexiert werden sollten – aber der Inhalt, der zählte, wurde gefunden. Der Client hörte auf zu fragen, ob etwas kaputt war. Und ich hörte auf, um Seitenwechsel um Seite 47.000 der Crawl-Reports nachzudenken. Größtenteils.