Ein Website-Relaunch ist aus SEO-Sicht immer ein Eingriff in ein bestehendes System. URLs ändern sich, Inhalte werden zusammengelegt, Technik wird ersetzt, interne Links verschieben sich, Tracking wird neu eingebunden und Suchmaschinen müssen die neue Struktur erst wieder einordnen.
Das heißt nicht, dass ein Relaunch automatisch Sichtbarkeit kostet. Es heißt aber: Wer ohne Inventar, Redirect-Plan, Canonical-Prüfung, Sitemap, Analytics und Monitoring live geht, verlässt sich auf Glück.
Bei unserem eigenen Website-Relaunch war genau das die praktische Perspektive: nicht "SEO am Ende", sondern technische Klarheit vor, während und nach dem Go-live. Die folgende Checkliste ist deshalb bewusst operativ. Sie hilft Teams, einen Relaunch so zu planen, dass bestehende Signale erhalten bleiben und neue Seiten sauber indexierbar sind.
1. Content- und URL-Inventar erstellen
Vor dem Design, vor der neuen Navigation und vor dem CMS-Umzug braucht es eine Bestandsaufnahme. Jede relevante bestehende URL sollte bekannt sein, bevor entschieden wird, was bleibt, was umzieht und was entfernt wird.
In ein Relaunch-Inventar gehören mindestens:
- aktuelle URLs aus Crawl, Sitemap, Analytics und Search Console
- Seitentitel, Meta-Descriptions und H1-Struktur
- organische Einstiegsseiten mit Traffic und Conversions
- Seiten mit Backlinks oder lokaler Sichtbarkeit
- Statuscodes, Canonicals und Weiterleitungen
- Inhalte, die zusammengelegt, aktualisiert oder gelöscht werden
Wichtig ist: Nicht nur die Seiten erfassen, die im Menü sichtbar sind. Viele SEO-relevante URLs liegen tiefer: Blogartikel, alte Landingpages, Case Studies, PDF-Dateien, Kampagnen-URLs oder lokalisierte Varianten.
2. Redirect-Mapping auf URL-Ebene planen
Weiterleitungen sind der kritischste Teil vieler Relaunches. Wenn alte URLs nach dem Launch auf 404 laufen oder pauschal auf die Startseite zeigen, verlieren Nutzer und Suchmaschinen Kontext.
Für jede alte URL sollte es eine klare Entscheidung geben:
- 1:1-Redirect: Die Seite hat eine direkte neue Entsprechung.
- Themen-Redirect: Die alte Seite geht in einer neuen, inhaltlich passenden Seite auf.
- 410 oder 404: Der Inhalt ist bewusst entfernt und hat keine sinnvolle Alternative.
- Keine Änderung: Die URL bleibt bestehen und wird technisch unverändert ausgeliefert.
Für dauerhafte URL-Änderungen sind serverseitige 301- oder 308-Weiterleitungen in der Regel die richtige Wahl. Google beschreibt permanente Redirects als starkes Signal dafür, dass die Ziel-URL kanonisch werden soll. Redirects sollten außerdem direkt zum finalen Ziel führen, nicht über Ketten wie alt -> zwischen-url -> neu.
Ein sauberer Redirect-Plan ist keine Tabelle für die Ablage. Er muss vor dem Go-live getestet werden: alte Top-URLs, URLs mit Backlinks, alte Sitemap-URLs und typische Varianten mit oder ohne Slash, mit oder ohne www, HTTP und HTTPS.
3. Kanonische Domain und URL-Varianten festlegen
Ein Relaunch ist ein guter Moment, alle Domain-Varianten konsequent zu bereinigen. Eine Website sollte eindeutig beantworten:
- Wird
https://example.comoderhttps://www.example.comverwendet? - Leiten HTTP-Varianten sauber auf HTTPS weiter?
- Gibt es doppelte Inhalte durch Trailing Slashes, Groß-/Kleinschreibung oder Parameter?
- Verweisen Canonical-Tags auf die neue finale URL?
- Stimmen Canonicals, interne Links und Sitemap miteinander überein?
Canonical-Tags sind kein Ersatz für Redirects, wenn alte URLs dauerhaft ersetzt werden. Sie sind aber wichtig, um Duplikate und bevorzugte Varianten sauber zu signalisieren. Besonders bei mehrsprachigen Websites sollte zusätzlich geprüft werden, ob hreflang-Verweise, Canonicals und Sprachpfade zusammenpassen.
4. Sitemap und robots.txt aktualisieren
Die XML-Sitemap sollte nach dem Relaunch nur indexierbare, kanonische, erfolgreiche URLs enthalten. Weitergeleitete URLs, 404-Seiten, Noindex-Seiten und Staging-Pfade gehören nicht hinein.
Prüfe vor dem Launch:
- Ist die neue Sitemap erreichbar?
- Enthält sie die finalen HTTPS-URLs?
- Sind wichtige neue Seiten enthalten?
- Sind gelöschte und weitergeleitete URLs entfernt?
- Verweist
robots.txtauf die korrekte Sitemap? - Blockiert
robots.txtkeine wichtigen CSS-, JS- oder Bildressourcen?
Nach dem Go-live sollte die neue Sitemap in der Google Search Console eingereicht werden. Bei größeren URL-Änderungen kann es normal sein, dass Google alte Sitemap-URLs zunächst als weitergeleitet meldet. Entscheidend ist, dass die neue Struktur konsistent ist und gecrawlt werden kann.
5. Metadata, strukturierte Daten und interne Links prüfen
Ein Relaunch verändert oft Templates. Dadurch können SEO-Elemente verschwinden, doppelt ausgegeben werden oder plötzlich auf falsche Inhalte zeigen.
Vor dem Go-live sollten mindestens diese Punkte gecrawlt und manuell stichprobenartig geprüft werden:
- eindeutige Title Tags
- sinnvolle Meta-Descriptions
- genau eine klare H1 pro Seite
- korrekte Open-Graph- und Social-Media-Metadaten
- strukturierte Daten ohne Template-Fehler
- interne Links auf finale URLs statt auf alte Redirect-Ziele
- Bild-Alt-Texte für relevante Medien
- Indexierungsregeln wie
index,noindex,followundnofollow
Interne Links sind besonders wichtig. Eine Website sollte nach dem Relaunch nicht intern auf alte URLs zeigen und sich dann auf Redirects verlassen. Redirects sind für externe Altlasten da. Die neue Website selbst sollte ihre finale Struktur direkt verwenden.
6. Analytics und Conversion-Tracking sauber übernehmen
SEO-Verlust wird oft erst spät erkannt, wenn Tracking beim Relaunch beschädigt wurde. Deshalb gehört Analytics nicht in die Kategorie "nach dem Launch irgendwann prüfen".
Vor dem Go-live sollte klar sein:
- Welche Analytics-Properties bleiben bestehen?
- Welche Events, Conversions und Consent-Einstellungen werden übernommen?
- Werden Formulare, Klicks, Downloads und Buchungen weiter gemessen?
- Sind interne IPs, Staging-Domains oder Test-Traffic gefiltert?
- Funktionieren UTM-Parameter und Kampagnen-Zuordnung?
- Werden Cookie- und Datenschutzanforderungen eingehalten?
Wenn Tracking-Strukturen geändert werden, sollte die Änderung dokumentiert werden. Sonst ist später unklar, ob ein Rückgang im Reporting aus SEO, Technik, Consent-Verhalten oder Messlogik entstanden ist.
7. Google Search Console vorbereiten
Die Search Console ist beim Relaunch kein Reporting-Tool für später, sondern Teil der Vorbereitung.
Vor dem Launch:
- Property für die kanonische Domain prüfen
- Zugriff für verantwortliche Personen sicherstellen
- bestehende Leistungsdaten exportieren
- Indexierungs- und Seitenberichte ansehen
- alte Top-Seiten und Suchanfragen dokumentieren
- Sitemap-Status prüfen
Nach dem Launch:
- neue Sitemap einreichen
- wichtige URLs mit dem URL-Prüftool testen
- Indexierungsprobleme, 404-Fehler und Redirect-Fehler beobachten
- bei echter Domain-Migration das Change-of-Address-Tool prüfen
- Leistungsdaten gegen die Vorperiode vergleichen
Google weist bei Site Moves darauf hin, dass die Verarbeitung einige Wochen dauern kann. Größere Websites können länger brauchen. Ein Relaunch ist deshalb nicht nach dem Deployment abgeschlossen, sondern erst, wenn Crawling, Indexierung, Rankings und Conversions stabil sind.
8. Staging vor Indexierung schützen und trotzdem realistisch testen
Staging-Umgebungen sind eine häufige Fehlerquelle. Sie dürfen nicht in den Index gelangen, müssen aber realistisch genug sein, um SEO-Signale vor dem Launch zu prüfen.
Sinnvolle Schutzmaßnahmen sind:
- Passwortschutz oder IP-Beschränkung
noindexnur mit klarer Entfernung vor dem Go-live- keine öffentlichen Links auf Staging-URLs
- keine Staging-URLs in Sitemaps
- keine Canonicals von Produktion auf Staging
Kurz vor dem Launch braucht es eine klare Checkliste: Ist noindex entfernt? Sind Canonicals auf Produktion gesetzt? Ist die Sitemap produktiv? Sind Analytics-IDs korrekt? Funktionieren Redirects auf der echten Domain?
9. Post-Launch-Monitoring in den ersten Wochen
Die ersten Tage und Wochen nach dem Relaunch entscheiden, ob Probleme schnell korrigiert werden oder sich in der Suche festsetzen.
Direkt nach dem Go-live:
- alte Top-URLs auf korrekte Redirects testen
- neue Seiten auf 200-Status prüfen
- Sitemap einreichen
- robots.txt und Canonicals kontrollieren
- Core Templates in mobilen und Desktop-Ergebnissen prüfen
- Analytics-Echtzeitdaten und Conversions testen
In den folgenden Wochen:
- 404- und 5xx-Fehler täglich prüfen
- Redirect-Ketten und falsche Ziele korrigieren
- Search-Console-Abdeckung beobachten
- Ranking- und Klickdaten nicht nur täglich, sondern über Trends bewerten
- wichtige Seiten erneut crawlen
- interne Links nachziehen, wenn alte Ziele auftauchen
Kurzfristige Schwankungen sind bei URL-Änderungen möglich. Kritisch sind systematische Muster: viele alte URLs ohne Ziel, neue Seiten mit noindex, falsche Canonicals, blockierte Ressourcen, fehlende Templates oder ein Tracking-Bruch.
Kompakte Relaunch-Checkliste
- Vollständiges URL- und Content-Inventar erstellen
- Top-Seiten aus Analytics und Search Console markieren
- Redirect-Mapping für jede relevante alte URL anlegen
- 301/308-Redirects direkt und ohne Ketten testen
- kanonische Domain festlegen und Varianten weiterleiten
- Canonicals,
hreflang, interne Links und Sitemap konsistent setzen - Metadata, strukturierte Daten und Open Graph prüfen
- Staging vor Indexierung schützen
noindexund Test-Konfiguration vor Go-live entfernen- Analytics, Consent und Conversion-Tracking testen
- neue Sitemap in Search Console einreichen
- URL-Prüfung für wichtige Seiten durchführen
- 404, 5xx, Redirect-Fehler und Indexierung nach Launch überwachen
- Rankings, Klicks und Conversions über mehrere Wochen vergleichen
Quellen und weiterführende Links
- Google Search Central: Websiteverschiebungen und Migrationen
- Google Search Central: Weiterleitungen und die Google Suche
- Google Search Central: Kanonische URLs angeben
- Google Search Central: Sitemap erstellen und einreichen
- Google Search Console-Hilfe: Adressänderungstool
- Google Search Central: SEO Starter Guide
