Site-Migration ohne SEO-Verluste

Ich habe gesehen, wie fünfstellige Migrationen zu sechsstelligen SEO-Katastrophen wurden, weil das Team Migration als technisches Problem statt als Kontinuitätsproblem behandelt hat. Das Muster ist immer gleich. Neue Site bauen. Schalter umwerfen. Organischen Traffic um vierzig bis siebzig Prozent in den nächsten acht Wochen sinken sehen. Das nächste Quartal damit verbringen, zu versuchen, das am Umzugstag Verlorene zurückzugewinnen.

Der technische Umzug ist selten das, was dich umbringt. Redirect-Maps, die zu achtzig Prozent fertig sind, bringen dich um. Canonical-Tags, die auf Staging-Domains verweisen, bringen dich um. Interne Links, die noch auf die alte Struktur verweisen, bringen dich um. URL-Änderungen, die „nebenbei" vorgenommen werden, bringen dich um. Der Build selbst ist die einfache Sache; die Kontinuitätsarbeit ist das, das bei jeder Migration, die ich in großem Maßstab geliefert habe, über Erfolg oder Misserfolg entscheidet.

Fünf Dinge, über zwölftausend Sites bei Seahawk Media mühsam gelernt. Jeder ist nicht verhandelbar bei jeder Migration, die wir liefern.

Zunächst wird die Redirect-Map vor jeglichem Code erstellt. Jede alte URL erhält eine 301-Weiterleitung zu ihrem neuen Pendant. Wir exportieren die Quell-URL-Liste aus Search Console, Ahrefs und der bestehenden Sitemap, dann bauen wir die Zuordnung in einem Spreadsheet auf, das zur Single Source of Truth für den Cutover wird. Der Build-Linter stoppt den Deploy, wenn eine Pre-Migration-URL in der Map fehlt.

Zweitens wird die URL-Struktur überall dort beibehalten, wo die neue Plattform es zulässt. Jede URL-Änderung ist ein Ranking-Risiko. Wir ändern URLs nur dann, wenn es einen echten inhaltlichen Grund gibt — ein Duplicate, ein Tippfehler, ein Canonical, das wir konsolidieren — niemals, weil die neue Plattform eine andere Konvention vorschlägt. Die Versuchung, nebenbei „aufzuräumen", hat in unserer Migration-Praxis mehr Rankings gekostet als jede andere Entscheidung.

Drittens: Websites mit über zehntausend Seiten bekommen einen gestaffelten Rollout. Die Traffic-schwächsten Inhalte zuerst migrieren, validieren, dass die Rankings halten, dann erweitern. Eine gestaffelte Migration begrenzt den Blast Radius, falls etwas bei einem bestimmten Template oder Content-Type schiefgeht, und gibt dem Team die Chance, das Problem zu beheben, bevor die High-Traffic-Seiten betroffen sind.

Viertens eine Parallel-Betriebsphase. Die alte Website bleibt dreißig Tage nach dem Launch im Read-Only-Modus online. Falls die neue Website ein Problem hat, wird Traffic sofort zurückgeleitet. Die Kosten für den Betrieb zweier Stacks einen Monat lang sind klein im Vergleich zu einem vier-Wochen-Traffic-Recovery-Zyklus.

Fünftens neunzig Tage Post-Launch-Monitoring. Search Console Crawl-Statistiken, Indexierungs-Coverage, Impressionen, Log-Datei-Analyse, Schema-Validator, Core Web Vitals Felddaten. Regressions in Tagen beheben, nicht in Quartalen. Nach Tag neunzig ist die Website stabil und wir übergeben entweder sauber oder gehen in einen laufenden Care-Plan über.

Eine Handvoll von Migration-Mustern macht fast die gesamte Projektarbeit aus. Jedes hat sein eigenes Playbook und seine eigenen typischen Fehlermodi.

WordPress zu Next.js oder Astro ist das häufigste Engagement. Die Aufgabe ist meist eine Marketing- oder Content-Website, die an der Performance-Grenze von klassischem WordPress angekommen ist, und ein Team, das moderne Frontend-DX haben will, ohne wp-admin für das Editorial-Team zu verlieren. Headless WordPress mit WPGraphQL plus ein Next.js oder Astro Frontend befriedigt beide Seiten.

Drupal, Sitecore oder Typo3 zu WordPress ist das zweite Muster. Weg von Legacy-Enterprise-CMS, ohne die SEO-Rankings zu brechen, die das Legacy-Team über ein Jahrzehnt aufgebaut hat. Langsamere Migrationen, komplexere Content-Modellierung, aber das Playbook ist dasselbe — vollständige Redirect-Map, bewahrte URLs wo möglich, Parallel-Betrieb, gestaffelter Rollout.

Shopify zu Headless Commerce ist das dritte. Shopify Plus Storefront mit einem Next.js oder Hydrogen Frontend, vollständig benutzerdefiniertes Design, schnellere Core Web Vitals, bewahrter Commerce-Engine. Shopify bleibt die Source of Truth für Katalog, Inventar und Checkout; das Frontend wird benutzerdefiniert.

Die anderen Muster, die wir regelmäßig sehen, sind Domain-Konsolidierung (mehrere Legacy-Domains werden in einer mit korrekter Canonical- und Redirect-Strategie zusammengeführt), Subdomain-zu-Verzeichnis-Konsolidierung (Blog von blog.example.com zu example.com/blog/ verschieben, um Link-Equity zu bündeln) und Hosting- sowie Platform-Migrationen (verwaltetes WordPress zwischen Kinsta, WP Engine, Pressable oder zu Bare-Metal-Infrastruktur verschieben).

Seiten mit weniger als tausend Seiten benötigen vier bis acht Wochen end-to-end inklusive Planung, Redirect-Mapping, Content-Migration, QA und Post-Launch-Überwachung. Seiten mit zehntausend bis zwanzigtausend Seiten benötigen zwölf bis zwanzig Wochen. Enterprise-Migrationen von fünfzigtausend Seiten oder mehr dauern mindestens sechs bis neun Monate, mit schrittweisen Rollouts und parallelen Betriebsphasen im Zeitplan eingeplant.

Die größte Variable ist die Content-Qualität an der Quelle. Unübersichtliche Taxonomien, doppelte URLs und inkonsistente Metadaten addieren Wochen zur Planungsphase. Wir werden dir während des Audits ehrlich sagen, ob deine Quellseite migrationsbereit ist oder ob sie erst einen Content-Cleanup-Durchgang benötigt. So zu tun, als wäre die Quelle clean, wenn sie es nicht ist, ist der Grund, warum Migrationen von einem Quartal in ein halbes Jahr rutschen.

Ehrliche Spannbreiten aus echten kürzlichen Engagements. Eine KMU-Migration unter fünfhundert Seiten kostet vier- bis zwölftausend Pfund. Eine Mid-Market-Migration von ein- bis zehntausend Seiten kostet fünfzehntausend bis sechzigtausend. Eine Enterprise-Migration von zehntausend bis hunderttausend Seiten kostet sechzigtausend bis dreihunderttausend Pfund, inklusive fortlaufender Post-Launch-SEO-Unterstützung für das erste Quartal.

Etwa dreißig bis vierzig Prozent der Kosten gehen in Planung und QA, nicht in den technischen Build. Die Teams, die dir günstig anbieten, sind die, die die Planung überspringen. Du zahlst dafür später in verlorenen Rankings, und die Kosten zum Wiederaufbau von Rankings sind immer höher als die Kosten, sie von Anfang an zu bewahren.