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.Site migrations lose rankings through skipped redirect audits, not platform changes; the checklist is redirect map, metadata transport, schema continuity, and post-launch verification.
Diese Erfahrung – schmerzhaft, wie sie war – ist im Grunde der Grund, warum diese Checkliste existiert. Seitdem habe ich Sites migriert, die von 800-Seiten-Broschüren bis zu einem 31.000-Seiten-Publisher mit regionalen Subdomains reichen, und die Grundlagen sind jedes Mal gleich. Wenn du die Reihenfolge falsch machst, einen Schritt überspringst, wird dir Google das in der Search Console auf die unangenehmste Art mitteilen.
Hier ist es. Die tatsächliche Checkliste, die ich bei Seahawk Media verwende, kein theoretisches Framework.Seahawk Media, not a theoretical 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-Site mit Screaming Frog SEO Spider. Bei einer 20.000-Seiten-Site dauert das ein paar Stunden – ich starte das normalerweise nachts mit dem Crawl im Datenbank-Modus, damit der Speicher kein Problem wird. Was ich erfasse:Screaming Frog SEO Spider. On a 20,000-page site this takes a couple of hours -- I usually kick it off overnight with the crawl stored to database mode so memory doesn't become an issue. What I'm capturing:
- Jede indexierbare URL (die kanonische Version, nicht das Pagination-Rauschen)
- Response-Codes insgesamt – 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 Menschen überspringen diesen Schritt, weil „wir kennen die Site ja bereits." Das ist nicht wahr. Ich dachte 2021, ich kenne die Site eines Travel-Clients – es stellte sich heraus, dass sie 4.000 URLs hatten, die aus einem Legacy-CMS-Unterverzeichnis bereitgestellt wurden, das niemand im Briefing erwähnt hatte. Ich habe es im Crawl gefunden. Das wäre eine Katastrophe gewesen.
Vergiss Googles eigene Daten nicht
Hole alles aus Google Search Console – Performance-Daten für mindestens die letzten 16 Monate, den Index-Coverage-Report, alle manuellen Maßnahmen, alle Sitemaps. Und hole Daten aus Google Analytics (GA4 jetzt, verständlich), damit deine Benchmarks für organischen Traffic feststehen, bevor sich etwas ändert. Screenshots funktionieren hier prima; ich exportiere auch die rohen CSVs.Google Search Console -- performance data for the last 16 months minimum, the index coverage report, any manual actions, all sitemaps. And pull from Google Analytics (GA4 now, obviously) so you have your organic traffic benchmarks locked down before anything changes. Screenshots work fine here; I also export the raw CSVs.
---
2. Die Redirect-Map erstellen. Dann nochmal checken.
Das ist der Punkt, wo Migrationen gelingen oder scheitern. Bei großen Sites ist die Redirect-Map eine echte Tabelle – normalerweise in Google Sheets geteilt mit dem Client, seinem Dev-Team und allen anderen, die um 23 Uhr versehentlich 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:
- Mache zunächst alle Top-Performer-URLs ab (nach organischem Traffic aus GSC – die Top 500 bringen normalerweise über 80 % des Traffic).
- Kategorie- und Taxonomie-Seiten abbilden
- Mache alle URLs ab, die aussagekräftige Backlinks haben (nutze Ahrefs dafür – filtere nach verweisenden Domains, nicht nur nach rohen Links).Ahrefs for this -- filter by referring domains, not just raw links)
- Musterbasierte Redirects für alles andere verwenden (z. B. /product/old-slug/ → /shop/old-slug/)
/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-Kunden, der dagegen Widerstand leistete – wollte „es einfach live machen, weil die Website klein ist". Die Website hatte 6.000 Seiten. Wir haben es auf dem Staging gemacht. Wir fanden einen Plugin-Konflikt, der kanonische Tags von allen Produktseiten entfernte. Das wäre unsichtbar geblieben, bis Google alles neu gecrawlt hätte, was auf einer Domain mit geringer 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 vor dem Indexieren (wichtig – verwenden Sie Disallow: /, aber fügen Sie auch einen noindex-Header für doppelten Schutz hinzu)
Disallow: /but also add a noindex header for double protection) - Die neue Sitemap ist korrekt und enthält keine Staging-URLs
- Kanonische Tags verweisen auf die richtigen Production-URLs
- Seitengeschwindigkeit-Baselines mit PageSpeed Insights – Migrationen werden oft als Redesign-Gelegenheiten genutzt, und Redesigns zerstören häufig Core Web VitalsPageSpeed Insights -- migrations are often used as redesign opportunities, and redesigns frequently destroy 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 Ausbreitung des neuen Inhalts bereitstellen – Redirects sollten auf Serverebene live sein, nicht nur in WordPressWordPress
- 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 Kunden immer flagge: Google wird die neuen URLs nicht sofort in den Suchergebnissen widerspiegeln. Es gibt eine Crawl- und Neuverarbeitungsverzögerung. Auf einer großen Website sollten Sie zwei bis sechs Wochen einplanen, bevor Sie ein klares Bild haben. Am vierten Tag in Panik zu geraten, weil sich die Rankings 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 Kunden, den wir Anfang 2023 von Magento zu WooCommerce migriert haben – dauerte zwei Tage. Sie hatten drei Migrationen über acht Jahre hinweg gehabt. Einige URLs gingen durch fünf Redirects, bevor sie auf der richtigen Seite landeten. Wir haben alles 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.: Compare a random 200-page sample against the pre-migration Screaming Frog export. Mismatches get flagged immediately.
- 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.: Run a sample of product pages, article pages, and the homepage through Google's Rich Results Test. Migrations break schema markup more often than you'd think, especially if the new theme uses a different plugin.
- 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.: Screaming Frog crawl, filter for inlinks. High-value pages should still have strong internal link counts. If a category page that previously had 400 internal links now has 12, something went wrong in the template.
- Bilder und Alt-Text: Nicht streng gesehen SEO-kritisch, aber fehlerhafte Bilder schaden den Nutzererlebnis-Signalen und sind auf Template-Seiten leicht zu übersehen.: Not strictly SEO-critical, but broken images hurt user experience signals and they're easy to miss on templated sites.
---
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.: Is the number of indexed pages recovering toward the pre-migration count? A significant drop that persists beyond three weeks needs investigation.
- Organischer Traffic im Vergleich zur Baseline: Segmentiert nach Landing-Page-Typ (Produkt, Kategorie, Blog). Traffic-Rückgänge sind oft ungleichmäßig – manchmal tanken Kategorieseiten ab, während Produktseiten stabil bleiben.: Segmented by landing page type (product, category, blog). Traffic drops are often uneven -- sometimes category pages tank while product pages hold.
- 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.: GSC's crawl stats report shows average pages crawled per day and server response times. If Googlebot is hitting a lot of 404s, it shows here.
- 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.: I use a combination of Ahrefs rank tracking and Google Search Console's performance report. Ranking volatility in the first two to three weeks is common and not necessarily a problem. Sustained drops beyond week four warrant action.
- Backlink-Profil: Mit Ahrefs überprüfen, dass hochwertige Backlinks auf alte URLs entweder bereits korrekt weitergeleitet sind oder zur Aktualisierung der Kontakte gekennzeichnet sind.: Using Ahrefs, verify that high-value backlinks pointing to old URLs are either already redirected correctly or flagged for outreach to update.
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 Kunden mit UK-, australischen und kanadischen Unterordnern verpasst. Die kanonischen Tags waren korrekt. Die Redirects waren in Ordnung. Aber die hreflang-Annotationen auf der neuen Website hatten die falschen Regionscodes – en-au statt en-AU (die Groß-/Kleinschreibung ist anscheinend in einigen Implementierungen wichtig). Google begann, die UK-Seiten für australische Suchende bereitzustellen. Es dauerte uns sechs Wochen, um herauszufinden, warum der australische organische Traffic sich halbiert hatte. Wir haben seit dann einen hreflang-Validierungsschritt bei jeder internationalen Migration.en-au instead of en-AU(case matters, apparently, in some implementations). Google started serving the UK pages to Australian searchers. Took us six weeks to figure out why Australian organic traffic had halved. We've had a hreflang validation step in every international migration since.
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?
Den Redirect-Plan als Dev-Aufgabe behandeln. Redirects sind eine SEO-Aufgabe, die ein Entwickler implementiert. Das SEO-Team – oder wer die Suchstrategie leitet – sollte den Plan besitzen, ihn überprüfen und freigeben. Ich habe Entwickler gesehen, die technisch korrekte Redirect-Regeln gebaut haben, die SEO-falsch waren, weil niemand ihnen sagte, welche URL-Variante kanonisch war.
Beeinflusst die Seitengeschwindigkeit SEO bei Migrationen?
Ja, mehr als die meisten Menschen berücksichtigen. Core Web Vitals sind ein Ranking-Faktor, und Redesigns – die oft Migrationen begleiten – führen häufig zu schwereren JavaScript oder nicht optimierten Bildern. Führen Sie immer einen PageSpeed Insights-Vergleich zwischen der alten und neuen Website vor dem Start durch. Wenn die neue Website auf Mobilgeräten merklich langsamer ist, beheben Sie das, bevor Sie den Schalter umlegen.
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 eines dieser Dinge, bei denen der Unterschied zwischen gut und katastrophal fast ausschließlich in der Vorbereitung liegt. Die technische Umsetzung ist normalerweise der einfache Teil. Die Arbeit vor dem Launch richtig zu machen – das Crawling, die Redirect-Zuordnung, die Staging-Verifikation – das ist die echte Arbeit. Und wenn dir jemals eine Migration übergeben wird, die bereits live ist und bereits defekt, gilt die Checkliste immer noch. Du machst sie nur rückwärts.