Relaunch und Migration
Ein SEO-Relaunch überträgt Seitenaufgaben, nicht bloss URLs
Eine Weiterleitung kann Signale nur zu einer sinnvollen Nachfolgerin führen. Deshalb werden wertvolle Seiten, Inhalte, Links und interne Beziehungen vor dem Bau entschieden, nicht am Abend vor dem Go-live.
Risikomodell
Designmigration und Suchmigration sind dasselbe Projekt
Ein Relaunch verändert selten nur die Oberfläche. Navigation, URL-Struktur, Templates, interne Links, Inhalte, Tracking und Rendering können sich gleichzeitig verschieben. Wird SEO erst kurz vor dem Start geprüft, sind zentrale Entscheidungen oft bereits teuer oder unmöglich zu ändern.
Ein früher SEO-Audit kann die Ausgangslage und die wichtigsten Risiken festhalten. Die eigentliche Relaunch-Arbeit muss diese Evidenz anschliessend in Architektur, Tickets, Tests und Startkriterien übersetzen.
Änderungskontrolle
Je mehr gleichzeitig wechselt, desto schwieriger wird jeder Verlust zu erklären
Ein Domainwechsel, ein neues CMS, ein neues Design, andere Navigation und vollständig überarbeitete Inhalte können jeweils organische Resultate verändern. Werden sie in einem Release kombiniert, fehlt nach einem Rückgang der brauchbare Vergleich. Die Migration ist dann zeitlich verdächtig, aber die konkrete Ursache bleibt offen.
Trennen Sie grosse Änderungen, wenn das Projekt es erlaubt. Muss alles gleichzeitig veröffentlicht werden, sichern Sie wenigstens die Kontrollpunkte: alte Rankings und Einstiegsseiten, vollständige URL- und Linkinventare, gerenderte Vorlagen, Metadaten, interne Linkpfade, strukturierte Daten, Performance und wichtige Geschäftssignale. Ohne diese Ausgangslage kann das Team nachher nur vermuten, was verloren ging.
Projektphasen
Jede Phase braucht ein prüfbares Ergebnis
| Phase | Arbeitsstand | Abnahmefrage |
|---|---|---|
| Vor der Konzeption | Bestehende URLs, Nachfrage, Leistung, Links und Seitentypen erfassen | Welche organischen Werte müssen erhalten oder bewusst aufgegeben werden? |
| Während des Baus | Zielarchitektur, Templates, Rendering, Metadaten und interne Links prüfen | Entspricht die Vorschau der beschlossenen Seiten- und URL-Logik? |
| Vor dem Start | Weiterleitungen, Canonicals, Robots, Sitemaps, Tracking und Abnahme testen | Ist jede alte URL entschieden und jede kritische Funktion geprüft? |
| Nach dem Start | Live-Ausgabe, Crawling, Indexierung, Fehler und Geschäftssignale beobachten | Welche Abweichung verlangt Korrektur und wer darf sie ausrollen? |
URL-Übergang
Von der Bestandsseite zur echten Nachfolgerin
Die Zuordnung beginnt mit einem vollständigen Inventar bekannter URLs. Dazu gehören indexierte Seiten, organische Einstiege, verlinkte URLs, PDFs und weitere Assets sowie Pfade aus Analytics, Search Console, Sitemaps und Crawls. Jede relevante URL erhält eine Entscheidung: erhalten, zusammenführen, ersetzen oder ohne Nachfolger entfernen.
Erst danach entsteht die Weiterleitung. Sie sollte direkt zum endgültigen Ziel führen, ohne Ketten und ohne zwischenzeitliche Platzhalter. Neue Zielseiten müssen veröffentlicht und intern verlinkt sein, bevor die alten URLs umgestellt werden.
Nicht jede alte URL braucht eine Weiterleitung. Wenn mehrere Seiten wirklich in einer vollständigen neuen Seite aufgehen, dürfen sie dasselbe Ziel erhalten. Gibt es keinen sachlich passenden Ersatz, ist ein echter 404 oder 410 ehrlicher als eine Umleitung zur Startseite. Pauschale Startseiten-Redirects können von Google als Soft 404 behandelt werden und helfen auch dem Besucher nicht weiter.
Technische Abnahme im realen System
Vorschauprüfungen sollten Statuscodes, Canonicals, Robots-Regeln, Sitemaps, interne Links, Rendering, strukturierte Daten und zentrale Performance-Muster abdecken. Diese Bereiche gehören zur technischen SEO-Verantwortung. Nach dem Start muss dieselbe Prüfung auf der tatsächlich veröffentlichten Website wiederholt werden.
Nach dem Start
Der Go-live beginnt die Beobachtung, er beendet den Relaunch nicht
Direkt nach der Veröffentlichung werden zentrale alte und neue URLs im Browser und per HTTP geprüft: Weiterleitungsziel, Statuscode, Canonical, Robots-Anweisung, sichtbarer Inhalt, interne Links, Tracking und Formulare. Danach folgen grössere Crawls sowie Search Console für Sitemaps, Indexierung, neue Fehler und Suchleistung. Bei einem Domainwechsel müssen beide Properties beobachtet werden.
Schwankungen während der erneuten Verarbeitung sind möglich. Das ist kein Grund, jeden Tageswert zu erklären. Alarmgrenzen sollten vorab feststehen: unerwartete 404 auf wertvollen URLs, Redirect-Schleifen, entfernte Canonicals, blockierte Templates, stark einbrechende Einstiegsseiten oder Geschäftsvorgänge, die nicht mehr gemessen werden. Für jeden dieser Fälle braucht es eine Person, die eine Korrektur priorisieren und veröffentlichen darf.
Wann die Migration abgeschlossen ist
Nicht am Tag, an dem das Projektteam die neue Website feiert. Abgeschlossen ist die Übertragung, wenn die bekannten alten URLs ihren beschlossenen Zustand liefern, neue Seiten intern und extern richtig referenziert werden, Suchmaschinen die neue Eigentümerschaft verarbeitet haben und die verbliebenen Abweichungen verstanden sind. Bei grösseren Websites dauert dieser Übergang länger als ein einzelner Reporting-Zyklus.
Schweizer Sprachen
Sprachversionen erhöhen die Zahl der Abhängigkeiten
Bei deutsch-, französisch- und italienischsprachigen Bereichen reicht eine zeilenweise URL-Zuordnung nicht. Sprach- und Marktstruktur, Canonicals, hreflang, Navigation und redaktionelle Verantwortung müssen gemeinsam migriert werden. Der Leitfaden zu mehrsprachiger SEO in der Schweiz hilft, diese Eigentümerschaft vor dem Umbau festzulegen.
Verantwortung vor dem Projektstart klären
- Wer genehmigt neue Architektur und URL-Zuordnung?
- Wer erstellt Weiterleitungen und wer prüft sie im Live-System?
- Wer verantwortet Inhalte, Übersetzungen und Metadaten je Sprache?
- Welche Startkriterien können einen fehlerhaften Go-live stoppen?
- Wer beobachtet die ersten Wochen und darf Korrekturen priorisieren?