Vor dem Bau: den Bestand vollständig erfassen.
Das Inventar enthält erreichbare URLs, Statuscodes, Canonicals, interne Links, wichtige Einstiege und bekannte externe Verweise. Verfügbare Suchdaten helfen, priorisierte Seiten zu erkennen; sie entscheiden aber nicht allein über Erhalt oder Zusammenführung.
Für jede alte URL wird eine begründete Zielentscheidung getroffen: unverändert erhalten, inhaltlich überführen, mit einer stärkeren Seite zusammenführen oder bewusst entfernen.
Weiterleitungen sind eine Inhaltsentscheidung.
Eine permanente Weiterleitung führt eine alte Adresse zur passendsten neuen Entsprechung. Alle entfernten Seiten pauschal zur Startseite umzuleiten verschleiert die Aufgabe und hilft Menschen selten weiter.
Zielseiten müssen erreichbar und inhaltlich passend sein. Redirect-Ketten, Schleifen und widersprüchliche Canonicals werden vor dem Wechsel automatisiert geprüft.
Interne Signale auf die neue Architektur ausrichten.
Navigation, redaktionelle Links, Canonicals, Sitemap und strukturierte Daten nennen die endgültigen Ziel-URLs. Alte Links nur über Redirects funktionieren zu lassen erzeugt unnötige Umwege und erschwert die Pflege.
Der neue Build enthält ausschließlich beabsichtigte öffentliche Seiten. Entwürfe und Vorschauen bleiben physisch getrennt, statt nur in der Navigation versteckt zu werden.
Staging und Produktion bewusst getrennt halten.
Eine Vorschau bleibt zugriffsgeschützt und noindex. noindex allein schützt keine vertraulichen Inhalte. Der Produktionskandidat enthält dagegen nur freigegebene Seiten, öffentliche URLs und die dafür vorgesehenen Indexierungsregeln; Staging-Zugangsdaten und Reviewhinweise gehören nicht hinein.
Vor dem Umschalten werden Zielsystem, Konfiguration und unmittelbar vorher aktiver Stand festgehalten. Ein Rollback stellt genau diesen Stand wieder her und darf nicht versehentlich eine ältere Kontakt- oder Inhaltsvariante aktivieren.
Vor dem Wechsel eine reale Abnahme durchführen.
Geprüft werden Kernrouten, lange und kurze Inhalte, Statuscodes, Formulare, mobile Darstellung, Tastatur, No-JS, reduzierte Bewegung, Bilder und Performance mit finalen Medien. Technische Testwerte werden nicht mit menschlichem Verständnis gleichgesetzt.
Backup, Wiederherstellung und Rollback sind vor dem Cutover konkret nachzuweisen. Eine Versionsnummer ersetzt weder Hostingkenntnis noch Betreiberfreigabe.
Nach dem Wechsel beobachten und gezielt korrigieren.
Direkt nach dem Start werden wichtige URLs, Redirects, robots-Regeln, noindex, Sitemap, Kontaktannahme und Serverantworten geprüft. Danach folgen verfügbare Crawling-, Indexierungs- und Nutzungsdaten über einen vereinbarten Zeitraum.
Kurzfristige Schwankungen sind kein Grund für hektische Massenänderungen. Befund, Ursache, Korrektur und erneute Prüfung bleiben dokumentiert.
Arbeitsmittel
Relaunch-Abnahme vor dem Cutover
- Alte URL-Liste und Prioritäten gesichert
- Zielmatrix ohne pauschale Startseiten-Redirects
- Redirects ohne Ketten und Schleifen getestet
- Canonicals, interne Links und Sitemap kohärent
- Entwürfe physisch aus dem öffentlichen Build ausgeschlossen
- Staging geschützt und noindex; Produktion ohne Staging-Zugangsdaten vorbereitet
- Kontakt, No-JS, Tastatur und mobile Kernwege geprüft
- Backup, Wiederherstellung und Rollback nachgewiesen
- Nachprüfplan mit Verantwortlichkeit und Datenquellen festgelegt