Neue Google Search Console 2018

Tiefe Einblicke in den Suchmaschinenindex

In den letzten Wochen gab es bereits einige Beiträge zur Beta-Version der neuen Google Search Console. Mittlerweile hat Google bestätigt, dass die Beta-Version derzeit an weitere Webmaster zum Testen ausgerollt wird. Vor einigen Tagen konnte die UDG selbst einen ersten Blick auf die neue Google Search Console (beta) für einen unserer Kunden werfen, sodass wir heute einen ausführlichen Überblick mit vielen deutschsprachigen Screenshots zur Verfügung stellen können.

Was gibt es in der aktuellen Beta-Version schon Neues zu sehen?

Der aktuelle Umfang der neuen Beta-Oberfläche ist noch recht stark reduziert. Lediglich zwei Hauptmenüpunkte – nämlich Status und Sitemaps – stehen zur Verfügung. Insbesondere der erste Menüpunkt enthält darunter allerdings schon eine Menge an Funktionen, wobei der Unterbereich Leistung der überarbeitete Nachfolger des bisherigen Suchanalyse-Bereichs ist. Um es kurz zu machen: Hier ist neben der Anpassung ans Material Design (und damit einhergehend ein Responsive Webdesign) vor allem hervorzuheben, dass Daten nun weit über die bisherigen 90 Tage hinaus bis zu 16 Monate in die Vergangenheit abrufbar sind und sich so Entwicklungen länger zurückverfolgen lassen.

In diesem Beitrag möchten wir uns daher vielmehr auf den neuen Bereich der sogenannten Indexabdeckung konzentrieren, da dieser sehr mächtig ist und die bislang größte Neuerung der Search Console darstellt. Als historische Vorgänger können die alten Bereiche Google-Index (darin Indexierungsstatus und Blockierte Ressourcen) sowie Crawling (darin die Crawling-Fehler und Crawling-Statistiken) angesehen werden. Was bisher auf vier Bereichen verteilt war, geht nun in einem umfassenden Bereich auf, der einerseits bisherige Möglichkeiten im neuen Material Design vorhält und andererseits aber auch völlig neue Analyseansätze bietet. Hinzu kommt die Möglichkeit manche der Ansichten bequem per Button mit anderen Personen teilen zu können – und zwar ohne, dass diese ein Google-Konto besitzen oder explizit freigeschaltet werden müssen.

Was ist in der neuen Indexabdeckung alles zu finden?

Google hat hier wirklich viele Kategorien definiert, die den Nutzer der Search Console dazu befähigen sollen, Fehlerquellen besser aufspüren und beheben zu können. Die Anzahl und Bedeutung der einzelnen Fehlerquellen zeigen, wie differenziert Google das Ganze sieht und wie differenziert Webmaster das Ganze sehen sollten.

Diese folgenden Kategorien sind derzeit in der neuen Indexabdeckung von Google verfügbar:

• Gesendet und indexiert

• Indexiert, nicht in Sitemap gesendet

• Gesendete URL als “noindex” gekennzeichnet

• Durch robots.txt-Datei blockiert

• Gecrawlt – derzeit nicht indexiert

• Crawling-Anomalie

• Soft 404

• Gesendete URL nicht als kanonisch ausgewählt

• Durch “noindex”-Tag ausgeschlossen

• Duplikat, aber ohne kanonisches Tag

• Seite mit Weiterleitung

• Nicht gefunden (404)

Dabei kann jeder Grund einzeln angewählt werden, um weitere Details, darunter konkrete Beispiel-URLs einzusehen. Die einzelnen Gründe sind drei verschiedenen Stati untergeordnet: Gültig, Fehler und Ausgeschlossen.

Googles neue Indexabdeckung nach einzelnen Stati und Gründen erklärt:

Status: Gültig
Grund: Gesendet und indexiert

Das ist der bevorzugte Status. Hier sollte der Großteil aller Seiten zu finden sein. Gesendet und indexiert bedeutet, dass Google die URLs problemlos crawlen konnte und aufgrund ihrer Relevanz auch indexiert hat. Damit sind diese URLs potenziell von Google-Nutzern über die Websuche auffindbar.
Grund: Indexiert, nicht in Sitemap gesendet

Auch URLs mit diesem Status sind über die Websuche auffindbar. Allerdings hat Google diese URLs nicht explizit über eine XML-Sitemap übermittelt bekommen, sondern nur das über Crawling von internen und externen Links gefunden und für indexierungswürdig erachtet. Hier sollte geprüft werden, ob diese URLs nicht gegebenenfalls in der XML-Sitemap mit aufgenommen werden sollten.

Status: Fehler
Grund: Gesendete URL als “noindex” gekennzeichnet

Dieser Status ist prinzipiell als Fehler anzusehen, da er bedeutet, dass in der XML-Sitemap URLs enthalten sind, die an anderer Stelle – nämlich durch die Meta-Angabeim Header des HTML-Dokumentes – für den Googlebot für eine Indexierung ausgeschlossen sind. Google zeigt mit diesem Status also einen Konflikt auf, der im Zusammenspiel der beiden widersprüchlichen Informationen entstanden ist. Um sein Crawling-Budget sorgsam einzusetzen, sollten die URLs entweder aus der XML-Sitemap entfernt werden (Irrelevanz, Duplikate, etc.) oder im HTML-Dokument von der Meta-Angabe befreit werden (zu Unrecht gesperrt, aus Versehen blockiert, obwohl wichtige Ressource).

Status: Ausgeschlossen
Grund: Durch robots.txt-Datei blockiert

Bei diesem Status unterscheidet Google nicht danach, ob eine URL in der XML-Sitemap oder über das Verfolgen eines Hyperlinks übermittelt wurde, sondern gibt lediglich die Information, dass die URL in der robots.txt der Domain explizit für das Crawling mit dem Googlebot(-Mobile) gesperrt wurde. Bei der robots.txt handelt es sich um eine Konfigurationsdatei, die pro Zeile bestimmte URLs oder ganze URL-Bereiche für Bots sperren kann. Im Gegensatz zu vielen bösartigen (Spam)-Bots respektiert der Googlebot die dort gemachten Anweisungen. Auch hier kann im Zweifelsfall geschaut werden, ob die Datei tatsächlich gesperrt sein soll oder ob es sich um relevante Inhalte handelt, die Google zugänglich sein sollten.

Grund: Gecrawlt – derzeit nicht indexiert

Dieser Status lässt den Webmaster leider etwas im Dunkeln über die genauen Gründe, warum eine URL zwar ohne Probleme gecrawlt werden konnte, aber trotzdem nicht in den Google-Index aufgenommen wurde. Aus Erfahrung handelt es sich hierbei entweder um absolut irrelevante oder doppelte Seiten, die über XML-Sitemap und/oder interne Verlinkung an Google übermittelt wurden oder aber das Index-Budget der Domain wurde erreicht. Ist dies der Fall, so reichen der Trust und die Relevanz einer Domain nicht aus, um mehr URLs im Google-Index zu rechtfertigen. Abhilfe schaffen hier Optimierung des Crawl-Budgets durch effizientere interne Verlinkung/Struktur sowie mehr externe Trust-Signale aus den Bereichen Backlinks, Social Media und Erwähnungen auf anderen Webseiten (Buzz).

Grund: Crawling-Anomalie

Unter diesem Status listet Google vorwiegend URLs, von denen aufgrund ihrer Beschaffenheit ausgegangen werden kann, dass sie gar nicht existieren sollen. So konnten bei unserem Kunden etwa URLs der Form http://www.domain.com/de/de/assistenz/ /$categoryDetailsService.getUrlForCompetenceOrCategoryPage(‘accessories’) gefunden werden, die beim Crawling im Quellcode fälschlicherweise von Google nachverfolgt wurden, aber logischerweise beim Aufruf einen Fehlercode ausgeben.

Grund: Soft 404

Unter diesem Status sind jene URLs versammelt, die fälschlicherweise einen Status Code 200 ausgeben, obwohl kein Inhalt angezeigt wird und besser ein Status Code 404 ausgegeben werden sollte. Bei Fehlern dieser Kategorie sollte ermittelt werden, warum diese URLs vom CMS erzeugt werden und wo sie intern oder extern verlinkt sind.

Grund: Gesendete URL nicht als kanonisch ausgewählt

Ähnlich wie im Fall von „Gesendete URL als “noindex” gekennzeichnet“ besteht hier ein Widerspruch, da einerseits eine URL über die XML-Sitemap übermittelt wurde und andererseits die gleiche URL per Canonical Tag auf eine andere zu bevorzugende URL verweist. Auch hier besteht die Aufhebung dieses Umstandes darin, entweder die genannten URLs aus der XML-Sitemap herauszunehmen oder ein möglicherweise falsch gesetztes Canonical Tag zu entfernen.

Grund: Durch “noindex”-Tag ausgeschlossen

Hier finden sich alle URLs, die Google durch Crawling der Domain gefunden hat, aber aufgrund der bindenden Meta-Angabenicht in den Index aufgenommen hat. Meist ist dies so gewollt, allerdings können auch hier URLs enthalten sein, die ohne Absicht (durch eine größere technische Umstellung etwa) vom Google-Index ausgeschlossen wurden.

Grund: Duplikat, aber ohne kanonisches Tag

Prinzipiell ein neuer hilfreicher Status, den es in dieser expliziten Form zuvor nicht gab. Hier lässt Google Webmaster an seiner Fähigkeit automatisiert Duplikate zu erkennen, die noch nicht adäquat mittels Weiterleitung, Entfernung oder Einbindung eines Canonical Tags behandelt wurden. Allerdings ist man in der aktuellen Form ohne Angabe der doppelten URL etwas allein gelassen, herauszufinden, auf welches Duplikat sich eine hier angegebene URL bezieht. Das muss noch verbessert werden.

Grund: Seite mit Weiterleitung

Unter diesen Status fallen alle URLs mit Status 301, auf die Google entweder durch Crawling oder Verarbeiten den XML-Sitemap gestoßen ist. Gemäß der Eigenschaft einer permanenten Weiterleitung wird nicht mehr die ursprüngliche URL, sondern die Ziel-URL indexiert. Somit fällt die ursprüngliche URL aus dem Index raus und wird durch die neue Ziel-URL ersetzt. Nach einem Relaunch auf gleicher Domain sind hier in der unmittelbaren Folgezeit viele URLs zu erwarten. Außerhalb eines Relaunchs sollte die Anzahl eher gering ausfallen. Ist dies nicht der Fall, so sollte die interne Verlinkung dahingehend überprüft werden, statt auf weiterleitende URLs mit Status Code 301 direkt auf die Ziel-URLs mit Status Code 200 zu verlinken.

Grund: Nicht gefunden (404)

Zu guter Letzt der wohl prominenteste Status Code 404. In der alten Search Console gab es bereits einen eigenen passenden Menüpunkt namens Crawling-Fehler, in dem die 404-Fehler beheimatet waren. Nun haben sie aller Voraussicht nach im Bereich Indexabdeckung ein neues Zuhause gefunden. Durch 301-Weiterleitung lassen sich 404-URLs „wiederbeleben“, um sie für das Ranking von damit assoziierten Keywords nutzen zu können. Es sollten regelmäßig 404-Analysen gemacht werden, um ein effektives Crawling zu gewährleisten und die Gesundheit einer Domain sicherzustellen.

Möglicherweise gibt es noch weitere Stati, die wir bei unserer Beispieldomain nicht angezeigt bekommen.

Bonusrunde: Das angeschlossene Testingtool zur Überprüfung von behobenen Indexfehlern

An die Indexabdeckung ist ein Testingtool angeschlossen, welches immer dann bemüht werden kann, wenn einer als rot markierter Fehlergrund behoben wurde. Im Test wurde die Überprüfung auch nach mehr als 48 Stunden noch nicht abgeschlossen, eventuell ist die Funktion in der Beta-Version noch nicht live geschaltet. Immerhin bekommt man als uneingeschränkter Nutzer (und sehr wahrscheinlich dann auch als Admin oder Inhaber) eine Bestätigungs-E-Mail über den gestarteten Vorgang zugeschickt.

Zu guter Letzt sei noch eine weitere Filterung innerhalb der jeweiligen Gründe vorgestellt. Um den Ursprung der Fehlerquelle weiter einschränken zu können, kann die aktuelle Ansicht noch danach gefiltert werden, ob die Daten aus „allen bekannten Seiten“ (egal ob über XML-Sitemaps oder Crawling), „allen eingereichten Seiten“ (aus allen XML-Sitemaps) oder nur aus einzelnen eingereichten XML-Sitemaps stammen.

Wie fällt unser Fazit zur Beta-Version der neuen Google Search Console aus?

Auch wenn erst wenige Bereiche bisher verfügbar sind, hat es vor allem der komplett neue Bereich der Indexabdeckung in sich. Hier bekommt man einen bislang nicht vorhandenen tiefen Einblick in den Indexalltag der eigenen Seite innerhalb von Google. Alle vorgestellten Fehlergründe unterstreichen die Wichtigkeit der damit verbundenen Aspekte wie robots.txt, XML-Sitemap, Canonical Tag, Meta-Robots-Noindex-Angabe sowie Soft- und Hard-404-Fehler. Vor allem gefällt, dass nun Informationen und Analysen innerhalb einer Ansicht möglich sind, die in der klassischen Search Console noch auf verschiedene Unterpunkte verteilt sind und jeweils etwas anders funktionieren.

Zusammen mit dem angegliederten Testingtool, der komfortablen Teilen-Funktion und dem responsiven Material Design fällt unser Fazit zur aktuellen Beta-Version der neuen Google Search Console daher sehr positiv aus. Das lässt hoffen, dass auch die anderen Bereiche schon bald in neuem Glanz und mit vielen nützlichen Features erscheinen. Wenn es soweit ist, freuen wir uns jetzt schon, einen weiteren ausführlichen Report an dieser Stelle geben zu können.

Abschließend sei gesagt, dass die bisherige klassische Google Search Console bis zur vollständigen Einführung der neuen Version noch parallel erhalten bleiben wird.

Weitere Reviews:

• Moritz Kühnel: Zum neuen Leistungsbericht der Google Search Console 2018.