Relaunch ohne Ranking-Verlust:
Der saubere Prozess in neun Schritten

Warum Relaunches Rankings kosten — und warum das vermeidbar ist

Suchmaschinen ranken nicht „Websites" als Ganzes, sondern einzelne URLs. Jede URL hat über Jahre Signale gesammelt: Backlinks, Klick-Verhalten, Content-Qualität, interne Verlinkung. Wenn eine URL nach einem Relaunch verschwindet, ist dieser ganze Signal-Bestand wertlos — sofern nicht eine saubere Weiterleitung den Bestand auf die neue Adresse überträgt.

Die häufigsten Ursachen für Ranking-Verlust beim Relaunch sind:

• Unvollständiges URL-Mapping: Detailseiten, Blog-Artikel oder Sub-Sub-Kategorien werden vergessen — meist die Seiten mit Long-Tail-Traffic.
• Pauschale Weiterleitungen: Alle alten URLs zeigen auf die Startseite oder auf eine generische Übersicht. Suchmaschinen erkennen das als „Soft 404".
• Verschobener Content ohne Hinweis: Texte wandern in andere Bereiche, ohne dass Suchmaschinen die Verbindung herstellen können.
• Geänderte Seitenstruktur: Die Hierarchie wird umgebaut — wichtige Seiten rutschen tief in die Navigation, verlieren interne Linkkraft.
• Indexierungs-Probleme: robots.txt, „noindex"-Header oder Canonical-Tags der Staging-Phase bleiben versehentlich live.
• Verloren gegangene Inhalte: Top-Seiten der alten Website wurden gestrichen, ohne dass ein Ersatz vorhanden ist.

Jede dieser Ursachen ist vermeidbar — aber nur, wenn der Relaunch als Prozess verstanden wird, nicht als „neue Website hochladen". Der Prozess beginnt Wochen vor der Live-Schaltung und endet zwei Wochen danach.

Schritt 1 + 2: Bestandsaufnahme vor dem Relaunch

Bevor irgendetwas an der neuen Website passiert, wird die alte Website inventarisiert. Ohne diese Bestandsaufnahme fehlt später die Vergleichsbasis für jede Entscheidung — und das URL-Mapping hat keine Grundlage.

Schritt 1: Vollständige URL-Liste der alten Website

Ein Crawler durchläuft die komplette alte Domain und exportiert jede einzelne erreichbare URL. Diese Liste ist die Grundlage des gesamten Mapping-Prozesses. Wichtig: Auch URLs erfassen, die nicht direkt verlinkt sind — etwa alte Landingpages, Pressemitteilungen, archivierte News-Beiträge. Quellen für diese „versteckten" URLs:

• Bestehende XML-Sitemap: Sofern eine geführt wurde, ist das die offizielle URL-Liste der Domain.
• Search-Console-Export: Die Search Console kennt alle URLs, die Suchmaschinen in den letzten Monaten gecrawlt haben — oft mehr als die Sitemap.
• Server-Log-Auswertung: Welche URLs wurden in den letzten zwölf Monaten tatsächlich aufgerufen?
• Webanalyse-Tool: Top-Landingpages der letzten zwölf Monate exportieren — diese Seiten bringen den meisten Traffic.
• Backlink-Analyse: Welche externen Seiten verlinken auf alte URLs? Diese URLs dürfen auf keinen Fall ins Leere laufen.

Schritt 2: Top-Traffic-Seiten priorisieren

Nicht alle URLs sind gleich wichtig. Aus der Bestandsaufnahme werden die Seiten extrahiert, die in den letzten zwölf Monaten den meisten organischen Traffic, die meisten Anfragen oder die meisten Backlinks gebracht haben. Diese Liste der „Money-Pages" wird zur Priorität: Sie bekommen die saubersten 1:1-Mappings, die gründlichste Content-Übernahme und das engste Post-Launch-Monitoring.

Faustregel: In den meisten KMU-Websites generieren 10 bis 20 Prozent der URLs rund 80 Prozent des organischen Traffics. Wer diese kritische Minderheit identifiziert, kann den Aufwand für das Mapping richtig dosieren — viel Sorgfalt dort, weniger bei tief verschachtelten Archiv-Seiten ohne Traffic.

Schritt 3: URL-Mapping — das Kernkapitel

Das URL-Mapping ist die wichtigste einzelne Aufgabe im gesamten Relaunch-Prozess. Wenn nur eines dieser neun Schritte richtig gemacht wird, sollte es dieses sein. Das Mapping ist eine Tabelle, in der jeder einzelne alten URL eine Zieladresse auf der neuen Website zugeordnet ist — und für jede Zuordnung wird dokumentiert, warum sie so getroffen wurde.

Struktur der Mapping-Tabelle

Eine saubere Mapping-Tabelle hat mindestens diese Spalten:

1. Alte URL (vollständig): Inklusive Pfad und eventueller Query-Parameter.
2. Aktueller Status: Was steht heute unter dieser URL? Welcher Content, welche Position in der alten Struktur?
3. Traffic / Backlinks: Letzte zwölf Monate Sessions, Anfragen, eingehende Links. Priorisierungs-Basis.
4. Neue URL: Die Zieladresse auf der neuen Website.
5. Status der neuen URL: Existiert die neue URL bereits, ist sie inhaltlich vergleichbar, oder ist sie eine übergeordnete Kategorie?
6. Begründung der Zuordnung: Ein Satz, warum genau diese Zuordnung gewählt wurde.
7. Statuscode: 301 (dauerhaft) für fast alle Fälle; 410 (Gone) wenn Inhalt absichtlich entfernt wird und kein Ersatz vorhanden ist.
8. Geprüft am / von: Wer hat die Zuordnung gegengelesen?

Die fünf Mapping-Szenarien

Jede alte URL fällt in eines von fünf Mapping-Szenarien — und jedes hat eine klare Lösung:

• 1:1-Mapping: Die Inhalte bleiben gleich, nur die URL ändert sich. 301-Redirect, Standardfall.
• Inhalts-Zusammenfassung: Mehrere alte URLs werden auf einer neuen, umfassenderen Seite zusammengeführt. Alle alten URLs zeigen per 301 auf die neue Seite.
• Inhalts-Aufteilung: Eine alte URL wird in mehrere neue Seiten aufgeteilt. 301 auf die thematisch zentrale neue Seite, von dort interne Verlinkung zu den weiteren neuen Seiten.
• Übergeordnete Zuordnung: Es gibt keinen 1:1-Ersatz, aber eine sinnvolle übergeordnete neue Seite. 301 dorthin, mit Hinweis im Content auf den ursprünglichen Sachverhalt.
• Bewusste Entfernung: Der Inhalt existiert nicht mehr und soll auch nicht ersetzt werden. 410 (Gone), nicht 404. Suchmaschinen entfernen 410-URLs schneller aus dem Index als 404.

Was nicht ins Mapping gehört

Drei häufige Fehler im Mapping müssen ausgeschlossen werden:

• Pauschale Weiterleitung auf die Startseite: Suchmaschinen werten dies als „Soft 404", der Linkwert geht verloren.
• Redirect-Ketten: Alte URL → erste neue URL → finale neue URL. Jeder Sprung kostet Linkkraft. Direktes Mapping auf das finale Ziel.
• Kreis-Redirects: A leitet auf B, B leitet auf A. Suchmaschinen brechen das Crawling ab; entstehen meist durch zwei unabhängige Mapping-Listen.

Gegenlesen ist Pflicht

Eine Mapping-Tabelle wird mindestens zweimal von einer zweiten Person gegengelesen — und zwar nicht „kurz durchschauen", sondern Zeile für Zeile gegen den Live-Stand der alten Website abgeglichen. Dieser Schritt fühlt sich überflüssig an und ist es nie. Pro hundert Mapping-Einträge entdeckt ein guter Reviewer im Schnitt fünf bis zehn falsche Zuordnungen.

Schritt 4: Staging mit Indexierungs-Schutz

Parallel zum Mapping entsteht die neue Website auf einer Staging-Umgebung. Das ist eine separate Subdomain oder ein separater Server, auf dem die neue Website entwickelt, getestet und finalisiert wird — bevor sie auf die Hauptdomain wechselt. Die kritische Frage: Staging-Umgebungen dürfen unter keinen Umständen von Suchmaschinen indexiert werden.

Warum eine indexierte Staging-Umgebung gefährlich ist

Wenn die Staging-Seite mit denselben Texten und Bildern wie die spätere Live-Version unter staging.beispiel.de erreichbar ist und indexiert wird, entsteht Duplicate Content der schädlichsten Sorte: Suchmaschinen wissen nicht, welche Version die echte ist, und ranken im Zweifel keine von beiden gut. Nach dem Live-Gang bleibt die Staging-Subdomain dann oft monatelang im Index — und die neue Live-Version konkurriert mit ihrer eigenen Vorab-Version.

Die saubere Absicherung in drei Schichten

1. HTTP-Basic-Auth: Die Staging-Subdomain ist nur mit Benutzername und Passwort erreichbar. Suchmaschinen kommen gar nicht erst zum Content — das ist die wichtigste Schicht.
2. X-Robots-Tag „noindex": Per Server-Konfiguration wird im HTTP-Header jeder Antwort ein „noindex" mitgesendet. Falls die Auth-Schicht je deaktiviert wird, greift diese Schicht.
3. robots.txt mit Disallow: Die Staging-Subdomain hat eine eigene robots.txt, die jeden Crawler aussperrt. Letzte Schicht — allein nicht ausreichend, weil sie nur eine Bitte ist, keine technische Sperre.

Wichtig: Vor dem Go-Live müssen alle drei Schichten zurückgebaut werden — sonst ist die Live-Domain ebenfalls gesperrt. Das ist einer der häufigsten und schmerzhaftesten Fehler bei Relaunches: Die neue Website ist live, aber für Suchmaschinen unsichtbar, weil der noindex-Header nicht entfernt wurde.

Schritt 5: Pre-Launch-Check 24 Stunden vor Live

Am Tag vor der Live-Schaltung wird eine standardisierte Checkliste durchgegangen. Diese Checkliste fängt die häufigsten und am schwersten reparierbaren Fehler ab — und braucht in der Regel eine bis zwei Stunden.

Die kritischen Prüfpunkte

• Indexierungs-Steuerung: Kein „noindex"-Meta-Tag in den finalen Templates. robots.txt erlaubt Indexierung. X-Robots-Tag-Header sind entfernt.
• Canonical-Tags: Jede Seite hat einen Canonical-Tag, der auf sich selbst zeigt. Keine versehentlichen Canonicals auf Staging-URLs.
• Sitemap: XML-Sitemap der neuen Domain ist vorbereitet, enthält nur die finalen URLs, ist live erreichbar.
• 301-Redirects vorbereitet: Mapping-Tabelle ist in den Server-Regeln umgesetzt — auf der Test-Umgebung wird geprüft, ob jede alte URL korrekt weitergeleitet wird.
• Interne Verlinkung: Alle internen Links in der neuen Website zeigen auf die neuen URLs, nicht über Redirects.
• Tracking eingerichtet: Webanalyse-Code, Search-Console-Bestätigung, Conversion-Tracking — alle Tools sind für die neue Domain konfiguriert und getestet.
• Strukturierte Daten: Schema.org-Markup ist auf den wichtigsten Seiten vorhanden und validiert.
• SSL-Zertifikat: Für die Hauptdomain inklusive www- und Non-www-Variante gültig. Keine Mixed-Content-Warnungen.
• Wichtige Seiten manuell prüfen: Die zehn wichtigsten Money-Pages werden manuell aufgerufen und gegen die alte Version verglichen.

Jeder Punkt wird abgehakt und mit Zeit/Person dokumentiert. Wer den Check ohne Dokumentation macht, erinnert sich später nicht mehr, was wirklich geprüft wurde.

Schritt 6 + 7: Live-Schaltung und erste Stunden

Die eigentliche Live-Schaltung ist meist der unspektakulärste Teil des gesamten Relaunches — vorausgesetzt, die vorherigen Schritte sind sauber gemacht. Was am Live-Tag passiert:

Schritt 6: Switch in der Live-Stunde

1. Backup der alten Website ziehen: Vollständiges Backup vor der Umschaltung — als Fallback, falls etwas grundlegend schief geht.
2. DNS-Switch oder Code-Deploy: Je nach Setup wird der DNS-Eintrag auf den neuen Server gezeigt oder der neue Code auf die bestehende Domain deployed.
3. 301-Redirects aktivieren: Die Mapping-Tabelle wird in Server-Regeln umgesetzt — wenn das nicht schon vorher auf der Test-Umgebung gemacht wurde.
4. Indexierungs-Sperren entfernen: Falls noch aktiv, jetzt deaktivieren. Die robots.txt der Live-Domain erlaubt Indexierung.
5. Erste Funktions-Prüfung: Startseite, Top-Money- Pages und Kontaktformular werden manuell aufgerufen und getestet.

Schritt 7: Erste zwei Stunden nach Live

• Statuscode-Sweep: Die Mapping-Tabelle wird komplett durchgetestet — jede alte URL erreicht ihre korrekte neue Zieladresse mit Status 301?
• Neue Sitemap einreichen: Über die Search-Console wird die neue XML-Sitemap eingereicht. Beschleunigt das Neu-Crawling deutlich.
• Wichtigste URLs zur Indexierung anfordern: Über die Search-Console werden die Top-Money-Pages einzeln zur Indexierung angefordert.
• Tracking-Test: Auf der Live-Seite einen Testbesuch machen, in der Webanalyse prüfen, ob der Besuch erfasst wird.
• Erste Performance-Messung: Ladezeiten und Core Web Vitals der wichtigsten Seiten messen, um eine Baseline zu haben.

Schritt 8 + 9: Die ersten 14 Tage nach Live

Der eigentliche Relaunch-Erfolg entscheidet sich nicht am Live-Tag, sondern in den zwei Wochen danach. In dieser Zeit kommen die Suchmaschinen schrittweise auf der neuen Struktur an, finden Fehler, indexieren neu — und in dieser Zeit kann jeder übersehene Fehler noch ohne dauerhaften Schaden korrigiert werden.

Schritt 8: Tägliches Monitoring

In den ersten sieben Tagen werden täglich folgende Punkte geprüft:

• Rankings der Top-100-Keywords: Bewegung pro Tag protokollieren. Stabile Schwankungen sind normal, einseitige Abstürze nicht.
• Indexierungs-Status: Wie viele URLs sind in der Search Console als „indexiert" gemeldet? Wachsende Zahl ist gut, schrumpfende oder stagnierende Zahl ist Warnzeichen.
• Crawl-Fehler: Die Search Console meldet 404, Server-Fehler und Soft-404 — täglich durchsehen und beheben.
• Statuscodes der wichtigsten alten URLs: Stichproben aus der Mapping-Tabelle — kommt jede wirklich mit 301 an?
• Traffic-Vergleich: Webanalyse mit Vorwoche / Vorjahr vergleichen. Bei stärkerem Einbruch sofort Ursache suchen.

Schritt 9: Wochenweise Nachjustierung

Ab Tag 8 wird das Monitoring auf zwei bis drei Mal pro Woche reduziert, ab Tag 15 auf wöchentlich. Wenn nach vier Wochen die Rankings stabil sind, ist der Relaunch durch. Wenn nicht, ist jetzt der Zeitpunkt für ein gezieltes Audit — meist liegt die Ursache in einem der drei Klassiker: fehlerhafte Redirects, versehentliche Indexierungs-Sperre, oder ein eingebrochener Content-Block, der vorher Long-Tail-Traffic gebracht hat.

Wer den Relaunch in den jährlichen Website-Check überführt, hält den Bestand mit minimalem Aufwand sauber — und entdeckt Spät-Fehler, die im ersten Monat noch nicht sichtbar waren.

Häufige Fehler aus der Praxis

In Relaunch-Audits tauchen sechs Muster immer wieder auf — bei eigen-organisierten Projekten genauso wie bei eingekauften Agenturleistungen. Wer sie kennt, kann sie systematisch vermeiden.

Die Fehler 1 bis 3 sind systemisch — sie entstehen, weil Grundlagen fehlen. Die Fehler 4 bis 6 sind handwerklich — sie entstehen durch Hektik oder fehlende Routine. Beide Klassen lassen sich mit einem dokumentierten Prozess vollständig abstellen.