Website-Relaunch ohne SEO-Blindflug: Checkliste vor und nach dem Launch

Bei einem Website-Relaunch gehen Rankings selten wegen des neuen Designs verloren. Kritisch werden unkontrollierte Änderungen an URLs, Inhalten, internen Links, technischen Signalen und Messung. Eine gute Relaunch-Planung behandelt SEO deshalb nicht als Endkontrolle, sondern als eigene Arbeitsspur vom Inventar bis zur Überwachung nach dem Start.

Zuerst klären: Was ändert sich tatsächlich?

„Relaunch“ kann einen visuellen Umbau im bestehenden CMS, einen Wechsel des Systems, eine neue Informationsarchitektur, eine Domainmigration oder mehrere dieser Änderungen gleichzeitig bedeuten. Das Risiko steigt, wenn viele Ebenen zur selben Zeit wechseln. Halten Sie deshalb vor Projektbeginn schriftlich fest:

• Bleiben Domain, Protokoll und URL-Struktur unverändert?
• Welche Inhalte werden übernommen, zusammengeführt, neu geschrieben oder entfernt?
• Ändern sich Navigation, interne Verlinkung oder Sprachverzeichnisse?
• Werden Tracking, Consent-Lösung, Formulare und Schnittstellen neu gebaut?
• Gibt es einen klaren Rückfallplan, falls der Start technisch scheitert?

Diese Veränderungsmatrix entscheidet, welche Prüfungen nötig sind. Ein reines visuelles Update braucht keine künstliche URL-Migration. Ein CMS-Wechsel kann dagegen selbst bei gleichbleibender Optik fast jedes technische Signal berühren.

Phase 1: Den Bestand sichern, bevor etwas verschwindet

Die aktuelle Website ist die einzige verlässliche Referenz für das, was vor dem Relaunch erreichbar war. Erstellen Sie deshalb einen vollständigen Crawl und ergänzen Sie ihn um Daten aus XML-Sitemaps, Analytics, Search Console, dem CMS und – falls vorhanden – Backlink-Daten. Kein einzelner Export enthält alle relevanten URLs.

Die zentrale URL-Liste sollte mindestens folgende Spalten enthalten:

• alte URL und Seitentyp;
• Statuscode, Indexierbarkeit und Canonical;
• organische Klicks oder Sitzungen im gewählten Vergleichszeitraum;
• relevante Conversions und externe Links, soweit verfügbar;
• Entscheidung: behalten, verbessern, zusammenführen, umleiten oder entfernen;
• neue Ziel-URL;
• verantwortliche Person und Freigabestatus.

Speichern Sie außerdem robots.txt, XML-Sitemaps, Weiterleitungsregeln, Analytics- und Tag-Manager-Konfiguration sowie eine Auswahl wichtiger Seitendarstellungen. Diese Sicherung ist nicht nur für SEO nützlich: Sie erleichtert die Fehlersuche, wenn sich nach dem Start mehrere Systeme gleichzeitig anders verhalten.

Phase 2: Inhalte und URLs einzeln entscheiden

Die Redirect-Liste sollte aus einer Inhaltsentscheidung entstehen, nicht umgekehrt. Für jede alte URL wird zuerst festgelegt, ob der Nutzerbedarf weiterhin besteht. Danach folgt das passende Ziel.

Behalten

Eine funktionierende, sichtbare und weiterhin relevante Seite sollte nicht allein wegen eines neuen Designs eine neue Adresse bekommen. Gleichbleibende URLs reduzieren Migrationsrisiko und vermeiden unnötige Weiterleitungen.

Zusammenführen

Wenn mehrere Seiten denselben Bedarf abdecken, kann eine konsolidierte Zielseite sinnvoll sein. Dabei müssen die wertvollen Inhalte tatsächlich übernommen werden. Eine Weiterleitung auf eine nur oberflächlich ähnliche Seite löst das inhaltliche Problem nicht.

Entfernen

Für Inhalte ohne Ersatz braucht es eine bewusste Fehlerantwort. Die Startseite ist selten ein relevanter Ersatz. Prüfen Sie vor dem Entfernen, ob interne Links, externe Links, Kampagnen oder Support-Dokumente noch auf die URL verweisen.

Am Ende muss jede alte URL genau einen definierten Zustand haben. Leere Felder in der Zuordnungsliste sind ein Launch-Risiko.

Phase 3: Die neue Informationsarchitektur auf Staging testen

Eine Staging-Umgebung sollte vor öffentlicher Indexierung und unbefugtem Zugriff geschützt sein. Innerhalb des Projektteams muss sie zugleich vollständig crawlbar sein. So lassen sich Templates, Navigation und Inhalte prüfen, ohne die Live-Website zu beeinflussen.

Testen Sie nicht nur, ob Seiten „da“ sind. Prüfen Sie, ob wichtige Seitentypen von der Navigation und von passenden Inhaltsseiten aus erreichbar sind. Achten Sie auf Brotkrumen, Pagination, Facetten, Sprachwechsel, Footer-Links und Module für verwandte Inhalte. Eine neue visuelle Navigation kann intern deutlich weniger Links erzeugen als die alte.

Vergleichen Sie für jedes Template:

• Title, Meta Description und H1;
• Hauptinhalt, Bilder und Alt-Texte;
• Canonical, Robots-Anweisungen und Sprachverweise;
• strukturierte Daten, sofern sie fachlich und technisch passen;
• interne Links und Linkziele;
• Formulare, Downloads und weitere zentrale Interaktionen.

Phase 4: Weiterleitungen als testbare Zuordnung bauen

Eine Weiterleitungsdatei ist kein Sammelplatz für reguläre Ausdrücke, die „ungefähr passen“. Jede alte URL sollte direkt auf die fachlich nächste neue URL führen. Vermeiden Sie Ketten, in denen eine alte Adresse zunächst auf eine Zwischenadresse und erst dann auf das endgültige Ziel umleitet.

Für große Musterregeln sind Stichproben nicht genug. Testen Sie positive und negative Fälle: Welche URLs sollen erfasst werden, und welche dürfen keinesfalls umgeleitet werden? Dokumentieren Sie auch Parameter, Groß- und Kleinschreibung, Slash-Varianten sowie HTTP- und Host-Versionen.

Die Zuordnungsliste eignet sich als automatisierter Abnahmetest. Jede alte URL muss den erwarteten Status und das erwartete Endziel liefern. Gleichzeitig sollte die neue Website intern direkt auf die neuen URLs verlinken, damit Besucher und Bots nicht ständig durch Redirects geschickt werden.

Phase 5: Messung und Consent vor dem Launch validieren

Ein Relaunch kann technisch erfolgreich aussehen und trotzdem die Entscheidungsgrundlage zerstören. Legen Sie daher vorab fest, welche Ereignisse und Conversions erhalten bleiben müssen. Testen Sie Formulare, Telefonnummern, Käufe, Terminbuchungen, Downloads und andere geschäftlich relevante Aktionen in der vorgesehenen Consent-Konfiguration.

Prüfen Sie:

• Tags nur in den vorgesehenen Zuständen auslösen;
• Ereignisnamen, Werte, Währungen und IDs korrekt übergeben werden;
• Dankeseiten oder Events bei erneuter Ansicht doppelt zählen;
• Verweise zwischen Domains oder Subdomains erhalten bleiben;
• interne Zugriffe und Testbestellungen erkennbar sind;
• Dashboards und Kampagnen weiterhin dieselben Definitionen verwenden.

Datenschutzrechtliche Anforderungen hängen von Setup und Einsatz ab. Die technische Prüfung ersetzt keine rechtliche Bewertung.

Die letzten sieben Tage vor dem Start

In der Schlussphase sollte der Änderungsumfang sinken. Neue Funktionen kurz vor dem Termin erhöhen die Zahl unbekannter Abhängigkeiten. Arbeiten Sie mit einer Launch-Checkliste, deren Punkte namentlich verantwortet und abgezeichnet werden.

Zu den kritischen Freigaben gehören:

• finaler Staging-Crawl ohne unaufgelöste Blocker;
• freigegebene URL- und Redirect-Zuordnung;
• korrekte Canonicals, Robots-Regeln und Sprachsignale;
• bereinigte XML-Sitemaps mit den endgültigen URLs;
• Performance- und Rendering-Tests auf repräsentativen Geräten;
• vollständige Funktions- und Conversion-Tests;
• Backup, Rollback-Kriterien und erreichbares Launch-Team.

Ein Freeze bedeutet nicht, dass niemand mehr arbeiten darf. Er bedeutet, dass nur noch Änderungen mit bekannter Wirkung und klarer Freigabe in den Launch gelangen.

Launch-Tag: Reihenfolge statt Hektik

Nach der technischen Veröffentlichung muss die Website zunächst für Nutzer und Suchmaschinen erreichbar sein. Prüfen Sie sofort Startseite, wichtigste Seitentypen, robots.txt, Sitemaps, Canonicals und eine Auswahl alter URLs. Entfernen Sie Staging-Sperren nur auf der Produktionsumgebung; der Testbereich bleibt geschützt.

Führen Sie anschließend den vorbereiteten Redirect-Test und einen fokussierten Crawl durch. Suchen Sie besonders nach 5xx-Antworten, flächigem Noindex, falschen Canonicals, internen Links auf alte URLs und Assets, die nur auf Staging erreichbar sind. Erst wenn die Website stabil ist, werden neue Sitemaps in den Suchmaschinen-Tools eingereicht.

Bei einem Domainwechsel kommen die dafür vorgesehenen Eigentums- und Adresswechselprozesse hinzu. Die alte Domain und ihre Weiterleitungen müssen weiterhin betrieben werden; sie sind nach dem Launch kein überflüssiges Relikt.

Die ersten 30 Tage: Nach Mustern suchen

Ein einzelner Tageswert ist nach einem Relaunch kaum belastbar. Vergleichen Sie stattdessen Seitentypen, Verzeichnisse und Query-Gruppen mit den vorher festgelegten Referenzwerten. Beobachten Sie Serverfehler, Crawling, Indexierung, organische Landingpages und Conversions.

Warnsignale sind beispielsweise:

• ein ganzer Seitentyp verliert Klicks, während andere stabil bleiben;
• alte URLs werden weiter intern verlinkt oder häufig gecrawlt;
• Google wählt andere Canonicals als vorgesehen;
• neue Seiten sind erreichbar, fehlen aber in Navigation oder Sitemap;
• Conversions sinken nur auf bestimmten Geräten oder Formularen;
• 404- und 5xx-Muster wachsen statt zu schrumpfen.

Solche Muster führen zu konkreten Hypothesen. Ein pauschaler Rückgang kann dagegen aus Saisonalität, Nachfrage, Tracking, Rankings oder mehreren Faktoren zugleich entstehen.

Wer besitzt welche Entscheidung?

Viele Relaunch-Probleme sind keine Wissens-, sondern Übergabeprobleme. SEO definiert Anforderungen, Entwicklung implementiert, Content überträgt Seiten, Analytics prüft Messung – und niemand besitzt das Endergebnis. Legen Sie deshalb für jede kritische Arbeit einen Verantwortlichen und eine prüfende Person fest.

Für ein Projekt, das Design, Entwicklung und Migration gemeinsam betrifft, sollte die Website-Entwicklung früh mit SEO und Messung verzahnt werden. Je später URL-Logik oder Templates korrigiert werden, desto eher kollidieren sie mit bereits freigegebenem Design und Content.

Relaunch-Check in fünf Fragen

1. Ist jede bisher relevante URL erfasst und entschieden?
2. Führt jede geänderte URL ohne Kette zu einem fachlich passenden Ziel?
3. Sind Inhalte, interne Links und Indexierungssignale auf Staging geprüft?
4. Funktionieren Conversions und Consent-Zustände vor der Freigabe?
5. Gibt es für Launch und Nachbeobachtung Eigentümer, Tests und Eskalationswege?

Wenn eine Antwort «noch nicht» lautet, ist das kein kosmetischer Restpunkt. Es ist ein klar benennbares Risiko, das vor dem Start entschieden werden sollte.