In diesem Beitrag
Am Montag ist die neue Website online. Drei Wochen später fragt jemand aus dem Verkauf, warum kaum noch Anfragen über das Formular kommen. In der Search Console zeigt die Kurve seit dem Launchtag nach unten.
Erst den Bestand erfassen
Bevor die neue Struktur feststeht, braucht ihr eine Liste aller heutigen Adressen. Dazu gehören Seiten aus der Navigation, aber auch PDFs, alte Kampagnenseiten und Beiträge, auf die andere Websites verlinken.
Ein Export aus dem CMS reicht dafür selten. Ergänzt ihn mit einem Crawl, den Seiten aus der Search Console und euren Zugriffszahlen der letzten zwölf Monate. So tauchen auch Adressen auf, die in keiner Navigation mehr stehen.
Haltet zu jeder wichtigen Seite fest, welche Frage sie beantwortet. Fällt diese Antwort im neuen Auftritt weg, hilft auch die beste Weiterleitung nicht.
Für jede Adresse eine Entscheidung
Aus der Liste entsteht eine Tabelle: alte Adresse, Entscheidung, neue Adresse. Eine bewährte Adresse darf bleiben, ein neues Design ist kein Grund, alle URLs umzubenennen.
Zieht ein Inhalt um, führt eine dauerhafte Weiterleitung mit Statuscode 301 oder 308 direkt zur neuen Seite. Fasst ihr mehrere Seiten zusammen, muss das Ziel deren Inhalte tatsächlich aufnehmen.
Viele alte Adressen auf die Startseite umzuleiten, verwirrt Besucher. Google behandelt solche Weiterleitungen unter Umständen wie eine fehlende Seite. Entfällt ein Inhalt ohne passenden Ersatz, ist der Status 404 oder 410 die richtige Antwort, mit einer Fehlerseite, die zurück ins Angebot führt.
Was ausser den Adressen mitumzieht
Bei einem CMS-Wechsel gehen Seitentitel und Beschreibungen leicht verloren, weil das neue System sie in anderen Feldern speichert. Dasselbe gilt für Bildtexte, Sprachversionen, Canonical-Angaben und strukturierte Daten.
Eine Testumgebung sperrt Suchmaschinen zu Recht aus. Auf der Live-Website müssen diese Sperren weg. Prüft robots.txt und noindex deshalb ausdrücklich im Ablauf für den Launchtag.
Legt ausserdem fest, ab wann Inhalte nur noch im neuen System geändert werden. Wer zwei Monate vor dem Launch die Preisseite anpasst, will die neue Fassung danach wiederfinden.
Der Launchtag und die Wochen danach
Am Launchtag reichen Stichproben nicht. Ein Skript prüft die ganze Tabelle: Jede alte Adresse muss mit einer einzigen Weiterleitung auf eine erreichbare Seite führen. Danach reicht ihr die neue Sitemap in der Search Console ein.
Google verarbeitet einen Umzug schrittweise. Bei kleinen bis mittelgrossen Websites dauert es laut Google einige Wochen, bis die meisten Seiten umgezogen sind, bei grossen länger. Schwankungen in dieser Zeit sind normal.
Bleiben die Besuche danach aus, prüft gezielt: Fehlen Weiterleitungen, sind Inhalte verloren gegangen, hat sich die interne Verlinkung verändert? Blockiert eine Einstellung die Indexierung? Der Bericht zu nicht gefundenen Seiten zeigt, wo eine Zeile in der Tabelle fehlt.
Lasst die Weiterleitungen mindestens ein Jahr bestehen, besser länger. So kann Google alle Signale auf die neuen Adressen übertragen, auch die von Links auf anderen Websites. Diese Links bleiben bestehen, bis ihre Betreiber sie ändern.
Vor dem Launch erledigt
- Exportiert aus der Search Console die Seiten mit den meisten Klicks der letzten zwölf Monate. Jede davon braucht eine Entscheidung.
- Klärt, wann im Projekt die Weiterleitungstabelle entsteht und wer sie am Launchtag prüft.
- Plant für die ersten acht Wochen nach dem Launch einen festen wöchentlichen Blick in die Search Console ein.
Wir planen die Weiterleitungen zusammen mit der neuen Struktur, nicht in der letzten Woche vor dem Launch.
