Crawling-Fehler in der Search Console finden und beheben

Bis 2019 gab es in der Search Console einen eigenen Bericht „Crawling-Fehler“. Wer ihn bei einer neuen Website zum ersten Mal öffnete, sah oft Tausende Einträge mit 404, Soft 404, Serverfehlern und verweigertem Zugriff. Den Bericht gibt es nicht mehr, die Fehler aber schon. Sie stehen heute an drei Stellen.

Dieser Ratgeber zeigt, wo du Crawling-Fehler heute findest, welche davon wirklich zählen und wie du sie abarbeitest. Warum Seiten trotz fehlerfreiem Crawling nicht im Index landen, erklärt der Ratgeber Google-Indexierung.

Wo die Crawling-Fehler heute stehen

Google hat den alten Bericht Ende März 2019 zusammen mit der alten Search Console abgeschaltet, ebenso die Crawl-Errors-API. Für die API gibt es laut Google keinen Ersatz. Die Informationen verteilen sich heute so:

• Crawling-Statistik (Einstellungen → Crawling-Statistik) zeigt, wie Googlebot deinen Server erlebt, mit Hoststatus, Antworten nach Status, Dateitypen, Zweck und Googlebot-Typ.
• Seitenindexierung (Indexierung → Seiten) zeigt, welche URLs aus welchem Grund nicht im Index sind, darunter alle Gründe, die mit dem Crawling zu tun haben.
• URL-Prüfung (Suchfeld oben) zeigt eine einzelne URL, mit Live-Test.

Vom alten Bericht zum heutigen Stand

Die Tabelle zeigt, wo die Kategorien des alten Berichts heute zu finden sind.

Bericht „Crawling-Statistik“

Den Bericht findest du unter Einstellungen → Crawling-Statistik → Bericht öffnen. Er steht nur für Properties auf Stammebene zur Verfügung, also für Domain-Properties oder URL-Präfix-Properties wie https://www.beispiel.de. Google richtet ihn an fortgeschrittene Nutzer und schreibt, dass Websites mit weniger als 1.000 Seiten ihn meist nicht brauchen. Bei großen Websites ist er die wichtigste Quelle für Crawling-Fehler.

Hoststatus für robots.txt, DNS und Serververbindung

Der Hoststatus fasst drei Prüfungen zusammen. Hier landen die früheren Website-Fehler.

• robots.txt-Abruf zeigt, wie oft der Abruf der robots.txt fehlgeschlagen ist.
• DNS-Auflösung zeigt, ob dein DNS-Server den Hostnamen nicht erkannt oder nicht geantwortet hat.
• Serververbindung zeigt, ob dein Server nicht reagiert oder keine vollständige Antwort geliefert hat.

Jede Prüfung hat ein Diagramm mit einer roten Grenzlinie. Liegt ein Tag darüber, wertet Google das als Problem. Der Status hat drei Stufen. Entweder gab es in den letzten 90 Tagen keine nennenswerten Probleme, oder es gab welche in den letzten 90 Tagen, aber nicht in der letzten Woche, oder es gab mindestens ein Problem in der letzten Woche.

Crawling-Antworten nach Status

Diese Aufschlüsselung zeigt den Anteil jeder Antwort an allen Crawling-Anfragen, nicht je URL. Google teilt die Antworten in drei Gruppen.

Dateityp, Zweck und Googlebot-Typ

• Nach Dateityp unterscheidet der Bericht HTML, Bild, JavaScript, CSS, PDF, JSON und weitere. Der Typ „Unbekannt (fehlgeschlagen)“ zählt Anfragen, die gar keine Antwort bekommen haben. Fallen viele JavaScript- oder CSS-Dateien aus, kann Google Seiten nicht vollständig rendern.
• Nach Zweck steht „Erkennung“ für URLs, die Google zum ersten Mal crawlt, und „Aktualisierung“ für bekannte URLs. Nach einem Relaunch steigt der Anteil der Erkennung.
• Nach Googlebot-Typ siehst du Smartphone, Computer, Bild, Video, Laden der Seitenressource, AdsBot, StoreBot und andere. So erkennst du, welcher Crawler auf Fehler stößt.

Oben im Bericht stehen außerdem die Crawling-Anfragen insgesamt, die Download-Größe und die durchschnittliche Reaktionszeit. Ein Anstieg der Reaktionszeit kündigt Serverprobleme oft an, bevor Fehler auftauchen.

Crawlbezogene Gründe in der Seitenindexierung

Der Bericht Indexierung → Seiten (früher „Abdeckung“) listet unter „Warum Seiten nicht indexiert werden“ alle Gründe auf. Die folgenden haben direkt mit dem Crawling zu tun. Die übrigen Gründe, etwa „Duplikat“ oder „Durch noindex-Tag ausgeschlossen“, behandelt der Ratgeber Google-Indexierung.

Beispiel-URLs zeigt der Bericht je Grund bis zu 1.000 Stück. Bei großen Websites fehlen also viele betroffene URLs. Hast du alle Fälle eines Grundes behoben, klickst du in der Detailansicht auf Fehlerbehebung überprüfen. Laut Google dauert die Prüfung in der Regel etwa zwei Wochen, manchmal länger. Das ersetzt das frühere „Als behoben markieren“.

URL-Prüfung für einzelne URLs

Mit der URL-Prüfung siehst du für eine einzelne URL, was Google beim letzten Crawl erlebt hat. Gib die URL ins Suchfeld oben in der Search Console ein.

• Gecrawlte Seite anzeigen zeigt HTML, Screenshot und HTTP-Antwort aus dem letzten Crawl.
• Seitenabruf, Crawling erlaubt?, Indexierung zulässig? und Letztes Crawling zeigen, ob und wann Google die URL abrufen konnte. „Gecrawlt über“ nennt den Crawler.
• Verweisende Seite und Sitemaps zeigen, woher Google die URL kennt. Das ist der Nachfolger des alten Reiters „Verlinkt von“, nennt aber nur Beispiele.
• Live-URL testen ruft die URL jetzt ab. So prüfst du, ob eine Korrektur wirkt.
• Indexierung beantragen nutzt du nach einer Korrektur. Dafür gilt ein Tageslimit je Property.

Ein erfolgreicher Live-Test heißt nicht, dass die URL indexiert wird. Google prüft im Live-Test unter anderem keine Duplikate, keine Canonical-Auswahl und keine manuellen Maßnahmen.

404-Fehler durch URLs in Skripten

Manchmal meldet die Search Console 404-Fehler für URLs, die auf keiner Seite als Link stehen. Oft stecken sie als relative Pfade in JavaScript, etwa in einem Konfigurationsobjekt oder einem Template-String. Google erkennt Links auch in eingebettetem Code und versucht, solche Pfade zu crawlen.

Laut Google schaden solche 404-Fehler deiner Website nicht. Dass einzelne URLs 404 liefern, wirkt sich nicht darauf aus, wie die übrigen URLs gecrawlt und gerankt werden. Du kannst sie ignorieren. Wichtig ist nur, dass dein Server für nicht existierende URLs wirklich 404 liefert und keine leere Seite mit Status 200.

Wie arbeitest du viele Crawling-Fehler ab?

Viele Fehler auf einmal sind normal, vor allem bei einer Website, die du neu übernimmst. Die meisten sind harmlos. Diese Reihenfolge hat sich bewährt:

1. Hoststatus zuerst. Probleme mit robots.txt, DNS oder Serververbindung betreffen die ganze Website. Sie haben Vorrang vor allen URL-Fehlern.
2. Dann Serverfehler (5xx). Einzelne Fehler bei Wartung oder Lastspitzen sind normal. Wiederholen sie sich, drosselt Google das Crawling, und Besucher sehen dieselben Fehler. Schick deiner Entwicklung oder dem Hosting die Beispiel-URLs mit Datum und vergleiche sie mit den Server-Logs.
3. Dann interne Ursachen. Kommen 404, Soft 404 oder Weiterleitungsfehler von eigenen Seiten oder aus der Sitemap, korrigierst du den Link oder den Sitemap-Eintrag. Zusätzlich leitest du auf das richtige Ziel weiter, damit die alte URL aus dem Index verschwindet.
4. Dann externe Links. Zeigt ein Link einer anderen Website auf eine falsche URL, leite sie per 301 auf das passende Ziel weiter. Den Betreiber um Korrektur zu bitten lohnt sich nur bei wichtigen Links.
5. Den Rest liegen lassen. 404 für gelöschte Seiten ohne Links, URLs aus Skripten und Fehler, deren Herkunft sich nicht klären lässt, sind kein Problem. Taucht dieselbe URL immer wieder auf, gehst du ihr nach.

Am besten schaust du einmal pro Woche zu einem festen Termin in die Berichte. Dann sind die neuen Fehler überschaubar, und du erkennst Ausreißer.

Was die Search Console nicht zeigt

• Verzögerung. Die Berichte zeigen, was Google schon gecrawlt hat. Ein Fehler auf einer selten gecrawlten Seite fällt dort erst nach Tagen oder Wochen auf.
• Stichproben. Je Grund gibt es höchstens 1.000 Beispiel-URLs, und „Verweisende Seite“ nennt nur ein Beispiel.
• Nur Google. Wie Bing, KI-Crawler oder Besucher deine Website erleben, steht nicht drin.

Für eine vollständige Liste aller Anfragen und Statuscodes brauchst du die Server-Logs, siehe Logfile-Analyse. Wie du 404-Fehler aus allen Quellen bewertest und behebst, erklärt der Ratgeber 404-Fehler finden und beheben.

Häufige Fragen