Eine SEO-Relaunch-Checkliste schützt nicht automatisch vor jeder Schwankung. Sie sorgt aber dafür, dass URL-Werte, Inhalte, interne Links, technische Signale und Messdaten nicht unkontrolliert verloren gehen. Besonders wichtig ist die Reihenfolge: Bestandsdaten werden gesichert, bevor neue Strukturen und Weiterleitungen finalisiert werden.
Diese Checkliste deckt Relaunches mit Design-, CMS-, Hosting-, Domain-, URL- oder Strukturänderungen ab. Nicht jeder Punkt ist für jedes Projekt relevant. Umfang, Verantwortliche, Prüfmethode und Abnahmekriterium werden deshalb vor Projektbeginn festgelegt.
Das Wichtigste in Kürze
- Ein Relaunch ist ein Migrationsprojekt, kein reiner Designwechsel.
- Bestehende URLs, Rankings, Klicks, Conversions, Backlinks und interne Links werden vor Änderungen inventarisiert.
- Jede relevante alte URL erhält eine begründete Entscheidung und gegebenenfalls ein fachlich passendes neues Ziel.
- Permanente Umzüge verwenden direkte serverseitige Weiterleitungen; pauschale Umleitung auf die Startseite ist zu vermeiden.
- Staging muss vor Indexierung geschützt sein, darf aber für autorisierte Tests nicht unsichtbar bleiben.
- Canonicals, Robots-Regeln und Sitemaps müssen zum Live-System passen und dürfen keine Staging-Signale enthalten.
- Go-live, Crawling, Indexierung, Suchleistung und Conversions werden über eine gemeinsame Ereignistimeline überwacht.
- Google weist darauf hin, dass während einer größeren Migration vorübergehende Ranking-Schwankungen normal sein können.
Welche Relaunch-Arten die Checkliste abdeckt
Design-Relaunch ohne URL-Änderung
Auch bei stabilen URLs können Hauptinhalte, Überschriften, interne Links, Rendering, strukturierte Daten, Tracking und Ladezeiten verändert werden.
CMS- oder Shopsystemwechsel
Templates, Canonicals, Parameter, Pagination, Filter, Sitemaps und technische Statuscodes können sich gleichzeitig ändern.
Neue Informations- und URL-Struktur
Navigation, Kategorien und Pfade werden neu geordnet. Dafür sind vollständiges Mapping und direkte Weiterleitungen erforderlich.
Domain- oder Subdomainwechsel
Zusätzlich zu Redirects und Signalen müssen alte und neue Search-Console-Properties, externe Profile und gegebenenfalls das Change-of-Address-Verfahren berücksichtigt werden.
Hosting- oder Infrastrukturwechsel
Bleiben die sichtbaren URLs unverändert, stehen DNS, Erreichbarkeit, Serverleistung, Caching und Crawlverhalten im Vordergrund.
Zusammenführung oder Aufteilung von Websites
Mehrere Contentbestände, Marken, Sprachen oder Systeme werden konsolidiert. Konflikte, Duplikate und verantwortliche Zielseiten benötigen besonders sorgfältige Entscheidungen.
Phase 1: Ziele, Scope und Verantwortlichkeiten
Vor Konzeption und Entwicklung werden folgende Punkte geklärt:
- Welche Geschäftsziele soll der Relaunch unterstützen?
- Welche Domains, Subdomains, Sprachen und Systeme sind betroffen?
- Ändern sich URLs, Inhalte, Navigation, CMS, Hosting oder Tracking?
- Wer entscheidet über URL-, Content- und Redirect-Fragen?
- Wer kann Server-, DNS-, Cache- und Robots-Einstellungen ändern?
- Welche Teams prüfen Entwicklung, Redaktion, Analytics und Datenschutz?
- Welche Bereiche sind geschäftskritisch?
- Welches Zeitfenster besitzt die Abnahme?
- Gibt es ein vollständiges Backup und einen realistischen Rollback-Plan?
- Welche Änderungen werden bewusst in eine spätere Phase verschoben?
Ein Relaunch sollte nicht gleichzeitig jedes bekannte SEO-Problem lösen. Kritische Migration und optionale Optimierung werden getrennt priorisiert.
Phase 2: SEO-Bestand vollständig sichern
URL-Inventar erstellen
URLs werden aus mehreren Quellen zusammengeführt:
- vollständiger Crawl der aktuellen Website
- XML-Sitemaps
- Google Search Console
- Webanalyse und Conversionberichte
- CMS- oder Datenbankexport
- Backlinkdaten
- bezahlte Kampagnen und externe Landingpage-Listen
- Serverlogs, wenn verfügbar und erforderlich
- bekannte PDFs, Bilder und Downloads
Keine Quelle allein ist vollständig. Das zusammengeführte Inventar wird normalisiert, ohne Parameter und Varianten vorschnell zu verwerfen.
Leistung und Wert pro URL dokumentieren
Für priorisierte URLs werden gesichert:
- Klicks und Impressionen
- Query- und Themencluster
- organische Sessions
- Leads, Umsatz oder unterstützte Conversions
- externe Links und wichtige Verweise
- interne Linktiefe
- Indexierungsstatus
- Canonical und HTTP-Status
- Seitentyp, Sprache und Zielgruppe
Ausgangszustand archivieren
Vor dem Wechsel sollten relevante Seitentitel, Meta Descriptions, Überschriften, Hauptinhalte, Canonicals, strukturierte Daten und interne Links nachvollziehbar sein. Ein Crawl-Export und Screenshots kritischer Templates erleichtern den späteren Vergleich.
Messbaseline festlegen
Die Baseline enthält mindestens:
- wichtige Landingpages und Verzeichnisse
- priorisierte Marken- und Nichtmarken-Queries
- Seitentypen und Länder
- Conversionpfade
- technische Fehlerklassen
- Zeitpunkt geplanter Releases
- normale Saisonalität und Vergleichszeiträume
Phase 3: Neue Architektur und URL-Mapping
Seitenaufgaben definieren
Jede neue Zielseite erhält eine klare Suchintention, Zielgruppe und Conversionaufgabe. Ähnliche Seiten werden nur zusammengeführt, wenn die neue Seite die bisherigen Nutzerbedürfnisse fachlich abdeckt.
Pro alter URL entscheiden
Für jede relevante Alt-URL wird dokumentiert:
- unverändert übernehmen
- auf neue gleichwertige URL umziehen
- mit anderer Seite konsolidieren
- bewusst entfernen und korrekten 404- oder 410-Status liefern
- vorerst erhalten und später überarbeiten
Redirect-Mapping aufbauen
Das Mapping enthält:
- vollständige alte URL
- vollständige Ziel-URL
- Begründung oder Contentbeziehung
- Regel oder individuelle Weiterleitung
- verantwortliche Umsetzung
- Teststatus
- mögliche Konflikte mit bestehenden Redirects
Google empfiehlt, alte URLs direkt auf fachlich passende neue Ziele weiterzuleiten. Viele unterschiedliche Seiten pauschal auf die Startseite umzuleiten, kann Nutzer verwirren und als Soft 404 behandelt werden.
Interne Verlinkung planen
Navigation, Breadcrumbs, Contentlinks, Footer, HTML-Sitemaps und Komponenten müssen direkt auf neue Ziel-URLs zeigen. Interne Links sollten nicht dauerhaft über Redirects laufen.
Phase 4: Staging technisch absichern und prüfbar machen
Indexierungsschutz
Das Staging benötigt einen verlässlichen Zugriffsschutz, etwa über Authentifizierung oder Netzwerkregeln. Ein noindex kann zusätzlich verwendet werden, darf beim Go-live aber nicht versehentlich bestehen bleiben.
Staging-Signale prüfen
- keine Staging-Domain in Canonicals
- keine Staging-Domain in Hreflang
- keine Staging-Domain in strukturierten Daten und
@id - keine Staging-URLs in XML-Sitemaps
- keine internen Links auf Test- oder Alt-Domains
- korrekte Protokoll- und Hostvarianten
- keine produktiven Formulare oder E-Mails ohne Testkennzeichnung auslösen
Rendering und Seitentypen testen
Für jede wichtige Templatefamilie werden geprüft:
- Seitentitel und genau eine sinnvolle H1
- sichtbarer Hauptinhalt
- Überschriftenhierarchie
- Navigation und Breadcrumb
- interne Links
- Canonical und Meta Robots
- strukturierte Daten
- Bilder, Videos und Downloads
- mobile Darstellung
- Formulare, Suche und Filter
- JavaScript-Rendering
- Statuscodes und Fehlerseiten
Performance und Infrastruktur testen
- Serverkapazität für Nutzer und Crawler
- Cache- und CDN-Regeln
- Weiterleitungsleistung
- Timeouts und 5xx-Fehler
- Bildgrößen und Lazy Loading
- zentrale Core-Web-Vitals-Risiken
- Monitoring und Logzugriff
Phase 5: Content- und Onpage-Abnahme
Wertvolle Inhalte schützen
- zentrale Aussagen und Suchintention bleiben erhalten
- leistungsstarke Abschnitte werden nicht unbegründet entfernt
- wichtige Medien und Downloads werden übernommen
- Autoren- und Aktualisierungsinformationen bleiben sichtbar
- interne Links zu vertiefenden Seiten werden aktualisiert
- Inhalte werden nicht allein wegen eines neuen Designs stark gekürzt
Snippets und Metadaten prüfen
- eindeutiger SEO-Titel pro indexierbarer Seite
- passende Meta Description
- Open-Graph- und Social-Daten
- korrekte Sprach- und Gebietssignale
- keine Platzhalter oder automatisch duplizierten Metadaten
Strukturierte Daten prüfen
- Markup entspricht sichtbarem Inhalt
- Organisation und Personen besitzen konsistente IDs
- keine Staging-Domain oder alte Logos
- keine doppelten widersprüchlichen Plugin-Graphs
- Validierung der tatsächlich unterstützten Typen
Phase 6: Tracking, Datenschutz und Geschäftsfunktionen
Vor dem Go-live werden getestet:
- Analytics- und Tag-Management-Auslieferung
- Consent-Modus und Einwilligungslogik
- Search-Console-Verifizierung
- Formularstart und Formularversand
- Telefon-, E-Mail- und Termininteraktionen
- E-Commerce- und Umsatzereignisse
- Danke-Seiten und deren Indexierungsstatus
- Cross-Domain- und Payment-Wege
- CRM- oder Leadübergabe
- Fehler- und Abbruchereignisse
Ein technisch erfolgreicher Relaunch ist geschäftlich nicht erfolgreich, wenn Anfragen oder Käufe unbemerkt ausfallen.
Phase 7: Pre-Launch-Freigabe
Vor dem festgelegten Go-live müssen mindestens folgende Punkte freigegeben sein:
- vollständiges Backup von Dateien und Datenbank
- getesteter Rollback- und Kommunikationsplan
- finale Redirect-Datei oder -Regeln
- definierter DNS- und Cache-Ablauf
- aktuelle Crawls von Live und Staging
- Liste bekannter und akzeptierter Restfehler
- klare Go-/No-Go-Verantwortung
- Erreichbarkeit von Entwicklung, Hosting, SEO und Projektleitung
- Monitoring-Dashboard und Alarmwege
- Zeitpunkt mit möglichst geringem Geschäftsrisiko
Ein Freigabedokument hält fest, welche Kriterien bestanden, offen oder bewusst akzeptiert sind.
Phase 8: Go-live-Checkliste
Unmittelbar nach dem Umschalten werden geprüft:
- Startseite und geschäftskritische URLs erreichbar
- HTTP/HTTPS und Hostvarianten korrekt
- DNS, Zertifikat und CDN funktionsfähig
- alte URLs liefern erwartete direkte permanente Redirects
- keine Redirectketten oder -schleifen
- wichtige neue URLs liefern Status 200
- nicht vorhandene URLs liefern echten 404- oder 410-Status
- Robots.txt ist produktionsgeeignet
noindex-Stagingregeln sind entfernt- Canonicals zeigen auf finale produktive URLs
- Hreflang zeigt auf erreichbare, korrespondierende Seiten
- XML-Sitemaps enthalten nur gewollte kanonische URLs
- interne Links führen direkt auf neue URLs
- strukturierte Daten enthalten keine Staging- oder Alt-Domain
- Formulare, Suche, Checkout und Login funktionieren
- Analytics und Conversionereignisse werden empfangen
- Server, Cache und Logs zeigen keine kritische Fehlerwelle
Die wichtigsten Checks werden nicht nur manuell auf fünf Seiten durchgeführt. Redirects, Statuscodes, Canonicals und interne Links werden für große Mengen automatisiert getestet.
Phase 9: Search Console und Suchsysteme
Nach dem Go-live:
- neue XML-Sitemap einreichen
- wichtige URLs mit URL-Prüfung kontrollieren
- alte und neue Properties überwachen
- Indexierungs- und Crawlingberichte prüfen
- Sicherheits- und manuelle Maßnahmen ausschließen
- bei echtem Domain- oder Subdomainwechsel das Change-of-Address-Verfahren prüfen
- externe Profile, Kampagnen und wichtige Backlinks aktualisieren
Google empfiehlt das Change-of-Address-Tool nur für Domain- oder Subdomainwechsel, nicht für reine Pfadänderungen innerhalb derselben Domain.
Phase 10: Monitoring nach dem Relaunch
Erste Stunden und Tage
- Erreichbarkeit und 5xx-Fehler
- Redirectfehler
- Robots- und Canonical-Ausgabe
- Tracking und Conversions
- Server- und Crawlaktivität
- kritische Templates und Seitentypen
Erste Wochen
- Indexierung alter und neuer URLs
- Klicks und Impressionen nach Verzeichnis und Seitentyp
- Marken- und Nichtmarken-Queries
- wichtige Rankings als ergänzende Stichprobe
- organische Landingpages und Conversions
- Soft-404- und Canonicalabweichungen
- interne und externe Links auf alte Ziele
- Core Web Vitals und reale Performance
Google erklärt, dass größere URL-Migrationen vorübergehende Schwankungen verursachen können, während alte und neue URLs erneut gecrawlt und verarbeitet werden. Für kleine bis mittlere Websites kann die Umstellung mehrere Wochen beanspruchen; es gibt keine feste Crawlgeschwindigkeit.
Befunde dokumentieren und priorisieren
Jede Abweichung erhält:
- betroffenen Umfang
- Startzeitpunkt
- Datenquelle
- mögliche Ursache
- Dringlichkeit
- verantwortliche Person
- Maßnahme
- Nachkontrolltermin
SEO-Monitoring verbindet diese Daten mit der Ereignistimeline. Bei unerwarteten Verlusten folgt eine strukturierte SEO-Problemanalyse statt hektischer Pauschaländerungen.
Weiterleitungen: die wichtigsten Regeln
- permanente serverseitige 301- oder 308-Weiterleitungen für dauerhafte Umzüge
- direkte Weiterleitung ohne Ketten
- fachlich gleichwertiges Ziel
- keine pauschale Startseitenumleitung für nicht verwandte Inhalte
- Queryparameter nur nach dokumentierter Logik behandeln
- bestehende Redirects in die neue Regelmenge integrieren
- alte Domains und Weiterleitungen langfristig kontrollieren
- interne Links auf direkte Ziel-URLs aktualisieren
Google empfiehlt, Redirects bei Site Moves so lange wie möglich und im Allgemeinen mindestens ein Jahr zu erhalten. Aus Nutzersicht kann eine dauerhafte Beibehaltung sinnvoll sein.
Häufige Relaunch-Fehler
- SEO erst kurz vor dem Go-live einbeziehen
- URL-Inventar nur aus der Sitemap erstellen
- alte Seiten nach Designgefühl statt Datenwert bewerten
- alle entfernten URLs auf die Startseite umleiten
- Redirectketten aus mehreren Migrationen übernehmen
- Staging-
noindex, Robots- oder Canonical-Regeln live schalten - interne Links dauerhaft über Redirects führen
- Formulare und Conversiontracking nicht testen
- Domain, CMS, Struktur und Content ohne Phasen gleichzeitig ändern
- Monitoring erst nach sichtbarem Trafficverlust beginnen
- temporäre Schwankung und technisches Problem nicht unterscheiden
- alte Website oder Backups zu früh abschalten
Häufige Fragen zur SEO-Relaunch-Checkliste
Muss jede alte URL weitergeleitet werden?
Nein. Relevante umgezogene oder konsolidierte Inhalte benötigen passende Ziele. Dauerhaft entfernte Inhalte ohne Ersatz können einen echten 404- oder 410-Status liefern. Die Entscheidung erfolgt pro URL oder klarer Regelklasse.
Sind 301-Weiterleitungen schädlich für Rankings?
Google sagt, dass permanente Weiterleitungen bei einem Site Move keinen PageRank-Verlust verursachen. Entscheidend sind passende Ziele, direkte Regeln und konsistente weitere Signale.
Wie lange müssen Redirects bestehen bleiben?
Google empfiehlt im Allgemeinen mindestens ein Jahr und möglichst länger. Nutzer und externe Links können alte URLs auch danach noch verwenden.
Wann wird das Change-of-Address-Tool benötigt?
Bei einem Wechsel der Domain oder Subdomain. Für HTTP-zu-HTTPS, www-Änderungen derselben Domain oder reine Pfadänderungen ist es laut Google nicht vorgesehen.
Wie lange schwanken Rankings nach einem Relaunch?
Es gibt keinen festen Zeitraum. Umfang, Serverleistung, Zahl der URLs und Qualität der Migration beeinflussen, wie schnell Systeme alte und neue URLs verarbeiten.
Sollte der Go-live bei geringem Traffic stattfinden?
Wenn möglich ja, solange alle verantwortlichen Teams verfügbar bleiben. Google empfiehlt, Site Moves bei saisonalen Websites in verkehrsärmere Zeiträume zu legen.
Brauche ich Hosting-Zugriff für die Relaunch-Prüfung?
Spätestens für Backups, Redirects, DNS-, Cache-, Log- und Serverprüfungen wird technischer Zugriff oder eine verfügbare Hosting-/Entwicklungsverantwortung benötigt.
Reicht diese Checkliste ohne individuelle Prüfung?
Sie deckt die wichtigsten Bereiche ab, kennt aber weder Ihre Plattform noch geschäftskritische Seitentypen. Große Shops, internationale Websites und JavaScript-Systeme benötigen zusätzliche Tests.
Fachliche Einordnung
Autor: Markus Buchheit, SEO- und GEO-Berater. Zuletzt fachlich geprüft: 1. September 2026. Diese Checkliste ist Teil des SEO- und GEO-Wissensbereichs, in dem Methoden, Quellen und Grenzen transparent eingeordnet werden.
Relaunch vor dem Go-live kontrolliert abnehmen
Wenn URL-Mapping, Weiterleitungen, Staging-Signale oder Tracking noch nicht unabhängig geprüft wurden, kann ein Pre-Launch-Check die kritischen Risiken vor dem Umschalten sichtbar machen.
