SEO-Relaunch-Checkliste: Was muss vor und nach dem Website-Relaunch geprüft werden?

Wann wird ein Relaunch zum SEO-Risiko?

Ein Relaunch kann sehr unterschiedliche Änderungen umfassen. Manchmal ändert sich nur das Erscheinungsbild. In anderen Fällen werden gleichzeitig CMS, Navigation, Inhalte, Domain, URL-Struktur und technische Infrastruktur ausgetauscht.

Je mehr dieser Ebenen gleichzeitig verändert werden, desto schwieriger wird es später, die Ursache eines Problems eindeutig zu bestimmen.

Google empfiehlt bei komplexeren Veränderungen deshalb, Änderungen nach Möglichkeit nicht unnötig miteinander zu vermischen. Wer beispielsweise Domain, CMS und Layout ändern möchte, sollte prüfen, ob diese Schritte sinnvoll voneinander getrennt werden können.

Wenn noch nicht geklärt ist, ob überhaupt ein vollständiger Neubau notwendig ist, hilft zunächst die Entscheidungshilfe „Alte Website optimieren oder neu erstellen?“ .

1. Vor dem Relaunch den Ausgangszustand dokumentieren

Bevor die bestehende Website verändert wird, sollte klar sein, was heute tatsächlich vorhanden und relevant ist.

Dazu gehören insbesondere:

• aktuell erreichbare URLs,
• wichtige organische Landingpages,
• Seiten mit externen Backlinks,
• Seiten mit Impressionen und Klicks in der Google Search Console,
• wichtige interne Verlinkungen,
• bestehende Canonicals,
• Weiterleitungen und HTTP-Statuscodes,
• aktuelle XML-Sitemaps,
• sowie Inhalte, Bilder, Downloads und andere URLs, die weiterhin benötigt werden.

Eine Sitemap allein ist dabei kein vollständiges Inventar. Je nach Website können zusätzlich CMS-Exporte, Crawling-Daten, Serverprotokolle, Webanalyse und Search Console notwendig sein.

2. Festlegen, was tatsächlich geändert werden soll

Nicht jede bestehende URL muss beim Relaunch geändert werden. Wenn eine Adresse weiterhin verständlich, technisch geeignet und inhaltlich korrekt ist, kann ihre Beibehaltung unnötige Migrationsarbeit vermeiden.

Änderungen sollten deshalb einen konkreten Grund haben, beispielsweise:

• eine logischere Informationsarchitektur,
• zusammengeführte oder entfernte Inhalte,
• technisch problematische alte URL-Strukturen,
• eine Domain- oder Protokolländerung,
• oder eine grundlegende Neustrukturierung des Angebots.

Ein Relaunch ist kein Anlass, funktionierende URLs allein aus optischen Gründen umzubenennen.

3. Staging vollständig testen

Die neue Website sollte vor dem Livegang in einer Test- oder Stagingumgebung geprüft werden.

Dabei sollte nicht nur kontrolliert werden, ob das Design funktioniert. Wichtig sind unter anderem:

• Navigation und interne Links,
• mobile Darstellung,
• Formulare und Kontaktwege,
• Seitentitel und Meta-Beschreibungen,
• Canonicals,
• strukturierte Daten,
• Statuscodes,
• Tracking und Consent,
• sowie Performance und externe Skripte.

Während der Entwicklung wird eine Stagingumgebung häufig gegen Suchmaschinenzugriffe geschützt. Entscheidend ist deshalb ein eigener Launch-Check: Sperren, die nur für die Entwicklung gedacht waren, dürfen nicht versehentlich auf der Livewebsite bestehen bleiben.

4. Alte und neue URLs eindeutig zuordnen

Wenn sich URLs ändern, sollte vor dem Livegang ein Alt-zu-Neu-Mapping erstellt werden.

Alte URLs sollten nicht pauschal auf die Startseite weitergeleitet werden. Wenn das Ziel fachlich nicht zum alten Inhalt passt, kann eine solche Weiterleitung für Nutzer unverständlich sein und von Google als Soft-404 interpretiert werden.

5. Permanente Weiterleitungen vor dem Launch vorbereiten

Für dauerhaft ersetzte URLs empfiehlt Google nach Möglichkeit serverseitige permanente HTTP-Weiterleitungen wie 301 oder 308.

Die Weiterleitung sollte möglichst direkt von der alten auf die endgültige neue Adresse führen.

Ketten wie:

alt → zwischenziel → neues ziel

sind unnötig, wenn direkt auf das endgültige Ziel weitergeleitet werden kann.

Welche Statuscodes bei dauerhaften und temporären Änderungen sinnvoll sind, erklärt ausführlicher: „301 oder 302 Weiterleitung – welche ist für SEO richtig?“ .

6. Canonicals auf die neuen URLs ausrichten

Eine neue Seite sollte nicht gleichzeitig per Weiterleitung, interner Verlinkung und Sitemap als neue URL erscheinen, während ihr Canonical weiterhin auf die alte Adresse zeigt.

Google empfiehlt bei einer Migration, die Canonical-Angaben der neuen Seiten auf die neuen URLs zu aktualisieren.

Bei einer regulären eigenständigen Seite bedeutet dies üblicherweise ein selbstreferenzierendes Canonical auf die tatsächlich gewünschte neue URL.

7. Interne Links direkt aktualisieren

Eine permanente Weiterleitung ist kein Grund, interne Links dauerhaft auf der alten Adresse zu belassen.

Navigation, Footer, Inhaltslinks, Buttons und andere interne Verweise sollten nach Möglichkeit direkt auf die neue URL zeigen.

Dadurch entstehen klarere Nutzerwege und unnötige Weiterleitungsschritte werden vermieden.

8. XML-Sitemap neu erzeugen

Nach einer URL-Migration sollte die Sitemap die tatsächlich gewünschten neuen URLs enthalten.

Prüfen Sie insbesondere:

• Sind nur erreichbare und indexierbare Zielseiten enthalten?
• Stimmen Sitemap-URLs und Canonicals überein?
• Fehlen wichtige neue Seiten?
• Sind versehentlich alte oder weitergeleitete URLs enthalten?

Google empfiehlt außerdem, die neue Sitemap in der Search Console einzureichen.

9. noindex und robots.txt vor dem Livegang kontrollieren

Ein klassischer Relaunchfehler entsteht, wenn eine Entwicklungssperre versehentlich auf der Livewebsite bestehen bleibt.

Deshalb sollten unmittelbar vor und nach dem Launch unter anderem geprüft werden:

• Meta-Robots-Anweisungen,
• HTTP-Robots-Header,
• robots.txt-Regeln,
• Canonicals,
• sowie die tatsächliche HTTP-Antwort wichtiger URLs.

Ein versehentliches noindex auf zentralen Zielseiten kann die Aufnahme in den Suchindex verhindern.

10. Inhalte und Seitentypen nicht blind austauschen

Ein Relaunch kann technisch perfekt funktionieren und trotzdem Suchsichtbarkeit verlieren, wenn erfolgreiche Inhalte oder die Suchintention wichtiger Seiten grundlegend verändert werden.

Deshalb sollte für wichtige organische Landingpages geklärt werden:

• Welche Suchintention erfüllt die bestehende Seite?
• Welche Informationen machen sie aktuell nützlich?
• Welche Leistungs- oder Themenzuordnung besitzt sie?
• Soll dieselbe Aufgabe nach dem Relaunch weiterhin erfüllt werden?

Ein neues Layout allein ist kein Grund, bewährte Inhalte ohne fachlichen Anlass zu entfernen.

11. Tracking und Conversionpfade testen

SEO endet beim Relaunch nicht mit der Indexierung. Eine Website kann weiterhin Besucher erhalten und gleichzeitig wichtige Kontakt- oder Messprozesse verlieren.

Vor dem Livegang sollten deshalb unter anderem getestet werden:

• Kontaktformulare,
• Telefonnummern und E-Mail-Verknüpfungen,
• Consent-abhängige Dienste,
• Webanalyse und Conversionmessung,
• zentrale Buttons und Call-to-Actions,
• sowie gegebenenfalls Kampagnen- und Werbelinks.

12. Backup und Rückfallplan vorbereiten

Vor dem Livegang sollte ein technisch verwertbares Backup des bisherigen Systems beziehungsweise der relevanten Daten vorhanden sein.

Zusätzlich sollte klar sein, wie bei einem kritischen Fehler reagiert wird.

Ein Rückfallplan bedeutet nicht, bei jeder kleinen Abweichung sofort den gesamten Relaunch zurückzudrehen. Er sorgt vielmehr dafür, dass bei einem echten technischen Ausfall nicht erst während des Problems entschieden werden muss, welche Version wiederhergestellt werden kann.

Launch-Check: unmittelbar nach der Veröffentlichung

Sobald die neue Website erreichbar ist, sollten die wichtigsten Prüfungen erneut auf der tatsächlichen Liveumgebung durchgeführt werden.

1. Wichtige neue URLs liefern 200.
2. Alte ersetzte URLs leiten auf die vorgesehenen Ziele.
3. Gelöschte Inhalte ohne Ersatz liefern einen sinnvollen Fehlerstatus.
4. Es bestehen keine unbeabsichtigten Redirectketten oder -schleifen.
5. Canonicals zeigen auf die gewünschten Live-URLs.
6. Interne Links verwenden die neuen Ziele.
7. Wichtige Seiten enthalten kein versehentliches noindex.
8. robots.txt blockiert keine benötigten Bereiche.
9. Die neue Sitemap ist erreichbar und aktuell.
10. Formulare, Consent und Tracking funktionieren.

Wann ist das Search-Console-Tool zur Adressänderung notwendig?

Das Tool zur Adressänderung ist für einen Wechsel von einer Domain oder Subdomain auf eine andere vorgesehen.

Es ist dagegen nicht für jede Relaunch-Situation erforderlich. Google nennt unter anderem reine Pfadänderungen innerhalb derselben Website und die Umstellung von HTTP auf HTTPS als Fälle, für die dieses Werkzeug nicht verwendet wird.

Eine Adressänderung ersetzt außerdem keine Weiterleitungen. Sie wird erst nach den technischen Vorarbeiten eingesetzt.

Nach dem Relaunch beginnt das Monitoring

Der erfolgreiche Livegang ist nicht das Ende der Migration.

In den folgenden Tagen und Wochen sollten insbesondere beobachtet werden:

• Indexierung neuer URLs,
• Impressionen und Klicks in der Search Console,
• Crawling- und Serverfehler,
• ungewöhnliche 404- oder 5xx-Antworten,
• Weiterleitungsfehler,
• organischer Traffic,
• wichtige Rankings,
• sowie Kontakt- und Conversiondaten.

Vorübergehende Schwankungen können während einer Websitemigration auftreten, weil Suchmaschinen alte und neue URLs erneut crawlen und verarbeiten müssen.

Ein Rankingrückgang unmittelbar nach dem Relaunch ist deshalb ein Anlass zur Prüfung, aber noch kein Beweis für eine einzelne konkrete Ursache.

Zur Diagnose: „Google-Ranking plötzlich gefallen?“

Wie lange sollten permanente Weiterleitungen bestehen bleiben?

Google empfiehlt bei Websitemigrationen, permanente Weiterleitungen möglichst lange und grundsätzlich mindestens ein Jahr beizubehalten.

Aus Nutzersicht kann es sinnvoll sein, wichtige dauerhafte Weiterleitungen noch länger bestehen zu lassen, insbesondere wenn alte externe Links oder gespeicherte URLs weiterhin genutzt werden.

Kompakte SEO-Relaunch-Checkliste

• Ausgangs-URLs und wichtige Landingpages erfassen.
• Organische Leistungsdaten und wichtige Backlinks sichern.
• Änderungen an URLs nur mit nachvollziehbarem Grund planen.
• Alt-zu-Neu-URL-Mapping erstellen.
• Dauerhafte Redirects für ersetzte URLs vorbereiten.
• Irrelevante Massenweiterleitungen vermeiden.
• Canonicals auf neue Ziel-URLs ausrichten.
• Interne Links aktualisieren.
• XML-Sitemap neu erzeugen.
• Staging-Sperren vor dem Launch entfernen.
• Statuscodes und Weiterleitungen auf der Livewebsite testen.
• Formulare, Consent und Tracking kontrollieren.
• Backup und Reaktionsplan vorbereiten.
• Search Console und Analysewerkzeuge nach dem Launch beobachten.
• Permanente Weiterleitungen langfristig bestehen lassen.

Fazit

Ein SEO-Relaunch sollte nicht erst am Veröffentlichungstag beginnen.

Die wichtigsten Entscheidungen fallen vorher: Welche URLs bleiben bestehen, welche ändern sich, wohin werden alte Adressen weitergeleitet und welche Inhalte sollen ihre bisherige Aufgabe weiterhin erfüllen?

Direkt vor dem Launch müssen technische Sperren, Weiterleitungen, Canonicals, interne Links, Sitemap, Tracking und zentrale Funktionen geprüft werden.

Nach dem Launch folgt das Monitoring. Erst dadurch wird sichtbar, ob Suchmaschinen und Nutzer die neue Struktur wie geplant erreichen können.