Fragen Sie beliebige SEO-Fachleute nach den schlimmsten Trafficeinbrüchen, die sie erlebt haben — kaum jemand nennt ein Algorithmus-Update. Genannt wird der Relaunch: ein Redesign, ein Plattformwechsel, ein Domainumzug, live gegangen an einem Freitagnachmittag, ohne dass jemand die Weiterleitungen geprüft hat.
Das Ärgerliche daran: Relaunch-Verluste sind fast vollständig vermeidbar. Sie entstehen nicht durch etwas Rätselhaftes, sondern durch eine kleine, gut bekannte Menge von Fehlern unter Termindruck. Diese Checkliste deckt sie alle ab — in der Reihenfolge, in der die Arbeit tatsächlich abläuft.
Möchten Sie SEO-Probleme auf jeder Website finden?
Testen Sie WebSEO Auditor kostenlos — führen Sie Ihr erstes Audit in Sekunden durch.
Kostenlos testenWissen, welche Art von Migration ansteht
| Typ | Was sich ändert | Risiko |
|---|---|---|
| Design-Refresh | Nur Optik, URLs und Inhalte bleiben | Niedrig |
| Protokoll- oder Hostwechsel | HTTP zu HTTPS oder neues Hosting | Niedrig bis mittel |
| Neue URL-Struktur | Neue Pfade, gleiche Domain | Hoch |
| Plattform- oder CMS-Wechsel | Neues System, meist neue URLs und Templates | Hoch |
| Domainwechsel | Alles zieht um | Sehr hoch |
Die wirksamste Risikoentscheidung: Typen nicht kombinieren. Wer Plattform, URL-Struktur und Design gleichzeitig ändert, kann bei einem Einbruch die Ursache nicht zuordnen. Vier bis sechs Wochen Abstand machen jedes Problem diagnostizierbar.
Phase 1: Basiswerte erfassen, bevor Sie etwas anfassen
- Vollständiger Crawl der bestehenden Website — jede URL mit Statuscode, Titel, Description, H1, Wortzahl, Canonical und internen Inlinks.
- Search-Console-Export — 16 Monate Klicks, Impressionen, Durchschnittsposition je Seite und Query.
- Analytics-Export — Sitzungen, Conversions und Umsatz je Landingpage.
- Backlink-Export — jede verweisende Domain samt Ziel-URL. Diese Seiten dürfen nie brechen.
- Ranking-Snapshot für die hundert wichtigsten Keywords.
- Core-Web-Vitals-Basiswerte je Template.
Phase 2: Die Weiterleitungskarte bauen
- Alte auf neue URL eins zu eins abbilden.
- 301 verwenden, nicht 302.
- Niemals alles auf die Startseite weiterleiten — Suchmaschinen werten das als Soft 404.
- Ketten auflösen. A auf B ist gut; A auf B auf C verliert Wert.
- Den Long Tail abdecken. Musterregeln für die Masse, manuelle Zuordnung für die Top 200 und alle verlinkten URLs.
- Nie auf 404- oder noindex-Seiten weiterleiten.
- Über echte Streichungen entscheiden — nächste passende Elternseite oder bewusst 410.
Testen Sie die Karte auf Staging, indem Sie jede alte URL crawlen. Eine nie ausgeführte Tabelle ist eine Hypothese, kein Plan.
Phase 3: Bewahren, was die Rankings getragen hat
- Title-Tags und Descriptions — nicht vom neuen CMS neu generieren lassen.
- Überschriftenstruktur — H1 wird beim Redesign häufig zum gestylten div.
- Fließtext und Wortzahl. Text für ein aufgeräumteres Design zu kürzen ist die häufigste selbstverschuldete Schädigung.
- Strukturierte Daten müssen neu implementiert werden.
- Interne Links direkt auf die neuen URLs aktualisieren.
- Canonicals und hreflang neu erzeugen und Gegenseitigkeit prüfen.
- Bilddateinamen und Alt-Texte tragen Bildsuchtraffic, der sonst still verschwindet.
Phase 4: Staging-Prüfungen, die Katastrophen verhindern
- Das noindex vom Staging geht live. Prüfen Sie robots.txt und das Meta-Robots-Tag der ersten drei Seiten binnen Minuten nach dem Go-live. Dieser eine Fehler hat mehr Traffic gekostet als alle Algorithmus-Updates zusammen.
- Staging-URLs in der Produktion. Absolute Links auf staging.beispiel.de gelangen in den Index — Produktionsbuild nach dem Staging-Hostnamen durchsuchen.
Phase 5: Ablaufplan für den Launchtag
- Früh in der Woche und früh am Tag starten — niemals freitags.
- Binnen 15 Minuten: robots.txt, Meta-Robots und Status 200 der Startseite prüfen.
- Binnen einer Stunde: gesamte alte URL-Liste crawlen und 301 auf lebende 200-Ziele bestätigen.
- Binnen zwei Stunden: neue XML-Sitemap einreichen, bei Domainwechsel die Adressänderung melden.
- Am selben Tag: Analytics prüfen, strukturierte Daten validieren, die zwanzig wichtigsten Seiten manuell kontrollieren.
- Am selben Tag: alte Sitemap einige Wochen erreichbar lassen.
Phase 6: Der erste Monat
- Tag 1–7: Abdeckungsbericht täglich prüfen, defekte Weiterleitungen sofort reparieren.
- Woche 2: indexierte URL-Zahlen alt gegen neu vergleichen.
- Woche 3–4: Klicks je Seite gegen die Basislinie vergleichen; Seiten mit über 30 % Verlust untersuchen.
- Dauerhaft: Weiterleitungen bestehen lassen.
Bei Trafficverlust in dieser Reihenfolge prüfen
- Indexierbarkeit — ist etwas fälschlich noindex oder blockiert?
- Weiterleitungen — alte URL-Liste erneut crawlen.
- Inhaltsparität — Wortzahlen und Überschriften vergleichen.
- Interne Verlinkung — wurde ein Bereich verwaist?
- Geschwindigkeit — Core Web Vitals gegen die Basislinie.
- Rendering — siehe JavaScript-SEO und Rendering-Audit, falls der Neubau clientseitig rendert.
Die 20-Punkte-Checkliste
- Vollständiger Crawl der alten Website archiviert.
- 16 Monate Search-Console-Daten exportiert.
- Analytics und Umsatz je Landingpage exportiert.
- Backlink-Liste exportiert, verlinkte URLs markiert.
- Ranking-Snapshot erstellt.
- Core-Web-Vitals-Basiswerte je Template erfasst.
- Eins-zu-eins-Weiterleitungskarte für jede indexierte URL.
- Top 200 und alle verlinkten URLs manuell zugeordnet.
- Weiterleitungsketten aufgelöst.
- Karte auf Staging per Crawl getestet.
- Titel, Descriptions und Überschriften bewahrt.
- Fließtext ohne stille Kürzung übernommen.
- Strukturierte Daten neu implementiert und validiert.
- Interne Links direkt auf neue URLs aktualisiert.
- Canonicals und hreflang neu erzeugt und gegenseitig.
- Staging-noindex und robots-Sperre beim Launch entfernt.
- Keine Staging-Hostnamen im Produktions-HTML.
- Neue Sitemap eingereicht, alte vorübergehend behalten.
- Adressänderung bei Domainwechsel gemeldet.
- Tägliche Kontrolle in Woche eins, wöchentlich im ersten Monat.
Domainwechsel folgt eigenen Regeln
Der Umzug auf eine neue Domain ist die einzige Migrationsart, bei der auch das am alten Hostnamen gewachsene Vertrauen verloren geht. Alles bisher Gesagte gilt weiterhin — plus fünf zusätzliche Schritte:
- Adressänderung in der Search Console melden, direkt nach dem Go-live und mit beiden verifizierten Properties. Das ist das Signal, dass der Umzug beabsichtigt ist.
- Die alte Domain jahrelang registriert halten, nicht monatelang. Die Weiterleitungen müssen weiterlaufen, und eine verfallene Domain übergibt Ihr Linkprofil an den nächsten Käufer.
- Die zwanzig wichtigsten verlinkenden Seiten kontaktieren und um Aktualisierung bitten. Direkte Links wiegen schwerer als weitergeleitete.
- Alles außerhalb der Website aktualisieren: Social-Profile, Google-Unternehmensprofil, Verzeichnisse, E-Mail-Signaturen, Rechnungen, Werbekonten und Analytics-Einstellungen.
- Drei bis sechs Monate bis zur vollständigen Stabilisierung einplanen — und das vor dem Launch kommunizieren, nicht während des Einbruchs.
Die Prozessseite, die niemand dokumentiert
Die meisten gescheiterten Migrationen sind keine technischen, sondern organisatorische Fehler. Vier Praktiken verhindern den Großteil:
- Eine verantwortliche Person benennen für SEO-Kontinuität, mit der Befugnis, den Launch zu verschieben. Kann niemand Nein sagen, geht die Weiterleitungskarte ungetestet live.
- Inhaltsänderungen einfrieren — zwei Wochen vor und nach dem Launch, damit Textänderungen nicht mit Migrationseffekten vermischt werden.
- Den Rollback-Plan zuerst schreiben. Wissen, wie DNS zurückgesetzt, der vorherige Build wiederhergestellt und alte Weiterleitungen reaktiviert werden — und wie lange das jeweils dauert.
- Die Weiterleitungskarte fachlich freigeben lassen, nicht nur technisch. Entwickler kennen URL-Muster; das Marketing weiß, welche Kampagnenseite noch bezahlten Traffic erhält.
Die teuersten Migrationsfehler entstehen in den letzten 48 Stunden, unter Druck, durch Personen, die nicht im Planungstermin saßen. Ein schriftlicher Ablaufplan ist die günstigste verfügbare Versicherung.
Mehrsprachige Websites migrieren
Internationale Websites verdoppeln die Fehlerfläche. Zusätzlich zur Standard-Checkliste: prüfen, dass hreflang für die neue Struktur neu erzeugt wird und in beide Richtungen gegenseitig bleibt, dass jede Sprachversion auf dieselbe Sprachversion weiterleitet statt auf eine englische Standardseite zu fallen, und dass Sprachverzeichnisse oder Subdomains ihre bisherige Struktur behalten, sofern deren Änderung nicht ausdrückliches Projektziel ist.
Der häufigste Fehler ist subtil: Weiterleitungen, die alle lokalisierten Versionen auf eine Standardseite zusammenführen. Der Traffic aus jedem Nicht-Hauptmarkt bricht gleichzeitig ein, und weil die Summe wie ein allgemeiner Rückgang aussieht, erkennt wochenlang niemand das Muster. Segmentieren Sie das Monitoring ab Tag eins nach Sprache.
Was Sie nach dem Launch wöchentlich messen sollten
Vier Zahlen genügen, um zu wissen, ob die Migration trägt: indexierte URLs im Vergleich zu vorher, Anteil alter URLs, die weiterhin mit 301 auf eine lebende Seite antworten, organische Klicks je Woche gegen denselben Zeitraum vor dem Launch, und die Zahl neuer 404 im Abdeckungsbericht. Bewegen sich nach vier Wochen alle vier in die richtige Richtung, war die Migration erfolgreich — dann reicht monatliche Kontrolle.
Bewahren Sie diese Zahlen auf. Beim nächsten Relaunch ist diese Dokumentation das stärkste Argument dafür, die Vorarbeit sauber zu machen.
Zeitplan: acht Wochen davor bis vier Wochen danach
Migrationen scheitern selten daran, dass niemand weiß, was zu tun ist. Sie scheitern daran, dass die Dinge in falscher Reihenfolge und zu spät geschehen. Dieser Plan funktioniert für eine mittelgroße Website.
| Zeitpunkt | Aufgabe |
|---|---|
| −8 Wochen | Basiswerte erfassen: Crawl, Search Console, Analytics, Backlinks |
| −6 Wochen | Entscheidung zur URL-Struktur, erste Fassung der Weiterleitungskarte |
| −4 Wochen | Inhaltsübernahme und Metadatenprüfung je Template |
| −2 Wochen | Karte gegen Staging ausführen, Fehler beheben, Content-Freeze beginnt |
| −3 Tage | Finale Checkliste, Rollback-Plan, Verantwortlichkeiten geklärt |
| Launch | Kontrollen nach Ablaufplan bei 15 Minuten, 1 Stunde und 2 Stunden |
| +1 Woche | Tägliche Kontrolle von Abdeckung und Weiterleitungen |
| +4 Wochen | Seitengenauer Vergleich mit den Basiswerten, Content-Freeze endet |
Passt der Zeitplan nicht: nicht alles proportional zusammenstauchen, sondern Umfang streichen. Ein Design-Refresh ohne URL-Änderungen lässt sich unter Zeitdruck durchführen — ein Wechsel der URL-Struktur nicht.
Vorher und nachher auditieren — gleiches Tool, gleiche Einstellungen
Das wertvollste Artefakt eines Relaunches sind zwei vergleichbare Audits: eines eine Woche vor dem Go-live, eines am Tag danach. Führen Sie beide mit identischen Einstellungen aus, damit Unterschiede echte Unterschiede sind.
Starten Sie ein kostenloses Audit mit WebSEO Auditor, sichern Sie heute Ihre Basislinie und wiederholen Sie es am Launchtag — so finden Sie Probleme in Stunden statt in Wochen.