Crawl-Statistiken der Search Console richtig lesen
Der Crawl-Stats-Report versteckt sich in den Einstellungen der Search Console und wird deutlich seltener genutzt als der Leistungsbericht oder die Indexierungsübersicht, obwohl er als einziger Bericht direkt zeigt, wie Googlebot eine Website tatsächlich crawlt. Wer versteht, wie sich Crawl-Anfragen nach Antwortcode, Dateityp und Zweck aufschlüsseln lassen, erkennt technische Probleme oft Wochen bevor sie sich in Rankings oder im Indexierungsstatus bemerkbar machen.
Inhaltsverzeichnis
- 1. Wo sich der Crawl-Stats-Report befindet und was er zeigt
- 2. Crawl-Anfragen nach Antwortcode aufschlüsseln
- 3. Crawl-Anfragen nach Dateityp aufschlüsseln
- 4. Was ein Anstieg an 404-Crawls konkret bedeutet
- 5. Server-Fehler im Report richtig einordnen
- 6. Host-Status-Warnungen richtig verstehen
- 7. Der Zusammenhang zwischen Crawl-Statistiken und Crawl-Budget
- 8. Crawl-Zweck: Discovery gegenüber Refresh und Googlebot-Typ
- 9. Praktischer Handlungsplan bei Auffälligkeiten
- 10. Zusammenfassung
- 11. FAQ
1. Wo sich der Crawl-Stats-Report befindet und was er zeigt
Der Crawl-Stats-Report findet sich in der Search Console unter Einstellungen und dann unter dem Punkt Crawling-Statistiken, erreichbar allerdings nur auf Domain-Property-Ebene, da er sich auf den gesamten Host und nicht nur auf eine einzelne URL-Präfix-Property bezieht. Er zeigt für die letzten 90 Tage die Gesamtzahl der Crawl-Anfragen, das insgesamt heruntergeladene Datenvolumen sowie die durchschnittliche Antwortzeit des Servers auf Anfragen von Googlebot.
Anders als der Leistungsbericht, der die Wahrnehmung der Website durch Nutzer in der Suche abbildet, dokumentiert der Crawl-Stats-Report ausschließlich das technische Verhalten von Googlebot selbst. Das macht ihn zum wichtigsten Werkzeug, um festzustellen, ob Google überhaupt effizient auf die relevanten Inhalte einer Website zugreifen kann, unabhängig davon, wie diese Inhalte anschließend in den Suchergebnissen abschneiden.
2. Crawl-Anfragen nach Antwortcode aufschlüsseln
Die erste zentrale Aufschlüsselung im Bericht sortiert alle Crawl-Anfragen nach dem vom Server zurückgegebenen HTTP-Statuscode. Im gesunden Normalfall dominiert der Statuscode 200, oft ergänzt um einen sichtbaren Anteil an 301-Weiterleitungen, die bei gepflegten Websites mit regelmäßigen URL-Änderungen völlig normal sind. Ein gesundes Verhältnis liegt meist bei deutlich über 80 Prozent erfolgreichen 200er-Antworten.
Steigt der Anteil an 4xx- oder 5xx-Antworten spürbar an, verschwendet Googlebot einen wachsenden Teil seines zugewiesenen Crawl-Budgets auf Anfragen, die keinen indexierbaren Inhalt liefern. Besonders aufschlussreich ist dabei die zeitliche Entwicklung: Ein einmaliger, kurzer Ausschlag lässt sich oft auf einen einzelnen Deployment-Fehler zurückführen, während ein dauerhaft erhöhtes Niveau meist auf strukturelle Probleme wie fehlerhafte interne Verlinkung oder eine defekte Sitemap hindeutet.
3. Crawl-Anfragen nach Dateityp aufschlüsseln
Die zweite Aufschlüsselung zeigt, welche Dateitypen Googlebot tatsächlich abruft, unterteilt unter anderem in HTML, Bild, JavaScript, CSS und weitere Kategorien. Bei einer klassischen inhaltsgetriebenen Website sollte HTML den überwiegenden Anteil der Crawl-Anfragen ausmachen, da genau diese Dateien den indexierbaren Inhalt transportieren, während CSS- und JavaScript-Dateien nur für das Rendering benötigt werden.
Ein ungewöhnlich hoher Anteil an JavaScript- oder CSS-Anfragen im Verhältnis zu HTML kann darauf hindeuten, dass Googlebot pro gerenderter Seite überproportional viele zusätzliche Ressourcen laden muss, etwa durch nicht gecachte, dynamisch generierte Asset-URLs mit wechselnden Versionierungs-Parametern. Das bindet Crawl-Budget, ohne zusätzlichen indexierbaren Content zu liefern, und lässt sich häufig durch konsequentes Browser-Caching und stabile, versionierte Asset-Dateinamen deutlich reduzieren.
4. Was ein Anstieg an 404-Crawls konkret bedeutet
Ein plötzlicher Anstieg der 404-Antworten im Crawl-Stats-Report bedeutet in aller Regel, dass Googlebot über interne Links, eine Sitemap oder alte externe Backlinks auf URLs stößt, die nicht mehr existieren. Der erste Schritt zur Ursachenklärung ist ein Blick in den Bericht zur Indexierung unter dem Filter für nicht gefundene Seiten, kombiniert mit einer Prüfung, über welche Quelle Googlebot die jeweilige URL entdeckt hat.
Handelt es sich um alte, längst entfernte Produktseiten, die weiterhin über die XML-Sitemap gemeldet werden, liegt der Fehler meist in einer veralteten, nicht automatisch aktualisierten Sitemap-Generierung. Handelt es sich dagegen um interne Links aus der eigenen Navigation oder aus Kategorieseiten, liegt ein strukturelles Verlinkungsproblem vor, das mit hoher Priorität behoben werden sollte, da es echtes Crawl-Budget kontinuierlich für tote Links verbraucht, statt es für neue oder aktualisierte Inhalte einzusetzen.
5. Server-Fehler im Report richtig einordnen
Ein Anstieg an 5xx-Statuscodes ist ernster einzuordnen als 404-Fehler, da er auf tatsächliche Serverprobleme wie Überlastung, fehlerhafte Deployments oder Timeouts bei besonders rechenintensiven Seiten hindeutet. Google reduziert bei wiederholt auftretenden Serverfehlern automatisch die Crawl-Rate für die betroffene Domain, um den ohnehin belasteten Server nicht zusätzlich zu strapazieren, was kurzfristig sinnvoll ist, mittelfristig aber die Entdeckung und Aktualisierung neuer Inhalte spürbar verlangsamt.
Besonders kritisch wird es, wenn 5xx-Fehler zeitlich mit erhöhten durchschnittlichen Antwortzeiten im selben Bericht zusammenfallen, da dies auf eine grundsätzliche Serverkapazitätsgrenze statt auf einen isolierten Einzelfehler hindeutet. In diesem Fall sollte nicht nur der einzelne Fehler behoben werden, sondern grundsätzlich geprüft werden, ob die Infrastruktur, etwa PHP-FPM-Worker-Limits oder Datenbank-Connection-Pools, für das aktuelle Crawl-Volumen und den gleichzeitigen Nutzer-Traffic überhaupt ausreichend dimensioniert ist.
6. Host-Status-Warnungen richtig verstehen
Oberhalb der eigentlichen Diagramme zeigt der Bericht einen Host-Status mit einer einfachen Ampel-Bewertung für Abrufbarkeit von robots.txt, DNS-Auflösung und allgemeine Server-Verbindungsprobleme der letzten 90 Tage. Eine rote Markierung bei der robots.txt-Abrufbarkeit ist besonders kritisch, da Googlebot bei wiederholten Fehlern beim Abruf dieser Datei aus Vorsicht das Crawling der gesamten Domain vorübergehend einstellen kann, um versehentlich gesperrte Bereiche nicht fälschlich zu crawlen.
DNS-Auflösungsprobleme deuten häufig auf eine instabile oder falsch konfigurierte Nameserver-Infrastruktur hin und sollten sofort mit dem Hosting- oder DNS-Anbieter geklärt werden, da sie potenziell die gesamte Erreichbarkeit der Domain betreffen, nicht nur einzelne Seiten. Server-Verbindungsprobleme wiederum können auf Firewall-Regeln hindeuten, die Googlebot-IP-Bereiche unbeabsichtigt blockieren, was in der Praxis überraschend häufig nach Sicherheitshärtungen oder dem Wechsel eines Hosting-Anbieters vorkommt.
7. Der Zusammenhang zwischen Crawl-Statistiken und Crawl-Budget
Crawl-Budget bezeichnet die begrenzte Anzahl an Anfragen, die Googlebot innerhalb eines bestimmten Zeitraums auf einer Domain durchführt, bestimmt durch eine Kombination aus Crawl-Rate-Limit, also der maximal verträglichen Serverlast, und Crawl-Demand, also dem Interesse von Google an einer möglichst häufigen Aktualisierung der jeweiligen Inhalte. Der Crawl-Stats-Report ist die einzige offizielle Google-Quelle, die dieses abstrakte Konzept in konkrete, beobachtbare Zahlen übersetzt.
Für die meisten kleineren und mittelgroßen Websites ist Crawl-Budget in der Praxis kein limitierender Faktor, da Google in der Regel deutlich mehr Kapazität bereitstellt, als tatsächlich benötigt wird. Relevant wird das Thema vor allem bei sehr großen Websites mit mehreren Hunderttausend URLs, etwa umfangreichen E-Commerce-Katalogen mit vielen Filterkombinationen, bei denen ein ineffizientes Crawl-Verhalten tatsächlich dazu führen kann, dass neue oder aktualisierte Seiten spürbar verzögert entdeckt werden.
8. Crawl-Zweck: Discovery gegenüber Refresh und Googlebot-Typ
Der Bericht unterscheidet zusätzlich zwischen Crawling zur Entdeckung, wenn Googlebot eine URL zum ersten Mal besucht, und Crawling zur Aktualisierung, wenn eine bereits bekannte URL erneut abgerufen wird, um Änderungen zu erkennen. Ein gesundes Verhältnis hängt stark vom Reifegrad und der Änderungshäufigkeit der Website ab: Neue Websites zeigen naturgemäß einen höheren Discovery-Anteil, während etablierte, häufig aktualisierte Blogs meist einen hohen Refresh-Anteil aufweisen.
Zusätzlich lässt sich der Traffic nach Googlebot-Typ aufschlüsseln, etwa Smartphone-Googlebot als primärer Crawler seit der vollständigen Umstellung auf Mobile-First-Indexierung, sowie separate Crawler für Bilder, Videos und den AdsBot. Ein überraschend hoher Anteil an Desktop-Googlebot-Anfragen bei einer Website ohne separate Desktop-Ausrichtung kann ein Hinweis auf ein technisches Problem bei der Erkennung des primären, mobilen Crawlers sein und verdient eine genauere Prüfung der Server-Konfiguration.
9. Praktischer Handlungsplan bei Auffälligkeiten
Bei jeder auffälligen Veränderung im Crawl-Stats-Report empfiehlt sich ein strukturiertes Vorgehen: Zunächst wird geprüft, ob die Veränderung mit einem bekannten Deployment, einer Migration oder einer Änderung an der robots.txt zeitlich zusammenfällt, da sich viele Auffälligkeiten dadurch bereits erklären lassen. Erst wenn kein offensichtlicher interner Auslöser erkennbar ist, lohnt sich eine tiefere Analyse über Server-Logs, die im Gegensatz zum aggregierten Search-Console-Bericht jede einzelne betroffene URL konkret benennen.
Langfristig empfiehlt sich, den Crawl-Stats-Report nicht nur reaktiv bei Problemen zu prüfen, sondern als festen Bestandteil eines monatlichen technischen SEO-Checks zu etablieren, ähnlich wie es viele Teams bereits mit dem Index-Coverage-Bericht handhaben. Wer die üblichen Werte für Antwortzeit, Antwortcode-Verteilung und Dateityp-Verteilung der eigenen Website kennt, erkennt Abweichungen deutlich schneller als jemand, der den Bericht nur sporadisch und ohne Vergleichswerte konsultiert.
| Signal im Report | Mögliche Ursache | Dringlichkeit | Erster Prüfschritt |
|---|---|---|---|
| Anstieg 404-Antworten | Veraltete Sitemap oder tote interne Links | Mittel | Indexierungsbericht nach nicht gefundenen Seiten filtern |
| Anstieg 5xx-Antworten | Serverüberlastung oder fehlerhaftes Deployment | Hoch | Server-Logs und Antwortzeiten prüfen |
| Rote robots.txt-Abrufbarkeit | Datei nicht erreichbar oder Server blockiert Zugriff | Sehr hoch | robots.txt manuell und per Testtool abrufen |
| Hoher JS/CSS-Anteil | Fehlendes Caching oder instabile Asset-URLs | Niedrig | Caching-Header und Versionierung prüfen |
| DNS-Auflösungsfehler | Instabile Nameserver-Konfiguration | Sehr hoch | DNS-Anbieter kontaktieren |
Mironsoft
Technisches SEO, Content-Strategie und nachhaltiges Ranking
Sichtbarkeit, die nicht beim nächsten Google-Update wieder verschwindet?
Wir prüfen bestehende Webseiten auf technische SEO-Fehler, schwache Content-Struktur und fehlende strukturierte Daten und bauen daraus eine Grundlage, die organisches Wachstum nachhaltig statt nur kurzfristig trägt.
Technisches SEO-Audit
Crawling, Indexierung, Core Web Vitals und strukturierte Daten systematisch prüfen.
Content-Strategie
Suchintention-basierte Inhalte statt Keyword-Stuffing für echte Relevanz aufbauen.
Onpage-Optimierung
Meta-Daten, interne Verlinkung und Seitenstruktur konsistent und skalierbar gestalten.
10. Zusammenfassung
Crawl-Stats-Report: Das Wichtigste auf einen Blick
Antwortcodes
Über 80 Prozent 200er-Antworten gelten als gesundes Grundniveau, Anstiege bei 4xx/5xx sind Warnsignale.
Dateitypen
HTML sollte bei inhaltsgetriebenen Seiten den Großteil der Crawl-Anfragen ausmachen.
Host-Status
Rote Markierungen bei robots.txt oder DNS erfordern sofortiges Handeln, nicht nur Beobachtung.
Crawl-Budget
Relevant vor allem bei sehr großen Websites, für die meisten kleineren Seiten kein limitierender Faktor.