Vor drei Jahren wurde mir eine Migration übergeben, die bereits live war. Keine Staging-Umgebung. Keine Redirect-Zuordnung. Ein E-Commerce-Katalog mit 22.000 Seiten, den jemand gerade auf eine neue Domain verwiesen und als „fertig" bezeichnet hatte. Der organische Traffic sank innerhalb von sechs Wochen um 74%. Der Kunde rief mich in leichter Panik an, und ich verbrachte etwa vier Monate damit, das zu entwirren.
Wichtigste Erkenntnis: Site-Migrationen verlieren Rankings durch übersprungene Redirect-Audits, nicht durch Plattformwechsel; die Checkliste umfasst Redirect-Map, Metadaten-Transport, Schema-Kontinuität und Post-Launch-Verifizierung.
Diese Erfahrung, so schmerzhaft sie auch war, ist im Grunde der Grund, warum diese Checkliste existiert. Seitdem habe ich Websites migriert, die von 800-Seiten-Brochureware bis zu einem 31.000-Seiten-Publisher mit regionalen Subdomains reichen, und die Grundlagen sind jedes Mal gleich. Wenn du die Reihenfolge durcheinanderbringst, einen Schritt überspringst, wird Google dir das in der Search Console auf die unangenehmste Weise möglich mitteilen.
Hier ist es. Die tatsächliche Checkliste, die ich bei Seahawk Media verwende, kein theoretisches Framework.
---
1. Beginnen Sie mit einem vollständigen Crawl, bevor Sie etwas anfassen
Offensichtlich? Ja. Übersprungen? Ständig.
Bevor eine einzige Datei verschoben wird, crawle ich die gesamte Live-Website mit Screaming Frog SEO Spider. Bei einer 20.000-Seiten-Website dauert das ein paar Stunden. Normalerweise starte ich das über Nacht mit dem Crawl im Datenbank-Modus, damit der Speicher kein Problem wird. Was ich erfasse:
- Jede indexierbare URL (die kanonische Version, nicht das Pagination-Rauschen)
- Response-Codes von überall, 200er, 301er, 302er, 404er, alles.
- Bestehende interne Linkstruktur
- Canonical-Tags, hreflang-Attribute falls zutreffend
- Seitentitel und Meta-Beschreibungen (damit ich überprüfen kann, dass sie die Migration überstehen)
Ich exportiere den vollständigen Crawl als CSV und speichere ihn. Das ist meine Baseline. Es ist das Dokument, das ich drei Wochen nach dem Go-live der neuen Site damit vergleichen werde.
Viele Leute überspringen diesen Schritt, weil „wir kennen die Website bereits." Das tut ihr nicht. Ich dachte, ich kenne die Website eines Travel-Kunden Anfang 2021, es stellte sich heraus, dass sie 4.000 URLs hatten, die von einem Legacy-CMS-Unterverzeichnis bereitgestellt wurden, das im Brief niemand erwähnt hatte. Ich habe es im Crawl gefunden. Das wäre eine Katastrophe gewesen.
Vergiss Googles eigene Daten nicht
Alles aus der Google Search Console ziehen, Performance-Daten der letzten mindestens 16 Monate, den Index-Coverage-Report, alle manuellen Maßnahmen, alle Sitemaps. Und aus Google Analytics ziehen (jetzt GA4, natürlich), sodass du deine Benchmarks für organischen Traffic festlegst, bevor sich etwas ändert. Screenshots funktionieren hier prima; ich exportiere auch die rohen CSVs.
---
2. Die Redirect-Map erstellen. Dann nochmal checken.
Das ist der Punkt, an dem Migrationen gelingen oder scheitern. Bei großen Websites ist die Redirect-Map ein echtes Tabellenkalkulationssheet, normalerweise in Google Sheets mit dem Client, ihrem Dev-Team und allen anderen geteilt, die versehentlich um 23 Uhr eine Formel überschreiben könnten.
Die Struktur ist einfach:
- Spalte A: Alte URL (exakt, inklusive Trailing Slash oder ohne)
- Spalte B: Neue URL (exakt)
- Spalte C: Redirect-Typ (301 in fast jedem Fall)
- Spalte D: Status (zugeordnet, verifiziert, live)
- Spalte E: Notizen (Catch-all-Redirects, Kategorie-Konsolidierungen, absichtliche Drops)
Bei einer 20.000-Seiten-Website kannst du offensichtlich nicht jede URL einzeln abbilden. So gehe ich vor:
- Alle Top-Performing-URLs zuerst mappen (nach organischem Traffic aus GSC, die Top 500 treiben normalerweise über 80 % des Traffics).
- Kategorie- und Taxonomie-Seiten abbilden
- Alle URLs mappen, die aussagekräftige Backlinks haben (nutze Ahrefs dafür, filtere nach verweisenden Domains, nicht nur rohen Links).
- Musterbasierte Redirects für alles andere verwenden (z. B. /product/old-slug/ → /shop/old-slug/)
- Absichtliche 410s für Seiten dokumentieren, die du ausmusterst
Musterbasierte Redirects sind das, das die meisten Junior-Developer falsch machen. Sie schreiben eine Wildcard-Regel, die zu breit ist, und schlucken versehentlich URLs, die sie gar nicht umleiten wollten. Teste jede Musterregel auf Staging, bevor sie auch nur in die Nähe von Production geht.
---
3. Staging Ist Nicht Optional
Ich halte das kurz, weil es nicht viel Erklärung braucht. Jede Migration bekommt eine Staging-Umgebung. Punkt.
Seahawk hatte 2022 einen Fintech-Client, der sich dagegen wehrte, wollte „einfach auf Live machen, weil die Website klein ist." Die Website hatte 6.000 Seiten. Wir haben es auf Staging gemacht. Wir haben einen Plugin-Konflikt gefunden, der Canonical-Tags von allen Produktseiten entfernte. Wäre unsichtbar gewesen, bis Google alles neu gecrawlt hätte, was bei einer Domain mit niedriger Autorität Wochen dauern kann.
Auf Staging überprüfst du:
- Alle Weiterleitungen funktionieren korrekt (ich verwende Screaming Frog erneut, auf Staging gerichtet, um die Weiterleitungskarte in Bulk zu verifizieren)
- Robots.txt blockiert die Staging-Umgebung von der Indexierung (wichtig, nutze Disallow: /, aber füge auch einen noindex-Header hinzu für doppelten Schutz)
- Die neue Sitemap ist korrekt und enthält keine Staging-URLs
- Kanonische Tags verweisen auf die richtigen Production-URLs
- Seiten-Geschwindigkeit-Baselines mit PageSpeed Insights, Migrationen werden oft als Redesign-Gelegenheiten genutzt, und Redesigns zerstören häufig Core Web Vitals
---
4. Die Go-Live-Abfolge (Reihenfolge ist wichtiger, als du denkst)
Das ist der Teil, wo Menschen improvisieren und sich selbst Probleme bereiten. Es gibt eine bestimmte Reihenfolge. Ich weiche nicht davon ab.
Schritt 1: Vor dem Start (48 Stunden vorher)
- Reduziere die TTL aller DNS-Einträge auf 300 Sekunden (5 Minuten). Das beschleunigt die Propagation erheblich.
- Briefing für den Client: keine Content-Änderungen, keine neuen Seiten, keine Plugin-Updates während des Migrationsfensters.
- Benachrichtige alle Third-Party-Integrationen (CDNs, Ad-Plattformen, Monitoring-Tools) von der bevorstehenden Änderung.
Schritt 2: Startfenster
- DNS aktualisieren
- Redirects vor der vollständigen Verbreitung des neuen Inhalts bereitstellen, Redirects sollten auf Server-Ebene live sein, nicht nur in WordPress
- Aktiviere die neue Sitemap, deaktiviere die alte.
- Verifiziere, dass robots.txt korrekt ist (Production-Datei, nicht die Staging-Version).
Schritt 3: Unmittelbar nach dem Start
- Crawl die neue Website innerhalb von zwei Stunden mit Screaming Frog, auf die Production verwiesen, unter Beachtung von Redirects. Ich suche nach unerwarteten 404ern, Redirect-Ketten, die länger als zwei Hops sind, und nach Seiten, die indexierbar sein sollten, aber ein noindex-Tag aufweisen.
- Die neue Sitemap in Search Console einreichen
- Die Homepage über das URL-Inspection-Tool von GSC abrufen, um Googlebot zum Besuch aufzufordern
Eine Sache, die ich Clients immer flagge: Google wird die neuen URLs nicht sofort in den Suchergebnissen abbilden. Es gibt einen Crawl- und Verarbeitungs-Lag. Bei einer großen Website solltest du zwei bis sechs Wochen einplanen, bevor du ein klares Bild hast. Bei Tag vier in Panik zu verfallen, weil Rankings sich verschoben haben, ist normal – es bedeutet nicht, dass etwas kaputt ist.
---
5. Redirect-Chain-Audit (Der Schritt, den die meisten Agenturen separat abrechnen)
Redirect-Ketten sind ein langsamer Blutverlust. Eine URL, die A → B → C → D durchläuft, zwingt Googlebot zu zusätzlicher Arbeit, und sie dilutiert auch Link-Equity über mehrere Hops hinweg. Auf einer Website, die mehrere frühere Migrationen oder Plattformwechsel hatte, können Ketten überraschend lang werden.
Nach dem Launch exportiere ich den vollständigen Screaming-Frog-Crawl und filtere nach Redirect-Ketten. Alles über zwei Hops hinaus wird zusammengefasst. Wenn die ursprüngliche URL auf der Redirect-Map war, aktualisiere ich sie so, dass sie direkt auf das finale Ziel verweist. War es eine Legacy-Kette aus einer nicht dokumentierten Migration, füge ich sie hinzu.
Dieser Schritt allein, bei einem Client, den wir Anfang 2023 von Magento zu WooCommerce migriert haben, dauerte zwei Tage. Sie hatten drei Migrationen über acht Jahre hinweg. Manche URLs durchliefen fünf Redirects, bevor sie auf der richtigen Seite landeten. Haben sie alle zusammengefasst, und ihre Crawl-Budget-Metriken in Search Console verbesserten sich innerhalb eines Monats merklich.
---
6. Inhaltsüberprüfung im großen Maßstab
Sie können 20.000 Seiten nicht manuell überprüfen. Aber Sie können systematisch die Dinge überprüfen, die wichtig sind.
Hier ist, was ich in den ersten zwei Wochen nach dem Launch überprüfe:
- Title Tags und Meta Descriptions: Vergleichen Sie eine zufällige Stichprobe von 200 Seiten mit dem Screaming Frog Export vor der Migration. Unstimmigkeiten werden sofort gekennzeichnet.
- Strukturierte Daten: Eine Auswahl von Produktseiten, Artikelseiten und der Homepage durch Google's Rich Results Test laufen lassen. Migrationen brechen Markup-Schemata öfter als man denkt, besonders wenn das neue Theme ein anderes Plugin nutzt.
- Interne Verlinkung: Screaming Frog Crawl, gefiltert nach eingehenden Links. Seiten mit hohem Wert sollten immer noch starke Zähler für interne Links haben. Wenn eine Kategorieseite, die zuvor 400 interne Links hatte, jetzt 12 hat, ist etwas in der Template schiefgelaufen.
- Bilder und Alt-Text: Nicht streng gesehen SEO-kritisch, aber fehlerhafte Bilder schaden den Nutzererlebnis-Signalen und sind auf Template-Seiten leicht zu übersehen.
---
7. Überwachung für die 90 Tage danach
Die Migration ist am Launch-Tag nicht vorbei. Sie läuft mindestens 90 Tage.
Ich habe mit dem Client wöchentliche Reportingzyklen im ersten Monat etabliert, danach alle zwei Wochen. Das beobachte ich:
- GSC Index Coverage: Erholt sich die Anzahl der indexierten Seiten in Richtung des Pre-Migration-Stands? Ein signifikanter Rückgang, der länger als drei Wochen anhält, bedarf einer Untersuchung.
- Organischer Traffic vs. Baseline: Segmentiert nach Landing-Page-Typ (Produkt, Kategorie, Blog). Traffic-Rückgänge sind oft ungleich verteilt, manchmal brechen Kategorieseiten ein, während Produktseiten stabil bleiben.
- Crawl Budget: GSC's Crawl-Stats-Report zeigt durchschnittlich gecrawlte Seiten pro Tag und Server-Response-Zeiten. Wenn Googlebot auf viele 404er trifft, sieht man das hier.
- Ranking-Position-Tracking: Ich nutze eine Kombination aus Ahrefs Rank Tracking und dem Performance-Report der Google Search Console. Ranking-Volatilität in den ersten zwei bis drei Wochen ist normal und nicht zwingend ein Problem. Anhaltende Rückgänge nach Woche vier rechtfertigen Maßnahmen.
- Backlink-Profil: Mit Ahrefs überprüfen, dass hochwertige Backlinks auf alte URLs entweder bereits korrekt weitergeleitet sind oder zur Aktualisierung der Kontakte gekennzeichnet sind.
Die ehrliche Wahrheit? Die meisten Migration-SEO-Probleme lassen sich innerhalb von 30 Tagen erkennen, wenn man die richtigen Metriken beobachtet. Die Probleme, die Menschen treffen, entstehen dort, wo niemand Monitoring aufgesetzt hat und der Client es acht Monate später bemerkt.
---
8. Die Dinge, bei denen ich danebengegriffen habe (damit du es nicht musst)
2019 habe ich eine hreflang-Implementierung bei einer Migration für einen Client mit UK-, Australian- und Canadian-Subfoldern übersehen. Die Canonical-Tags waren korrekt. Die Redirects waren in Ordnung. Aber die hreflang-Annotationen auf der neuen Website hatten die falschen Region-Codes, en-au statt en-AU (Groß-/Kleinschreibung ist offenbar in manchen Implementierungen wichtig). Google fing an, die UK-Seiten an australische Sucher auszuliefern. Es hat uns sechs Wochen gekostet, herauszufinden, warum der australische organische Traffic um die Hälfte gefallen war. Seitdem haben wir einen hreflang-Validierungsschritt in jeder internationalen Migration.
Noch einer: XML-Sitemaps, die noindex-markierte URLs enthalten. Das klingt nach einer kleinen Inkonsistenz, sendet aber widersprüchliche Signale und ist wirklich einen Cleanup wert. Screaming Frog kann deine Sitemap prüfen und jede URL darin kennzeichnen, die einen noindex-Tag zurückgibt.
Und wahrscheinlich die teuerste Lektion: keinen Rollback-Plan zu haben. Bei einer Migration, die schiefläuft, ist die Möglichkeit, das DNS innerhalb einer Stunde zurück auf den alten Server zu wechseln, unbezahlbar. Ich bestehe immer darauf, dass die alte Umgebung mindestens 30 Tage nach der Migration aktiv und intakt bleibt. Kunden wehren sich manchmal gegen die Hosting-Kosten. Ich erkläre ihnen, was ein Traffic-Rückgang von 70 % den Umsatz kostet, und dann hören sie auf zu protestieren.
---
FAQ
Wie lange dauert es wirklich, eine Migration einer 20.000-Seiten-Website zu planen?
Realistisch gesehen? Sechs bis zehn Wochen Vorbereitung vor dem Go-Live-Datum. Die Redirect-Map allein kann bei einer Website dieser Größe zwei bis drei Wochen dauern, um sie richtig zu erstellen, besonders wenn du Backlinks für jede URL prüfst. Wenn man die Vorbereitung überstürzt, endet man in Monaten der Fehlersuche.
Muss ich nach einer Migration eine Disavow-Datei einreichen?
Normalerweise nicht, es sei denn, die alte Domain hatte toxische Links und du migrierst gezielt, um ihnen zu entgehen. Wenn du zu einer neuen Domain migrierst und ein sauberes Link-Profil möchtest, kümmere dich um das Disavow auf der neuen Property in GSC. Aber bei den meisten Plattform- oder Redesign-Migrationen in der gleichen Domain ist Disavow irrelevant.
Was ist der größte Fehler, den du Agenturen bei großen Migrationen machen siehst?
Die Redirect-Map als Dev-Task zu behandeln. Redirects sind eine SEO-Task, die ein Developer umsetzt. Das SEO-Team, oder wer die Search-Strategie verantwortet, sollte die Map besitzen, sie reviewen und freigeben. Ich habe Entwickler gesehen, die technisch korrekte Redirect-Regeln gebaut haben, die SEO-falsch waren, weil niemand ihnen gesagt hat, welche URL-Variante kanonisch ist.
Beeinflusst die Seitengeschwindigkeit SEO bei Migrationen?
Ja, deutlich mehr als viele denken. Core Web Vitals zählen für Rankings, und bei Redesigns passiert es schnell, dass mehr JavaScript mitkommt oder die Bilder nicht richtig optimiert sind. Vergleich die alte und neue Website immer vorher mit PageSpeed Insights. Sollte die neue auf dem Handy deutlich langsamer sein, beheb das vor dem Switch.
Wie gehst du mit Migrationen für Websites mit viel benutzergenerierten Inhalten um?
Mit Vorsicht. UGC-Seiten sind einzeln oft von niedriger Qualität, generieren aber kollektiv viel Long-Tail-Traffic. Ich empfehle normalerweise einen Crawl-und-Analyse-Schritt: Identifiziere, welche UGC-URLs überhaupt organischen Traffic bekommen, leite gezielt diese um, und verwende für den Rest 410-Status-Codes statt 404. Ein 410 teilt Google mit, dass die Seite absichtlich weg ist; ein 404 ist mehrdeutig.
---
Migrationen sind eine dieser Sachen, wo der Unterschied zwischen gut und katastrophal fast vollständig in der Vorbereitung liegt. Die technische Umsetzung ist üblicherweise der einfache Teil. Die Pre-Launch-Arbeit richtig hinzubekommen, den Crawl, die Redirect-Map, die Staging-Verifikation – dort passiert die echte Arbeit. Und falls dir je eine Migration in die Hände fällt, die schon live und schon kaputt ist, gilt die Checkliste immer noch. Du machst sie nur rückwärts.