SEO-Checkliste für die Website-Migration: was du vorher und nachher prüfst

Eine SEO-Checkliste für die Website-Migration hat drei Teile: was du vor dem Umzug festhältst, was du am Tag des Livegangs prüfst und was du im Monat danach weiter beobachtest. Bei einer SEO-Migration, die Traffic kostet, war der Plan oft gar nicht schlecht, sondern ein noindex aus dem Staging oder eine Sperre in der robots.txt hat die Umstellung überlebt und ist zwei Wochen lang niemandem aufgefallen.

Das gilt für einen Domainwechsel genauso wie für einen Plattformwechsel, die Umstellung von HTTP auf HTTPS oder einen Relaunch mit gleichbleibenden URLs. Einstellungen, die das Staging für Google unsichtbar gemacht haben, landen in der Produktion, und die Website ist nicht mehr crawlbar, während sie im Browser völlig normal aussieht.

Ein bis zwei Wochen vor dem Launch: die Baseline erstellen

Ohne Aufzeichnung des Ist-Zustands kannst du nicht zeigen, was eine Migration verändert hat. Erstelle sie früh genug, damit sie die normale Website abbildet und nicht eine, die für den Launch schon eingefroren ist.

1. Exportiere jede URL aus der aktuellen Sitemap und aus einem vollständigen Crawl und bewahre beide Dateien auf. Seiten mit Traffic, die nicht in der Sitemap stehen, fehlen gern in der Weiterleitungstabelle, gleiche deshalb mit den wichtigsten Landingpages der letzten 12 Monate aus GA4 oder dem Leistungsbericht der Search Console ab.
2. Halte Title, Meta Description, H1, Canonical und hreflang jeder URL mit organischem Traffic fest. Ein CSV-Export aus einem Crawler reicht dafür.
3. Liste das Tracking-Setup mit IDs auf: die GA4-Mess-ID (Präfix G-), den GTM-Container (Präfix GTM-), die Meta-Pixel-ID und die Cookie-Consent-Plattform.
4. Notiere die normalen Antwortzeiten, damit du später erkennst, ob der neue Stack langsamer ist.
5. Erstelle die Weiterleitungstabelle, eine Zeile pro alter URL mit ihrem konkreten neuen Ziel. Jede URL mit Traffic oder Backlinks braucht eine.

Wie die neue Sitemap aussehen sollte, beschreibt unser Leitfaden zu den Best Practices für XML-Sitemaps.

Auf dem Staging: die Einstellungen finden, die die Produktion lahmlegen

Die Mechanismen, die das Staging aus Google heraushalten, sind genau die, die du beim Launch entfernen musst. Finde heraus, wo jeder davon auf dem Staging sitzt, und prüfe ihn auf der Produktion innerhalb von Minuten nach der Umstellung erneut.

• robots.txt mit Disallow: /. Hier steht, wie du die robots.txt prüfst, Zeile für Zeile.
• Ein noindex-Tag in einem gemeinsam genutzten Template oder ein X-Robots-Tag: noindex-Header auf Server- oder CDN-Ebene
• In WordPress die Option „Suchmaschinen davon abhalten, diese Website zu indexieren“ unter Einstellungen > Lesen
• Canonicals, die auf den Staging-Hostnamen oder die alte Domain zeigen
• hreflang-Annotationen, die auf alte URLs verweisen oder denen die Rückverweise fehlen, die jede Sprachversion braucht
• HTTP-Basic-Authentication, die den Googlebot genauso wirksam aussperrt wie jede Robots-Regel

Der Launch-Tag

Die ersten Stunden sind dafür da, zu bestätigen, dass die Umstellung funktioniert hat, nicht für Umbauten an Templates.

Teste die Weiterleitungen anhand der Tabelle. curl -sIL https://old.example.com/seite/ gibt jeden Hop mit Statuscode aus, sodass du eine einzige 301 auf das richtige Ziel bestätigen kannst statt einer Kette oder einer 302. Leite nicht als Abkürzung alles auf die Startseite weiter; Google behandelt solche Weiterleitungen meist als Soft 404, und der Wert der alten Seiten geht verloren.

Prüfe, ob das SSL-Zertifikat sowohl für www als auch für die Domain ohne www gültig ist. Klick dich dann mit geöffnetem Echtzeitbericht in GA4 durch die wichtigsten Templates und kontrolliere, ob GA4 und GTM mit denselben IDs feuern, die du in der Baseline notiert hast. Tracking geht bei einem Neubau der Templates leicht verloren, und das merkt niemand vor dem Monatsreport.

Bei einem Domainwechsel verifizierst du beide Properties in der Search Console und meldest den Umzug in der alten Property mit dem Tool zur Adressänderung (Einstellungen > Adressänderung). Reiche die neue Sitemap ein und lass die alte noch eine Weile erreichbar, damit Google die alten URLs erneut crawlt und die Weiterleitungen findet.

Die 30 Tage nach der Migration

Probleme, die nach der ersten Woche auftreten, sucht niemand mehr. URLs können aus der neuen Sitemap fallen, während sich das CMS einpendelt, ein Template kann Titles und Meta Descriptions in einem ganzen Bereich umschreiben, ein Routine-Deploy kann Canonicals ändern, und die Antwortzeiten können steigen, wenn der Traffic zurückkommt. In der Search Console sollte der Bericht „Seiten“ unter „Indexierung“ in der neuen Property steigende Zahlen indexierter Seiten zeigen, während sie in der alten Property sinken, sobald die Weiterleitungen verarbeitet sind. Stockt die neue Property, sieh dir zuerst die Tabelle „Warum Seiten nicht indexiert werden“ an.

Die Baseline einem Monitoring überlassen

Nimmst du die Kundenwebsite ein bis zwei Wochen vor dem Launch in Deltio auf, wird der Vorher-Zustand für dich festgehalten. Deltio prüft Sitemap und Seiten täglich und vergleicht jede Prüfung mit der vorherigen. Verschwindet ein Bereich aus der Sitemap, ändern sich noindex oder robots.txt, zeigt ein Canonical plötzlich woandershin oder wurden Title, Meta Description oder H1 umgeschrieben, geht ein Alert per Slack und E-Mail für diese Website raus. Außerdem überwacht Deltio Uptime, SSL und Domain-Ablauf und ob GA4, GTM und das Meta Pixel noch auf der Seite sind.

Ein täglicher Zyklus ersetzt nicht die manuellen Prüfungen in der ersten Stunde nach dem Launch. Er deckt den Monat danach ab, wenn die Aufmerksamkeit meist schon beim nächsten Projekt ist. Die Baseline lässt sich nicht nachträglich erstellen, nimm die Websites also auf, bevor die nächste Migration ansteht; der 14-tägige kostenlose Test reicht locker für einen Launch.