Ein Website-Relaunch scheitert selten am neuen Design. Die größten Schäden entstehen durch vergessene URLs, falsche Canonicals, fehlende Messdaten und Inhalte, die beim Umzug ihren Suchkontext verlieren.
Die wichtigste Regel lautet deshalb: Ein Relaunch ist eine Migration, kein Gestaltungstermin. Wer Bestand, Zielstruktur und Erfolgskriterien vor dem ersten Layout dokumentiert, kann Risiken kontrollieren. Wer erst am Launch-Tag über Weiterleitungen spricht, arbeitet ohne Netz.
Vor dem Relaunch: Ziele, Benchmarks und Crawl sichern
Bevor sich eine URL, ein Text oder ein Template ändert, braucht ihr einen belastbaren Ausgangspunkt. Sonst lässt sich nach dem Go-live nicht unterscheiden, ob eine Abweichung neu ist oder bereits vorher bestand.
Sichert mindestens:
- vollständigen Crawl aller indexierbaren URLs;
- XML-Sitemaps, robots.txt und Canonical-Ziele;
- organische Klicks und Impressionen pro URL aus der Search Console;
- Rankings der geschäftlich wichtigsten Suchanfragen;
- Sitzungen, Conversions und Zielpfade aus Analytics;
- Ladezeiten und Core Web Vitals wichtiger Seitentypen;
- externe Links auf Seiten, PDFs und Bilder;
- aktuelle Formulare, Tracking-Ereignisse und Consent-Konfiguration;
- Screenshots zentraler Templates auf Desktop und Mobilgerät.
Die Benchmarks sollten nicht nur die Startseite abbilden. Produktseiten, Leistungsseiten, Blogartikel und Kampagnen-Landingpages haben unterschiedliche Aufgaben. Für jede Gruppe braucht ihr zwei bis fünf repräsentative URLs.
Definiert anschließend messbare Ziele: Welche Inhalte sollen leichter gefunden werden? Welche Nutzerwege werden kürzer? Welche Conversions müssen nach dem Relaunch unverändert funktionieren? „Moderner aussehen“ ist kein Abnahmekriterium.
Informationsarchitektur und URL-Mapping
Jede vorhandene URL bekommt vor dem Relaunch eine Entscheidung. Wir arbeiten dafür mit einem URL-Mapping:
| Alte URL | Aktuelle Aufgabe | Entscheidung | Neue URL | Redirect | Prüfung |
|---|---|---|---|---|---|
/alte-leistung/ |
kommerzielle Landingpage | migrieren | /neue-leistung/ |
301 | Inhalt und Intent passen |
/ratgeber-a/ |
informativer Beitrag | behalten | identisch | keiner | Template geändert |
/doppelter-text/ |
kannibalisiert Hauptseite | zusammenführen | /hauptseite/ |
301 | Signale konsolidieren |
/alte-aktion/ |
abgelaufen, ohne Ersatz | entfernen | – | 410 oder sinnvoller Hub | kein falsches Ziel |
Eine Weiterleitung ist dann nötig, wenn sich die URL ändert und ein passendes Ziel existiert. Sie ist kein Aufräumwerkzeug für beliebige 404-Fehler. Wer jede alte Seite auf die Startseite umleitet, löst das Nutzerproblem nicht und verwischt die thematische Zuordnung.
Google empfiehlt bei einer URL-Migration permanente serverseitige Weiterleitungen, direkte Ziele ohne Ketten und eine ausreichend lange Laufzeit. In der offiziellen Dokumentation zu Website-Umzügen mit URL-Änderungen wird mindestens ein Jahr genannt. In der Praxis lassen wir wichtige Redirects dauerhaft bestehen, solange alte Links und Lesezeichen noch genutzt werden.
Content-Migration und Onpage-Signale
Nicht jeder alte Absatz muss mit. Aber jeder relevante Suchintent braucht nach dem Relaunch weiterhin eine eindeutige Zielseite.
Prüft pro URL:
- Hauptfrage und Suchintention;
- Title, Description und H1;
- Überschriftenstruktur;
- interne Links und eingehende Linkziele;
- Medien, Downloads und Alt-Texte;
- strukturierte Daten;
- Autoren- und Aktualitätssignale;
- Inhalt, der nachweislich Klicks oder Anfragen erzeugt.
Ein häufiger Fehler ist die Kürzung aus Designgründen. Aus einer ausführlichen Leistungsseite werden drei Kacheln und ein Kontaktbutton. Visuell wirkt das aufgeräumt, inhaltlich fehlen plötzlich Entscheidungskriterien, Fachbegriffe und Belege. Gestaltung darf Inhalte priorisieren – nicht ihren Job abschaffen.
Ebenso gefährlich ist die ungeprüfte Komplettmigration. Veraltete, doppelte und schwache Texte ziehen dieselben Probleme in das neue System. Unser Vorgehen: behalten, überarbeiten, zusammenführen oder entfernen. Für jede Entscheidung steht ein Grund im Mapping.
Technik, Redirects, Canonicals und Tracking
Vor dem Launch werden die technischen Signale gegen die Zielstruktur geprüft:
- Jede neue URL liefert den erwarteten Statuscode.
- Redirects führen in einem Schritt zum finalen Ziel.
- Canonicals zeigen auf die tatsächlich indexierbare URL.
- Interne Links verwenden direkt die neue Adresse.
- XML-Sitemaps enthalten nur indexierbare Ziel-URLs.
- robots.txt blockiert keine benötigten Ressourcen oder Seiten.
- Noindex-Anweisungen aus dem Staging sind entfernt.
- HTTPS, Hostname und Weiterleitungen zwischen Domainvarianten sind eindeutig.
- Tracking misst dieselben geschäftlichen Ziele wie vor dem Relaunch.
- Consent und Tags funktionieren in allen Einwilligungszuständen.
Besonders kritisch sind widersprüchliche Kombinationen: Eine Seite steht in der Sitemap, trägt aber noindex. Ein Canonical zeigt auf die alte Domain. Die interne Navigation verlinkt über einen Redirect. Solche Signale machen die Migration unnötig langsam.
Wenn ihr bei Sperren unsicher seid, hilft unser Beitrag zur robots.txt. Für Links gilt außerdem: Google kann reguläre HTML-Links mit href zuverlässig crawlen; Details stehen in den offiziellen Empfehlungen für crawlbare Links.
Staging-Abnahme vor dem Go-live
Die Staging-Website bleibt vor Suchmaschinen geschützt, muss für das Projektteam aber vollständig testbar sein. Ein pauschales noindex genügt nicht als einzige Absicherung; eine Zugangsbeschränkung ist robuster. Vor dem Kopieren auf Produktion darf diese Sperre nicht versehentlich mitwandern.
Die Abnahme erfolgt nach Seitentyp, nicht nur nach Bildschirmgröße:
- Startseite und Navigation;
- zentrale Leistungs- und Produktseiten;
- Blog, Kategorien und Suche;
- Formulare inklusive Zustellung;
- Warenkorb, Checkout und Transaktionsmails;
- 404-Seite und Fehlerzustände;
- Cookie-Einwilligung und Tracking;
- Barrierearmut per Tastatur und Screenreader-Stichprobe;
- Performance auf einem realistischen Mobilgerät.
Zu jeder Prüfung gehören erwartetes Ergebnis, verantwortliche Person und Status. „Sieht gut aus“ ist keine dokumentierte Abnahme.
Launch-Tag: der 24-Stunden-Plan
Am Launch-Tag zählt Reihenfolge. Änderungen an DNS, Datenbank, Dateien und Caches dürfen nicht unkoordiniert nebeneinander laufen.
Vor der Umschaltung
- finales Backup von Dateien und Datenbank;
- Freeze für redaktionelle Änderungen und Bestellungen einplanen;
- Redirect-Datei und Rollback-Pfad bereithalten;
- Monitoring und Ansprechpartner aktivieren;
- DNS-Werte und Zertifikate prüfen.
Direkt nach der Umschaltung
- Homepage und wichtigste Seitentypen mit und ohne
wwwtesten; - Statuscodes, Canonicals, robots und Sitemap kontrollieren;
- Stichprobe alter URLs durch das Mapping schicken;
- Formulare, Anmeldung, Suche und Checkout real ausführen;
- Tracking-Ereignisse und Consent prüfen;
- Caches leeren und Logs beobachten.
Innerhalb von 24 Stunden
- neuen Crawl starten und gegen den Ausgangscrawl vergleichen;
- Sitemap in der Search Console prüfen oder neu einreichen;
- 404-, 5xx- und Redirect-Berichte auswerten;
- Team und Support mit bekannten Punkten versorgen;
- erste Abweichungen priorisieren, nicht hektisch alles gleichzeitig ändern.
Viele häufige Website-Fehler werden erst nach dem echten Go-live sichtbar. Deshalb endet die Abnahme nicht mit der Umschaltung.
Monitoring in den ersten 90 Tagen
Kurzfristige Schwankungen sind bei größeren Änderungen möglich. Entscheidend ist, ob Suchmaschinen die neue Struktur verstehen und wichtige URLs ihre Aufgabe wieder übernehmen.
Nach 24 bis 72 Stunden
- Crawling-Fehler und Serverlogs;
- Indexierbarkeit der wichtigsten Seiten;
- Redirects und 404-Häufungen;
- Conversions, Formulare und Checkout;
- auffällige Performance- oder JavaScript-Fehler.
Nach 30 Tagen
- Klicks und Impressionen pro URL-Gruppe;
- neue und ausgeschlossene URLs in der Search Console;
- Rankings der priorisierten Suchthemen;
- interne Wege zu Anfrage oder Kauf;
- Seiten mit unerwartetem Trafficverlust.
Nach 60 und 90 Tagen
- Entwicklung gegenüber der gesicherten Baseline;
- Kannibalisierung zwischen neuen Zielseiten;
- Qualität und Conversion der organischen Sitzungen;
- externe Links, die noch auf falsche Ziele führen;
- Backlog für Content, Technik und interne Verlinkung.
Ein Status wie „Gefunden – zurzeit nicht indexiert“ ist dabei ein Symptom, keine Diagnose. Erst im Zusammenspiel aus Crawl, internen Links, Inhalt und Serverdaten wird die Ursache erkennbar.
Kompakte Relaunch-Checkliste
- Ziele, Baseline und wichtigste URL-Gruppen dokumentiert
- vollständiger Crawl und Search-Console-Daten gesichert
- jede alte URL im Mapping entschieden
- Redirects direkt, dauerhaft und thematisch passend
- Inhalte nach Aufgabe statt nach Layout migriert
- Titles, H1, Canonicals und interne Links geprüft
- Sitemaps, robots.txt und Noindex-Regeln geprüft
- Formulare, Tracking, Consent und Zustellung getestet
- Staging-Abnahme nach Seitentyp abgeschlossen
- Backup, Freeze und Rollback für den Launch vorhanden
- 24-Stunden- und 90-Tage-Monitoring terminiert
- Verantwortliche für Befunde und Korrekturen benannt
Ein Relaunch ohne Rankingverlust lässt sich nicht garantieren. Die Risiken lassen sich aber sehr deutlich reduzieren, wenn SEO, Inhalte und Technik gemeinsam geplant werden. Genau so bauen wir WordPress-Websites und Relaunches: erst die bestehende Aufgabe verstehen, dann die neue Struktur umsetzen und nach dem Launch weiter messen.
