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: Wer ohne Inventar, Redirect-Plan, Canonical-Prüfung, Sitemap und Monitoring live geht, verlässt sich auf Glück.
Die gute Nachricht steckt in Googles eigener Dokumentation zu Websiteverschiebungen: Migrationen sind ein etablierter, kontrollierbarer Vorgang. Die folgende Checkliste ist deshalb bewusst operativ und an den aktuellen Vorgaben von Google Search Central (Stand Juni 2026) ausgerichtet.
Erst das Inventar, dann das Redesign
Bevor ein einziges Template gebaut wird, muss bekannt sein, was an Bestand existiert und welche Signale es trägt. Jede relevante bestehende URL sollte erfasst sein, bevor entschieden wird, was bleibt, was umzieht und was entfällt. In ein Relaunch-Inventar gehören mindestens die aktuellen URLs aus Crawl, Sitemap, Analytics und Search Console, die Title- und H1-Struktur, organische Einstiegsseiten mit Traffic und Conversions, Seiten mit Backlinks oder lokaler Sichtbarkeit sowie die vorhandenen Statuscodes, Canonicals und Weiterleitungen.
Der häufigste Fehler ist, nur die Seiten zu erfassen, die im Menü sichtbar sind. Viele SEO-relevante URLs liegen tiefer: alte Landingpages, Blogartikel, Case Studies, PDF-Dateien, Kampagnen-URLs oder lokalisierte Varianten. Genau diese Seiten tragen oft Backlinks – und genau sie fallen beim Redesign am schnellsten unter den Tisch. Der Relaunch selbst folgt danach einem klaren Ablauf, der erst mit stabilen Rankings endet, nicht mit dem Deployment.
Redirects sind der kritischste Hebel
Weiterleitungen entscheiden, ob aufgebaute Signale erhalten bleiben oder verloren gehen. Für jede alte URL braucht es eine klare Entscheidung: ein 1:1-Redirect auf die direkte Entsprechung, ein Themen-Redirect auf eine inhaltlich passende neue Seite, ein bewusstes 410/404 für endgültig entfernte Inhalte oder „keine Änderung", wenn die URL bestehen bleibt. Pauschale Weiterleitungen auf die Startseite sind der teuerste Fehler – Nutzer und Suchmaschinen verlieren den Kontext.
Für dauerhafte Änderungen sind serverseitige 301- oder 308-Weiterleitungen die richtige Wahl. Laut Google Search Central nutzt die Indexierung permanente Redirects als Signal, dass die Ziel-URL kanonisch werden soll – temporäre Codes (302/307) tun das nicht. Redirects sollten außerdem direkt zum finalen Ziel führen, nicht über Ketten wie alt → zwischen-url → neu.
| Status | Bedeutung | SEO-Signal | Einsatz beim Relaunch |
|---|---|---|---|
| 301 / 308 | dauerhaft verschoben | Ziel wird kanonisch | URL dauerhaft ersetzt |
| 302 / 307 | temporär | keine Konsolidierung | nur kurzfristige Umleitung |
| 404 | nicht gefunden | bleibt zunächst indexiert | versehentlich tote URL |
| 410 | endgültig entfernt | schnelleres Deindexieren | bewusst gelöschter Inhalt |
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. Und er muss bleiben: Google empfiehlt, permanente Redirects mindestens ein Jahr, idealerweise dauerhaft, aktiv zu halten.
Kanonische Domain, Sitemap und interne Links
Ein Relaunch ist der richtige Moment, alle Domain- und URL-Varianten konsequent zu vereinheitlichen. Eine Website sollte eindeutig beantworten, ob https://example.com oder https://www.example.com verwendet wird, ob HTTP sauber auf HTTPS weiterleitet und ob Trailing Slashes, Groß-/Kleinschreibung oder Parameter Duplikate erzeugen. Canonical-Tags signalisieren die bevorzugte Variante, ersetzen aber keine Redirects, wenn alte URLs dauerhaft wegfallen. Bei mehrsprachigen Sites müssen hreflang, Canonicals und Sprachpfade zusammenpassen.
Die XML-Sitemap sollte nach dem Relaunch nur indexierbare, kanonische, erfolgreiche URLs enthalten – keine weitergeleiteten, noindex- oder Staging-Pfade. robots.txt muss auf die korrekte Sitemap verweisen und darf keine wichtigen CSS-, JS- oder Bildressourcen blockieren. Besonders wichtig: Die neue Website sollte intern direkt auf ihre finalen URLs verlinken und sich nicht über Redirects auf alte Ziele verlassen. Redirects sind für externe Altlasten da, nicht für die eigene Navigation. Wie technische Sauberkeit, Performance und Ladezeit zusammenhängen, zeigt unser Beitrag zu Core Web Vitals und Performance.
Tracking und Search Console gehören in die Vorbereitung
SEO-Verlust wird oft erst spät bemerkt, wenn das Tracking beim Relaunch beschädigt wurde. Vor dem Go-live sollte klar sein, welche Analytics-Properties bestehen bleiben, welche Events, Conversions und Consent-Einstellungen übernommen werden und ob Formulare, Klicks, Downloads und Buchungen weiter gemessen werden. Werden interne IPs, Staging-Domains und Test-Traffic gefiltert? Funktionieren UTM-Parameter und Kampagnen-Zuordnung? Jede Änderung an der Messlogik sollte dokumentiert werden – sonst ist später unklar, ob ein Rückgang aus SEO, Technik, Consent-Verhalten oder Messung stammt.
Die Search Console ist kein Reporting-Tool für später, sondern Teil der Vorbereitung. Vorher: Property für die kanonische Domain prüfen, Zugriffe sichern, Leistungsdaten exportieren, alte Top-Seiten und Suchanfragen dokumentieren. Nachher: neue Sitemap einreichen, wichtige URLs mit dem URL-Prüftool testen, Indexierungs-, 404- und Redirect-Fehler beobachten. Bei einem echten Domain-Umzug kommt das Adressänderungstool hinzu; bei einem Relaunch unter derselben Domain ist es nicht nötig.
Staging schützen, Launch testen, die ersten Wochen beobachten
Staging-Umgebungen sind eine häufige Fehlerquelle – sie dürfen nicht in den Index gelangen, müssen aber realistisch genug zum Testen sein. Sinnvolle Schutzmaßnahmen sind Passwortschutz oder IP-Beschränkung, keine öffentlichen Links auf Staging-URLs, keine Staging-Einträge in Sitemaps und keine Produktions-Canonicals, die auf Staging zeigen. Wird noindex zum Schutz genutzt, braucht es einen klaren Entfernungsschritt vor dem Go-live. Genau dieses vergessene noindex ist einer der häufigsten und teuersten Relaunch-Fehler.
Kurz vor dem Launch hilft eine knappe Abnahme-Checkliste: Ist noindex entfernt? Sind Canonicals auf Produktion gesetzt? Ist die Sitemap produktiv? Sind die Analytics-IDs korrekt? Funktionieren die Redirects auf der echten Domain? Nach dem Go-live gilt: alte Top-URLs auf korrekte Redirects testen, neue Seiten auf 200-Status prüfen, Sitemap einreichen, Echtzeitdaten kontrollieren. In den folgenden Wochen 404- und 5xx-Fehler zunächst täglich prüfen, Redirect-Ketten korrigieren und die Search-Console-Abdeckung beobachten. Google weist darauf hin, dass die Reindexierung einige Wochen dauern kann und größere Sites länger brauchen – kurzfristige Schwankungen sind also normal. Kritisch sind systematische Muster: viele alte URLs ohne Ziel, neue Seiten mit noindex, falsche Canonicals oder ein Tracking-Bruch. Dieselbe Disziplin, mit der wir Relaunches in Hamburg technisch begleiten, gilt hier: Qualität ist messbar, nicht Geschmackssache.
Nächste Schritte
Drei Fragen klären, wie risikoarm euer Relaunch wirklich ist:
- Bestand: Existiert ein vollständiges URL-Inventar inklusive tiefer Seiten, Backlinks und Conversions – oder nur die Menüstruktur?
- Redirects: Gibt es für jede alte URL eine bewusste Entscheidung (1:1, Thema, 410/404, unverändert) und einen Test vor dem Go-live?
- Messbarkeit: Sind Tracking, Consent und Search Console vor dem Launch geprüft, sodass ihr einen Rückgang sofort einordnen könnt?
Wer hier dreimal „ja" sagen kann, geht mit Plan statt mit Glück live. Unsicher bei einem anstehenden Umzug? Wir planen und begleiten Relaunches technisch von der Inventur bis zum Post-Launch-Monitoring. Sieh dir unsere Webentwicklung an oder buche direkt ein Erstgespräch.
