SEO Migration
Ein Website-Relaunch ist aus SEO-Sicht kein Design-Projekt, sondern ein Migrationsprojekt: URLs, interne Verlinkung, Canonicals, Index-Regeln, Performance und Content-Signale ändern sich oft gleichzeitig. Ranking-Einbrüche entstehen selten, weil Google Relaunches nicht mag, sondern weil Signale verloren gehen.
27.02.2026 · 18 Min · Aktualisiert 12.03.2026
TL;DR
Google kann eine Website sauber neu bewerten, wenn bestehende Signale korrekt übertragen werden. Genau deshalb braucht ein Relaunch ein Runbook: Inventar -> Mapping -> Implementierung -> QA -> Go-Live -> Monitoring.
In den offiziellen Search-Central-Migrationsleitfäden zieht sich dieselbe Logik durch: vorbereiten, testen, URL-Mapping bauen, serverseitig weiterleiten und danach aktiv überwachen.
Die Checkliste ist für Teams gedacht, die einen Relaunch mit klaren Verantwortlichkeiten und messbaren Ergebnissen durchführen wollen.
Wenn du das Runbook konsequent umsetzt, hast du vor dem Go-Live einen belastbaren Satz an Unterlagen für Umsetzung, Abnahme und Stabilisierung.
In einem typischen B2B-Relaunch mit rund 150 bis 300 indexierbaren URLs reicht keine pauschale Redirect-Regel. Entscheidend ist, dass jede relevante Alt-URL nach Suchintent, Business-Wert und Seitentyp bewertet wird.
Der eigentliche Hebel liegt nicht in der Menge der Redirects, sondern in der Passung. Eine ehemals starke SEO-Landingpage darf nicht in einem Sammelziel verschwinden, nur weil die neue Navigation kompakter geworden ist.
Wenn du mitten in der Planung steckst, starte mit diesen 12 Punkten. Sie sind die nicht verhandelbare Liste. Alles andere ist spätere Optimierung.
Nicht jeder Relaunch hat dasselbe Risiko. Je mehr du gleichzeitig veränderst, desto höher wird das SEO-Risiko und desto strenger müssen deine Launch-Gates sein.
Relaunches scheitern oft daran, dass Design messbar ist, SEO-Sicherheit aber nicht als verbindliches Ziel dokumentiert wird. Deshalb brauchst du harte Kriterien, nicht nur gute Absichten.
Definiere vorab, welche Seiten keinesfalls verlieren dürfen und wer den Launch im Zweifel stoppt.
Ohne Vorher-Daten kannst du nach dem Relaunch kaum unterscheiden, ob eine Bewegung normal ist oder ob Signale verloren gingen.
Eine gute Baseline beinhaltet nicht nur Traffic, sondern auch Queries, URL-Status und technische Kennzahlen.
Ein Menü-Export reicht nie aus. Ein belastbares Inventar kombiniert Crawl, Sitemap, Search Console, Analytics und wenn möglich Logfiles.
Jede Alt-URL bekommt genau eine Entscheidung: Keep (200), Redirect (301/308) oder Remove (410).
Redirects sind der Signal-Bus der Migration. Sie wirken nur sauber, wenn Zielseiten fachlich passen und dauerhaft auf stabile Endziele zeigen.
Irrelevante Massen-Redirects, vor allem auf die Startseite, verschlechtern Nutzerpfade und können als Soft-404 Muster gewertet werden.
Technisch perfekte Migration kann trotzdem verlieren, wenn Suchintent gebrochen wird: wichtige Inhalte fehlen, Themen werden unpassend zusammengelegt oder Conversion-Pfade werden geschwächt.
Prüfe für jede Tier-1 URL die Intent-Parity: Erfüllt die neue Seite den Zweck mindestens gleich gut wie die alte?
Relaunch-Fehler entstehen oft systemisch über Templates: Canonical falsch, noindex falsch, duplizierte Titles. Deshalb braucht jeder Seitentyp ein verbindliches Pflichtset.
Ein Klassiker im Relaunch: Staging wird indexiert. Das führt zu Duplicate-Problemen, Canonical-Chaos und unnötiger Bereinigung nach Launch.
Robots allein reicht dafür nicht. Die sauberste Schicht ist Zugriffsschutz (Auth/IP), noindex ist zusätzliche Absicherung.
Wichtig: noindex wirkt nur, wenn Google die Seite auch crawlen kann. Eine harte robots-Blockade kann noindex aushebeln.
Vor dem Go-Live ist ein Full-Crawl Pflicht: Redirects, Statuscodes, interne Links, Canonicals, noindex-Regeln, Titles und H1 müssen stimmen.
Migrationen sind ein Prozess. QA ist der Nachweis, dass Planung und Umsetzung wirklich belastbar sind.
Canonical ist ein Hinweis, keine harte Anweisung. Deshalb ist Konsistenz in Host, Protokoll, Slash-Policy und internen Links entscheidend.
Im Relaunch entstehen hier häufig Fehler durch Mischformen wie www/non-www, http/https oder inkonsistente Trailing-Slash-Varianten.
Sitemaps sind Discovery- und Steuerungsinstrumente. Sie funktionieren nur sauber, wenn sie indexierbare Ziel-URLs enthalten und mit Canonical-Regeln konsistent sind.
robots.txt darf keine für Rendering nötigen Assets unabsichtlich blockieren.
Performance ist kein Nice-to-have. Sie wirkt direkt auf Nutzerverhalten und ist Teil der technischen Qualität deines Relaunches.
Prüfe Core Web Vitals auf den wichtigsten Landingpages, nicht nur auf der Startseite.
Wenn Tracking am Relaunch-Tag bricht, fehlt die Grundlage für jede belastbare Bewertung. Deshalb gehört Tracking-QA in die Launch-Abnahme.
Smoke-Tests für Conversion-Pfade sollten auf Stage und direkt nach Live erfolgen.
Ein Relaunch scheitert häufig am Launch-Tag: fehlende Redirect-Regeln, falsche robots/noindex Settings, 5xx-Spikes oder kaputtes Tracking.
Ein Runbook mit Reihenfolge, Verantwortlichkeiten und Rollback reduziert dieses Risiko drastisch.
Go/No-Go Gates verhindern Relaunch-Katastrophen. Wenn harte Kriterien verletzt sind, wird nicht live geschaltet.
Nach Launch gibt es immer Noise. Entscheidend ist, echte Fehler schnell zu priorisieren und die richtigen Hebel zuerst zu fixen.
Google empfiehlt nach Site-Moves explizit Monitoring von Traffic, Indexierung und Crawling.
Wenn sich die Domain ändert, kommt zur normalen Migration ein zusätzlicher Schritt in Search Console: Change of Address (für passende Property-Setups).
Redirects sollten nicht zu früh entfernt werden. In der Praxis bleiben sie deutlich länger aktiv, solange Signale über alte URLs laufen.
Bei mehrsprachigen Projekten ist hreflang ein typischer Relaunch-Painpoint. Sobald URLs wechseln, müssen hreflang-Referenzen konsistent aktualisiert werden.
Fehlende Gegenseitigkeit oder inkonsistente URLs führen schnell dazu, dass hreflang ignoriert wird.
Diese Fehler tauchen in Relaunches immer wieder auf und sind in fast allen Fällen vermeidbar.
Wenn du nur eine Liste in dein Projektboard übernimmst, dann diese:
Ein sauberes Mapping trennt kontrollierte Migration von Chaos. Pro URL sollten mindestens diese Felder gepflegt werden:
Ein Relaunch wird stabil, wenn du ihn wie eine Migration behandelst: Signale sauber übertragen, Indexierung kontrollieren, Soft-404 Muster vermeiden und alles vor Go-Live technisch verifizieren.
Genau dieses Gate-System verhindert die typischen Katastrophen: verlorene URLs, kaputte interne Links, falsche Indexierung und Traffic-Einbrüche ohne klare Ursache.
Nein. Irrelevante Redirects auf die Homepage verschlechtern die Nutzerführung und können als Soft-404 Muster interpretiert werden. Besser: thematisch passendes Ziel pro URL oder bewusst 404/410, wenn kein Ersatz existiert.
Bei dauerhaften URL-Änderungen nutze permanente Redirects (301/308). Temporare Redirects (302/307) sind für wirklich kurzfristige Situationen gedacht.
Weil noindex nur gesehen wird, wenn die Seite crawlbar ist. Wird die URL gleichzeitig per robots.txt blockiert, kann Google den noindex unter Umständen nicht auslesen.
In die Sitemap gehören die URLs, die in Search erscheinen sollen - in der Regel die Canonical-URLs. Mehrfach erreichbare Inhalte sollten auf eine bevorzugte URL konsolidiert sein.
Bei Domain-Moves empfiehlt Google mindestens 180 Tage. In der Praxis bleiben Redirects meist länger aktiv, solange alte URLs noch Signale oder Traffic liefern.
Soft-404 entstehen z. B. wenn nicht existente Seiten mit 200 antworten, aber keinen echten Inhalt liefern. Das verwirrt Nutzer und verschwendet Crawl-Ressourcen.
Quellen
SEO Audit
Enterprise-Runbook für technische SEO Audits: Datenquellen, Audit-Ablauf, priorisierter Output und die häufigsten Ursachen für Indexierungs-, Canonical- und Rendering-Probleme.
Aktualisiert 13.03.2026 · 19 Min
Conversion
Enterprise-Blueprint für B2B-Landingpages: Struktur in 12 Bausteinen, Copy-Formeln, Trust-Layer, CTA- und Formular-Patterns für mehr qualifizierte Leads.
Aktualisiert 09.03.2026 · 15 Min
Performance
Runbook statt Score-Jagd: Grenzwerte, 75. Perzentil, Field vs Lab und priorisierte Fixes für LCP, INP und CLS mit echtem UX-Impact.
10.02.2026 · 16 Min
Technische SEO-Grundlagen & Performance: Crawl/Index-Checks, Core Web Vitals, Pagespeed, Rendering, Redirects und saubere URL-Strukturen mit priorisiertem Maßnahmenplan und Umsetzung.
Leistung ansehen
Moderne Webprojekte mit sauberer technischer Umsetzung, klarer Struktur und verlässlicher Performance.
Leistung ansehen
Beratung, Analyse & Weiterentwicklung: Code- und Architektur-Review, klare Priorisierung, Roadmap und Aufwandsschätzung - plus Umsetzung, damit aus Planung messbarer Fortschritt wird.
Leistung ansehen
CMS-basierte Webseiten mit sauberer Content-Struktur: Headless CMS oder WordPress, Templates und Komponenten, Vorschau-Workflows, Migration und SEO-Felder, damit Inhalte schnell, konsistent und auffindbar bleiben.
Leistung ansehen
Autor
Fachinformatiker und Entwickler hinter Reimcode
Michael Reimer entwickelt mit Reimcode Websites, Web-Apps und technische Setups mit Fokus auf saubere Umsetzung, klare Struktur und belastbare Entscheidungen.
Mehr über michNächster Schritt
Wenn du willst, reviewe ich dein Mapping, deine QA-Gates und dein Go/No-Go Setup - damit der Launch als kontrollierte Migration läuft und nicht als Risiko-Event.