Site icon Blog für den Onlinehandel

Der perfekte SEO-Relaunch: Die optimale Nachsorge

3D First Aid Crossword Block Button text over white background

Nach dem Go-Live einer neuen Website sollte man sich nicht beruhigt zurücklehnen. Der beste Freund in dieser Zeit sollte die Google Search Console sein – mit dem (fast) direkten Draht zu Google. Der Relaunch einer neuen Website ist häufig ein anstrengender Prozess. Ähnlich wie bei einer Geburt ist natürlich „Tag 0“ der alles entscheidende Tag. Um beim Bild zu bleiben, ist die „Nachsorge“ aber mindestens genauso wichtig. Denn auch bei perfekter Planung können immer noch Detailprobleme auftauchen, die man bei den Prüfungen vorab übersehen hat bzw. gar nicht sehen konnte, da man z. B. beim Testen der Markups oft nur stichprobenweise prüft. In diesem vorletzten Teil der Artikelserie geht es daher um die optimale Nachsorge: Welche Reports sollte man sich anschauen? Und was kann man dort entdecken?

Crawling-Fehler

Wer bei der Vorbereitung des Relaunches alles richtig gemacht hat, hat dafür gesorgt, dass für alle wichtigen alten Seiten eine 301-Umleitung auf eine neue Seite existiert. Im Rahmen des Relaunches werden in der Google Search Console unter „Crawling-Fehler“ (siehe Abbildung 1) aber trotzdem viele Fehler angezeigt – in der Regel 404-Fehler („Seite nicht gefunden“). Ist das schlimm? Kann das Nachteile bringen?

Abb. 1: 404- und andere Fehler werden in diesem Report angezeigt – aber immer nur 1 000 URLs auf einmal.

Zunächst ist es so, dass viele 404- oder auch andere Seiten-Fehler per se keinen negativen Einfluss auf die Rankings oder Sichtbarkeit haben. Natürlich führt ein 404-Fehler einer Seite jedoch dazu, dass das entsprechende Ranking verloren geht. Außerdem wird ein eventueller externer Link auf eine solche Seite weder der Seite noch der Website zugerechnet. Da im Rahmen der Vorbereitung aber alle rankenden Seiten und Seiten mit externen Verlinkungen bedacht werden, kann eigentlich nichts Schlimmes mehr passieren.

Wie in Abbildung 1 zu sehen ist, findet Google natürlich immer noch Seiten, die jetzt einen 404-Fehler generieren – weil es die Seiten in der neuen Website nicht mehr gibt oder weil die Seite so unwichtig war, dass man dafür keine Umleitung eingerichtet hat. Beim Relaunch der Website www.bloofusion.de galt das z. B. für die Seite https://www.bloofusion.de/events/bloocon/agb.html, die die AGB der Veranstaltung BLOO:CON beinhaltete. Die Seite hatte keine Rankings und auch keine externen Verlinkungen. Das Letztere kann man übrigens relativ einfach prüfen, indem man auf die jeweilige URL klickt und dann in den Tab „Verlinkt über“ wechselt (siehe Abbildung 2). Google weist natürlich zu Recht darauf hin, dass hier möglicherweise nicht alle URLs aufgeführt werden, aber in der Regel ist es so, dass hier externe Links erscheinen, wenn es denn welche gab.

Abb. 2: Bei den Crawling-Fehlern kann man recht gut prüfen, ob eine bestimmte Seite auch über externe Verlinkungen verfügt.

Mit der entsprechenden Vorbereitung kann man den Report für „Crawling-Fehler“ also relativ entspannt durcharbeiten. Dabei sind vor allem zwei Dinge wichtig: Es dauert einige Tage, bis in dem Report Fehler erscheinen. Und es werden maximal 1 000 fehlerhafte URLs angezeigt. Wer mehr als 1 000 URLs einsehen möchte, sollte die ersten 1 000 Einträge herunterladen, dann als korrigiert markieren und dann wieder von vorne anfangen. Bei einer hohen Anzahl fehlerhafter URLs kann das natürlich einige Zeit dauern.

Wenn man die Liste zusammengestellt hat, kann man diese durcharbeiten, um evtl. Seiten zu finden, die man doch noch umleiten möchte. Gelegentlich kann es sein, dass man hier noch einen „Schatz“ findet, aber – wie gesagt – mit der richtigen Vorbereitung sollte das unwahrscheinlich sein.

hreflang-Fehler

Wer eine internationale Website betreibt, sollte nach dem Go-Live auf jeden Fall den Report „Internationale Ausrichtung“ im Auge behalten, denn dort werden Fehler beim hreflang-Tag aufgeführt. Da hreflang-Tags im HTML-Code versteckt sind, fallen Fehler dort typischerweise nicht auf. Auch ist es oft so, dass diese nicht flächendeckend, sondern nur auf einigen Seiten oder Seitentypen auftreten. Und diese Fehler findet man dann am besten mit der Google Search Console.

In der Übersicht (siehe Abbildung 3) sieht man zunächst, für welche Sprache/Länder fehlerhafte Tags existieren. Dabei muss man aber beachten, dass nicht alle vermeintlichen Fehler auch tatsächlich welche sind. Manchmal hat Google einfach nur Probleme, die Korrektheit der hreflang-Tags über mehrere Seiten hinweg korrekt zu verfolgen.

Abb. 3: In der Übersicht der hreflang-Tags werden viele Fehler angezeigt – die es dann in der Realität so nicht immer gibt.

In der Praxis sollte man sich also die URLs der jeweiligen Seiten in der Google Search Console herunterladen und dann über ein externes Tool überprüfen. Kostenlos geht das sehr gut mit hreflang.org (die URLs über „Analyse Pages from a List“ überprüfen). Je nach Anzahl der Seiten kann das natürlich durchaus einige Zeit in Anspruch nehmen. Kostenpflichtig kann man dazu den Screaming Frog SEO Spider einsetzen, der seit einiger Zeit auch hreflang-Tags überprüfen kann.

Sobald die hreflang-Tags von einem der Tools geprüft wurden, geht es an die Fehlerbehebung. Dabei ist es hilfreich, systematische Fehler zu finden, um den Dienstleister oder die IT-Abteilung nicht mit Anfragen zu überfordern.

Fehlerhafte Markups

Wer auf seiner Website auch Markup einsetzt – und das werden mittlerweile die meisten Unternehmen sein –, sollte auch die Korrektheit dieser Markierungen überprüfen. Denn auch hier zeigen sich Fehler oft nur auf einigen wenigen Seiten. Über den Report „Strukturierte Daten“ sieht man hier relativ übersichtlich, welche Markups es auf der Website gibt und wo Fehler auftauchen. Auch hier ist es oft so, dass Markup auf vielen Seiten korrekt ist und sich Fehler nur auf einigen wenigen Seiten finden lassen (z. B. weil sich in die Preisinformation, die eigentlich nur aus einer Zahl besteht, bei Angeboten das Wort „Ab“ einschleicht).

In der Google Search Console werden in der Regel schon direkt Fehler angezeigt (also z. B. „Folgendes fehlt: author“ für ein fehlendes author-Attribut). Aber auch hier passiert es manchmal, dass der Fehler nicht (mehr) existiert. Es bietet sich also auch hier an, die Daten live zu testen. Dazu bietet Google einen direkten Link an, um in das „Test-Tool für strukturierte Daten“ zu wechseln (siehe Abbildung 4).

Abb. 4: Angezeigte Markup-Fehler sollte man in jedem Fall überprüfen.

Auch hier geht es dann wieder darum, systematische Fehler zu finden und diese durch die IT abstellen zu lassen.

Noch mehr?

Man sollte natürlich auch einen Blick auf die folgenden Reports werfen:

Insgesamt ist die Google Search Console sehr hilfreich, um viele Fehlerquellen zu entdecken. Wie schon erwähnt, dauert es aber zum Teil mehrere Tage, bis sich die Reports mit Daten füllen. Insgesamt sollte die Nachsorge eines Go-Live also gerne einen ganzen Monat umfassen. Man muss natürlich nicht stündlich reinschauen, aber sollte sich z. B. einmal pro Woche durch die Reports klicken, um dann entsprechende Maßnahmen zu ergreifen.

Alternativ bzw. ergänzend bieten sich übrigens auch die Webmaster Tools von Bing an. Auch dort sind viele Reports zu finden – zum Teil anders, zum Teil sogar besser als bei Google.

Fazit

Im ersten Monat nach dem Go-Live ist es wichtig, regelmäßig in der Google Search Console nach Fehlerquellen zu suchen. Trotz Vorbereitung kann es immer wieder passieren, dass bestimmte Fehler bei einigen Seiten auftauchen – und diese Fehler findet man eben am besten mit der Google Search Console. Dabei muss man natürlich immer darauf achten, das „große Bild“ zu sehen und nicht Fehler für Fehler abarbeiten zu wollen, denn die meisten Fehler sind in der Praxis dann doch systematischer Natur.

Dieser Beitrag ist in Ausgabe #68 des Magazins für SEO, SEA und E-Commerce „suchradar“erschienen. Die gesamte Ausgabe #68 des suchradars mit dem Fokusthema „Remarketing / Retargeting: aus Besuchern Kunden machen“ kann unter www.suchradar.de kostenlos als PDF-Version heruntergeladen werden!

Exit mobile version