Website-Relaunch ohne Sichtbarkeitsverlust: Inventar, Mapping, Rückrollpunkt

Ein Relaunch verliert Sichtbarkeit, wenn das Design vor dem Inventar beginnt. Jede alte Adresse braucht eine bewusste Entscheidung — behalten, verbessern, zusammenführen oder weiterleiten.

Sie haben Jahre in Ihre Website gesteckt. Der Relaunch soll sie besser machen, nicht unsichtbar. In der Praxis passiert oft das Gegenteil: Die Anfragen brechen ein. Und hinterher weiß niemand genau, woran es lag.

Das lässt sich vermeiden. Nicht durch mehr Aufwand, sondern durch eine andere Reihenfolge. Dieser Leitfaden beschreibt sie so, dass Sie am Montag anfangen können. Die Abschnitte mit dem Hinweis Technische Umsetzung enthalten Werkzeugeinstellungen und Freigabekriterien. Wenn Sie den Relaunch steuern und nicht selbst durchführen, genügen Ihnen die Abnahmesätze im Kapitel Was Sie vertraglich festhalten sollten.

Was die Absicherung kostet — und was ein Einbruch kostet

Diese Rechnung brauchen Sie, bevor Sie in die Runde mit der Geschäftsführung gehen. Für eine Website mittlerer Größe — bis etwa tausend Adressen, gleiche Domain — rechnen wir mit drei bis fünf Personentagen für Inventar und Mapping. Dazu zwei Tage für die Tests vor der Umstellung und ein halber Tag je Woche in der achtwöchigen Beobachtung. Bei einem Domainwechsel kommen ein bis zwei Tage dazu.

Die Gegenrechnung füllen Sie mit Ihren eigenen Zahlen. Anfragen pro Monat × Abschlussquote × durchschnittlicher Auftragswert = Umsatz je Monat aus der Website. Ein Einbruch von dreißig Prozent über sechs Monate kostet davon knapp zwei Monatsumsätze. Rechnen Sie beides nebeneinander auf eine Seite — das ist die Folie, die die Diskussion beendet.

Posten	Aufwand	Ihre Zahl
Inventar, Bewertung, Mapping	3 bis 5 Personentage	___
Nullmessung und Tests vor der Umstellung	2 Personentage	___
Beobachtung Woche +1 bis +8	0,5 Personentage je Woche	___
Anfragen pro Monat aus der Website	—	___
Abschlussquote × Auftragswert	—	___
Verlust bei −30 % über 6 Monate	—	___

Zuerst klären: Strukturwechsel oder Domainwechsel

Das sind zwei verschiedene Projekte, und fast alle Fehleinschätzungen beim Aufwand entstehen daran, dass sie nicht getrennt werden. Klären Sie das in der ersten Sitzung.

	Gleiche Domain, neue Struktur	Neue Domain
Search Console	bestehende Property bleibt, kein Sonderschritt	Adressänderung im Tool, beide Properties vorher bestätigt
Voraussetzung	keine	funktioniert nur auf Domain-Ebene, nicht für Verzeichnisse
Weiterleitungen laufen	dauerhaft, mindestens bis kein Traffic mehr darüber kommt	nach Googles Empfehlung mindestens ein Jahr
Zusätzlich zu bedenken	interne Links, Sitemap	DNS und Wartezeit, E-Mail und MX, alte Domain nicht kündigen
Zusatzaufwand	—	1 bis 2 Personentage

Hier werden zwei Fristen regelmäßig verwechselt, und die Verwechslung kostet Sichtbarkeit. Die 180 Tage sind die Laufzeit des Werkzeugs: So lange hält Google die Verknüpfung beider Properties aufrecht und überträgt die Signale. Die Weiterleitungen selbst bleiben davon unberührt — Google empfiehlt für sie mindestens ein Jahr, weil externe Links, Lesezeichen und Verzeichniseinträge deutlich länger leben als die Signalübertragung. Wer die Regeln nach 181 Tagen abräumt, hat formal das Werkzeug bedient und praktisch alle externen Verweise entwertet.

Der Zeitplan: acht Wochen davor, acht Wochen danach

Ein Relaunch ist kein Termin, sondern ein Zeitraum. Diese Aufteilung hat sich in unseren Projekten bewährt. Sie verschiebt die riskanten Entscheidungen nach vorn.

Zeitpunkt	Was passiert	Wer führt
Woche −8	Inventar aus sechs Quellen, Bewertung je Seite, Nullmessung eingefroren	SEO und Fachabteilungen
Woche −6	Struktur und Mapping stehen, Freigabe durch Vertrieb	Projektleitung
Woche −4	Inhalte in der Vorschau, erster vollständiger Crawl	Redaktion und Technik
Woche −3	Wiederherstellung der Sicherung auf einem separaten Host getestet	Technik
Woche −2	Weiterleitungen gegen die Vorschau geprüft, Freigabekriterien erfüllt	Technik
Woche −1	Mapping eingefroren, Diff-Crawl gegen geänderte Ziele, DNS-Vorlaufzeit gesetzt, Rollen benannt	Projektleitung
Tag 0	Umstellung im Zeitfenster, Sofortprüfung binnen zwei Stunden	Technik
Woche +1 bis +8	Beobachtung gegen feste Schwellenwerte	SEO

Der Schritt in Woche −1 wird fast immer vergessen und kostet regelmäßig Adressen. Zwischen Mapping-Freigabe und Start ändert die Redaktion Seitentitel und damit Pfade. Ein Crawl der Vorschau gegen die Zielspalte des Mappings findet genau diese Abweichungen. Ohne ihn ist die in Woche −2 geprüfte Weiterleitungsliste am Tag der Umstellung veraltet.

Das Inventar: sechs Quellen, sechs Exporte

Die häufigste Ursache für Verluste ist ein unvollständiges Inventar. Wer nur das Hauptmenü abbildet, übersieht regelmäßig die Hälfte der Adressen. Jede Quelle findet andere Seiten — deshalb sechs Exporte und nicht einer.

Quelle	Werkzeug und Weg	Was nur hier auftaucht
Crawl der Live-Seite	Screaming Frog oder Sitebulb, Export „Internal — HTML“	verwaiste Unterseiten, alte Kampagnenziele
Alte XML-Sitemap	sitemap.xml und alle Unter-Sitemaps herunterladen	Adressen, die kein Crawl mehr findet, weil nichts mehr auf sie zeigt
Search Console	Search-Console-API, seitenweise abgerufen — nicht der CSV-Export	Seiten mit Impressionen ohne interne Verlinkung
Analytics	GA4 über BigQuery-Export oder Data API, 12 Monate	Seiten mit Direktzugriffen aus E-Mails und Angeboten
Backlinkdaten	Ahrefs, Semrush oder Search-Console-Linkbericht	Adressen mit externen Verweisen, oft sehr alte
Serverprotokoll	Access-Log der letzten 90 Tage, nach Statuscode gefiltert	PDF-Downloads, Bilder in Fremdseiten, Bot-Pfade

Technische Umsetzung. Zwei Fallen bei den Exporten, die beide genau die Seiten verschlucken, für die die Quelle da ist. Der Download aus der Search-Console-Oberfläche ist auf tausend Zeilen gekürzt. Bei dreitausend Adressen fehlt damit der gesamte lange Schwanz. Nutzen Sie die Search-Console-API mit rowLimit 25.000 und startRow zum Blättern, oder den Massenexport nach BigQuery. Beim Blättern ist bei 100.000 Zeilen Schluss — wer mehr braucht, segmentiert nach Datum. In GA4 kippen bei vielen Adressen die schwachen Pfade im Standardbericht in die Sammelzeile (other). Nehmen Sie den BigQuery-Export, die Data API oder ersatzweise eine gefilterte Exploration.

Technische Umsetzung. Vor dem Zusammenführen wird normalisiert, sonst verlieren Sie genau die Adressen, für die Quelle 5 und 6 überhaupt da sind. Der Crawl liefert nur die kanonische Schreibweise; in Backlinks und Serverprotokoll stehen daneben /Leistungen/SEO, dieselbe Adresse ohne Schrägstrich am Ende und alte Parameterformen wie /index.php?p=42. Vereinheitlichen Sie Groß- und Kleinschreibung und den Schrägstrich am Ende für den Abgleich, behalten Sie die Varianten aber als eigene Quellzeilen. Für Schreibweise und Schrägstrich kommt eine allgemeine Regel vor die Einzelregeln — und zwar so, dass sie das Ziel in einem Sprung erreicht und nicht als zweite Stufe die Ein-Sprung-Regel bricht. Die naheliegende Umsetzung ist genau die verbotene: Eine eigene Regel mit [R=301,L] für Kleinschreibung erzeugt exakt die Zwei-Sprung-Kette. Der saubere Weg führt über die Zuordnungsdatei, die Sie ohnehin aus dem Mapping erzeugen — schreiben Sie die Schlüssel gleich in allen Varianten hinein, klein geschrieben sowie mit und ohne Schrägstrich am Ende. Dann genügt ein Nachschlagen und ein Sprung, ganz ohne vorgelagerte Regel. Bei Apache lässt sich die Kleinschreibung alternativ mit ${tolower:$1} im Zugriff auf die Zuordnungsdatei erledigen, ohne extern weiterzuleiten; nginx kennt in map keine Kleinschreibung und braucht dort Schlüssel mit ~*.

Führen Sie die Exporte in einer Tabelle zusammen. Rechnen Sie mit einem halben bis ganzen Arbeitstag. Bei Websites über tausend Seiten eher mit zwei.

Bewerten Sie danach jede Adresse. Eine Seite ohne Besucher kann trotzdem im Angebotsprozess verlinkt sein. Fragen Sie den Vertrieb, bevor Sie Inhalte streichen.

Die Nullmessung: wogegen Sie später vergleichen

Jede Schwelle in diesem Leitfaden ist wertlos, wenn in Woche +3 niemand sagen kann, wie die Zahlen vorher aussahen. Die Search Console hält ihre Daten rollierend sechzehn Monate — die Zahlen von heute sind in anderthalb Jahren weg. Frieren Sie sie ein, bevor Sie umstellen, und legen Sie die Dateien ins Projektverzeichnis.

• Search Console, Leistung je Seite, 16 Monate — über die API, nicht als CSV. Ablage als baseline-gsc-seiten-JJJJ-MM-TT.csv.
• GA4, Einstiegsseiten und Anfragen, 12 Monate — als baseline-ga4-einstiege-JJJJ-MM-TT.csv.
• Anfragen je Monat aus dem Kundenmanagement, 24 Monate, damit Saisonalität sichtbar wird.
• Aktuelle Indexierungszahl aus dem Bericht Seitenindexierung, gefiltert auf die eingereichte Sitemap.
• Core Web Vitals aus dem gleichnamigen Bericht — mit dem Hinweis im Dateinamen, dass der Bericht ein rollierendes 28-Tage-Fenster zeigt.

Legen Sie außerdem eine kurze Tabelle nur für Ihre Geldseiten an: Adresse, Klicks im Vormonat, Klicks im Vorjahresmonat, Anfragen im Vormonat. Diese eine Seite ist das Dokument, das Sie in der Krisensitzung aufschlagen.

Geldseite	Klicks Vormonat	Klicks Vorjahresmonat	Anfragen Vormonat
/leistungen/seo-beratung/	340	295	6

Wogegen wird verglichen. Immer gegen zwei Zeiträume gleichzeitig: gegen die vierzehn Tage vor der Umstellung und gegen denselben Zeitraum im Vorjahr. Nur der Vorjahresvergleich fängt Saisonalität ab. Wer im September gegen die Werksferien im August vergleicht, sieht einen Erfolg, wo keiner ist — und umgekehrt.

Das Mapping-Dokument: eine Zeile je Adresse

Dieses Dokument ist das Herzstück des Projekts. Es entscheidet über jede alte Adresse und hält fest, wer das wann entschieden hat. Legen Sie es mit diesen Spalten an. Und behandeln Sie es als einzige Quelle: Die Weiterleitungsregeln auf dem Server werden später aus genau dieser Datei erzeugt, nicht daneben gepflegt.

Spalte	Inhalt	Beispiel
Alte Adresse	vollständiger Pfad	/leistungen/seo-beratung/
Statuscode	aus dem Crawl	200
Klicks 12 Monate	Search Console	340
Verweisende Domains	Backlinkwerkzeug	7
Geschäftswert	hoch, mittel, gering — vom Vertrieb bestätigt	hoch
Entscheidung	behalten, verbessern, zusammenführen, weiterleiten, entfallen	zusammenführen
Ziel	genau eine neue Adresse	/sichtbarkeit/seo/
Zielstatus	301, oder 410 bei „entfallen“	301
Begründung	ein Satz, warum dieses Ziel	gleiche Suchintention, stärkere Seite
Geprüft am / von	Datum und Name	14.03. / K. Taron

Die Entscheidung folgt einer einfachen Regel. Bei mehr als fünfzig Klicks im Jahr oder mindestens einer verweisenden Domain wird die Adresse nicht ersatzlos gestrichen. Sie wird behalten oder auf ein fachlich passendes Ziel geführt.

Für „entfallen“ braucht es eine bewusste Entscheidung zwischen zwei Codes. Eine 404 sagt „nicht gefunden“ und wird über Monate erneut abgefragt. Eine 410 sagt „dauerhaft entfernt“ und führt schneller zur Entfernung aus dem Index. Nehmen Sie 410 für Inhalte, die wirklich nie wiederkommen, und 404 im Zweifel.

Behalten Sie bewährte Pfade, wenn kein Grund dagegen spricht. Ein neues Design verlangt keine neuen Adressen. Wer beides gleichzeitig ändert, kann Ursachen später nicht mehr trennen.

Weiterleitungen: ein Sprung, kein Umweg

Die Regel ist strenger, als sie meistens formuliert wird: Jede alte Adresse erreicht ihr Ziel in genau einem Sprung. Nicht in zwei. Zwei Sprünge sind kein kleineres Problem als drei. Sie erschweren die Fehlersuche, verlieren unterwegs Parameter und kosten Ladezeit — auf mobilen Geräten am spürbarsten.

Technische Umsetzung. Die häufigste Kette entsteht ungewollt und ist in fast jeder Standardkonfiguration angelegt: http://alt/pfad springt auf https://alt/pfad (Kanonisierung von Protokoll und www), und erst diese Adresse springt auf das neue Ziel. Die Pfadregel muss deshalb Host und Pfad in einem Schritt final umschreiben, statt sich auf die vorgelagerte Regel zu verlassen.

Welcher Code, und wann. Dauerhaft verschobene Inhalte bekommen am Ende eine 301. In den ersten vierundzwanzig bis achtundvierzig Stunden ist eine 302 die sicherere Wahl: Browser merken sich eine 301 dauerhaft. Wer um 22 Uhr eine 301 ausliefert und um 23 Uhr zurückrollen muss, erreicht damit alle Besucher aus dieser Stunde nicht mehr — deren Browser springt weiter auf die tote Adresse. Erst nach der Freigabe wird auf 301 umgestellt.

Die Zwischenspeicher-Angabe auf den Weiterleitungen wird dazu in drei Stufen gefahren. Eine feste Stunde durchgängig zu setzen wäre widersprüchlich: Sie würde im Rückroll-Fenster genau die Falle wieder aufstellen, die die 302 vermeiden soll.

Zeitraum	Statuscode	Cache-Control
Rückroll-Fenster (0 bis +2 Stunden)	302	no-store
Nach der Freigabe bis +48 Stunden	302	max-age=3600
Ab +48 Stunden, dauerhaft	301	Voreinstellung

Der Wechsel von 302 auf 301 hat einen Termin und einen Verantwortlichen — siehe die Zeile +48 Stunden in der Tabelle zum Tag der Umstellung. Ohne benannten Besitzer bleibt er liegen, und die Website fährt dauerhaft auf dem schwächeren Signal.

Parameter müssen die Weiterleitung überleben. Ohne QSA bei Apache beziehungsweise $is_args$args bei nginx verliert jede Regel die angehängten Parameter. Damit landen ab Tag 0 alle laufenden Kampagnen unter „direct“, und in Woche +2 diskutiert das Team über einen Sichtbarkeitseinbruch, der in Wahrheit ein Zuordnungsfehler ist.

Ab etwa fünfhundert Regeln gehören diese nicht mehr als Einzeleinträge in die Serverkonfiguration und schon gar nicht in ein Plugin, das bei jeder Fehlerseite die Datenbank befragt. Nutzen Sie eine Zuordnungsdatei — RewriteMap bei Apache, einen map-Block bei nginx — und erzeugen Sie diese Datei aus dem Mapping-Dokument. Musterregeln mit Platzhaltern nur für echte Muster wie Kategoriepfade, niemals für Einzelseiten.

Vor der Umstellung: die Freigabekriterien

„Weiterleitungen getestet“ ist kein Prüfschritt, sondern ein Satz aus einem Angebot. Ein Prüfschritt hat ein Werkzeug, eine Einstellung und ein Kriterium, an dem er scheitern kann. Diese sechs müssen erfüllt sein, bevor freigegeben wird.

1. Die Weiterleitungsliste ist vollständig geprüft

Kriterium: hundert Prozent der Zeilen mit einem Sprung, Endstatus 200, Endadresse gleich der Zielspalte des Mappings. Nicht neunundneunzig Prozent — die fehlende Zeile ist erfahrungsgemäß eine Geldseite.

Technische Umsetzung. Im Crawler in den Listenmodus wechseln und die Spalte „Alte Adresse“ des Mappings als Liste laden. Weiterleitungen dauerhaft folgen lassen, die Zugangsdaten der Vorschauumgebung hinterlegen und den Zielhost über einen Hosts-Eintrag auf die Vorschau biegen. Danach den Bericht über Weiterleitungsketten exportieren und die Spalten Anzahl der Sprünge, Endadresse und Endstatus gegen die Zielspalte des Mappings abgleichen.

Denselben Abgleich zusätzlich als kurzes Skript mit curl -sIL über dieselbe Datei laufen lassen, eingebunden in die Auslieferungskette, damit ein späterer Stand die geprüfte Liste nicht unbemerkt bricht. Drei Stichproben gehören in denselben Lauf: eine Adresse mit angehängtem ?utm_source=test muss den Parameter am Ziel wiederfinden; eine garantiert nicht existierende Adresse muss im Statuscode 404 liefern und nicht bloß optisch wie eine Fehlerseite aussehen; und eine Adresse in abweichender Schreibweise muss dasselbe Ziel in einem Sprung erreichen.

Diese Freigabe verfällt bei jeder Änderung am Mapping. Findet der Diff-Crawl in Woche −1 geänderte Ziele, ist die Abnahme aus Woche −2 ungültig und der Listenlauf wird vollständig wiederholt. Eine Freigabe, die vor der letzten Änderung erteilt wurde, ist keine.

2. Interne Links zeigen auf die Ziele, nicht durch die Weiterleitung

Ein Crawl der Vorschau darf keinen einzigen internen Link mit Status 301 zurückgeben. Andernfalls verdeckt die Weiterleitungsschicht dauerhaft eine falsch verlinkte Navigation — und beim nächsten Umbau fällt genau das auf die Füße. Kriterium: null interne Weiterleitungen.

3. Kein Rest aus der Vorschau

Das ist der teuerste Einzelfehler beim Relaunch, und er hat drei Erscheinungsformen: ein noindex im Seitenkopf, ein Disallow: / in der robots.txt aus der Testumgebung, und — am schwersten zu finden — ein X-Robots-Tag: noindex im Antwortkopf von Server oder Auslieferungsnetz. Die dritte Form sieht kein Crawl, der nur den Quelltext prüft. Der Crawler muss auf Antwortköpfe eingestellt sein, und die robots.txt der Vorschau wird ausdrücklich mit der Live-Fassung verglichen.

Wirksamer als jede Erkennung ist allerdings, den Fehler gar nicht erst möglich zu machen. Eine Vorschauumgebung wird über eine Zugangssperre geschützt — Passwortabfrage oder Freigabe einzelner Adressbereiche —, nicht über noindex und robots.txt. Was gar nicht abrufbar ist, kann nicht indexiert werden, und es existiert keine Sperre, die beim Umzug mitwandern könnte. Der teuerste Einzelfehler beim Relaunch entsteht praktisch ausschließlich in Projekten, die ihre Testumgebung mit Suchmaschinen-Anweisungen statt mit einem Passwort schützen.

4. Die Messung steht vor dem Start

Zählpunkte, Einwilligungsbanner und Formularziele werden mit echten Testfällen geprüft, nicht mit einem Blick in die Oberfläche. Prüfen Sie ausdrücklich den Fall, dass die Einwilligung abgelehnt wird — dort brechen Messungen still ab.

5. Formulare kommen an

Jedes Formular wird abgeschickt und der Eingang im Postfach oder im Kundenmanagement bestätigt. Mit echter Absenderadresse, nicht mit einer Testadresse, die der Spamfilter anders behandelt.

6. Sprachzuordnung stimmt

Bei Seiten für Deutschland, Österreich und die Schweiz ist der typische Relaunch-Fehler, dass die hreflang-Angaben nach dem Umzug noch auf die alten Adressen zeigen. Zu prüfen sind vier Punkte: Jede Sprachfassung verweist kanonisch auf sich selbst, alle Angaben verweisen wechselseitig aufeinander, es gibt eine x-default-Fassung, und keine Länderfassung wird auf eine andere kanonisiert.

Was Sie vertraglich festhalten sollten

Wenn Sie den Relaunch steuern und nicht selbst durchführen, ist das der Abschnitt, der die vorigen Kapitel für Sie brauchbar macht. Fünf Sätze zum Übernehmen in Angebot oder Protokoll — sie verwandeln „wurde geprüft“ in etwas Nachweisbares.

• Die Weiterleitungsliste wird als Datei mit den Spalten alte Adresse, Statuscode, Ziel, Begründung geliefert und vom Auftraggeber freigegeben. Freigabetermin: Woche −6.
• Weiterleitungen mit mehr als einem Sprung sowie Weiterleitungen auf die Startseite gelten als Mangel und werden binnen fünf Werktagen ohne zusätzliche Kosten behoben.
• Ein vollständiger Crawl der Vorschauumgebung wird als Bericht übergeben. Die Freigabe erfolgt gegen den Bericht, nicht gegen eine mündliche Bestätigung.
• Vor der Umstellung werden die Vergleichsdaten aus Search Console, Analytics und Kundenmanagement exportiert und im Projektverzeichnis abgelegt.
• Die Weiterleitungen werden 48 Stunden nach der Freigabe von 302 auf 301 umgestellt und die Stichprobe wiederholt. Der Termin wird im Protokoll bestätigt.

Der Tag der Umstellung: wer entscheidet was

Ein Relaunch scheitert selten an der Technik. Er scheitert daran, dass im Zwischenfall niemand entscheidungsbefugt ist. Legen Sie das vorher schriftlich fest — mit Namen, nicht mit Rollenbezeichnungen.

Zeitfenster	Aufgabe	Rolle
−48 Stunden	DNS-Vorlaufzeit auf 300 Sekunden gesenkt	Technik
−2 Stunden	Sicherung von Datenbank und Dateien (Wiederherstellung wurde in Woche −3 getestet)	Technik
0	Umstellung, Weiterleitungsregeln aktiv, alle Zwischenspeicher geleert	Technik
+15 Minuten	Listenlauf über die Mapping-Datei, Geldseiten zuerst; Vollcrawl parallel im Hintergrund	SEO
+30 Minuten	Neue Sitemap eingereicht; alte Sitemap bleibt erreichbar und eingereicht, bis das Serverprotokoll keine Googlebot-Zugriffe auf die alten Adressen mehr zeigt (in der Regel vier bis sechs Wochen)	Technik
+1 Stunde	Alle Formulare abgeschickt und Eingang bestätigt	Marketing
+2 Stunden	Freigabe oder Rückabwicklung	Projektleitung
+48 Stunden	Weiterleitungen von 302 auf 301 umgestellt, Stichprobe wiederholt	Technik

Die letzte Spalte wird vor dem Start überschrieben: Name und Telefonnummer statt Rollenbezeichnung. Eine Rolle ist um 22 Uhr nicht erreichbar, eine Nummer schon.

Zwischenspeicher sind Ursache Nummer eins für den Satz „die Weiterleitungen funktionieren nicht“. Nach dem Umschalten werden Seitenzwischenspeicher und Auslieferungsnetz vollständig geleert, und es wird ausdrücklich geprüft, dass die Weiterleitungsantworten nicht mit alten Zwischenspeicher-Angaben ausgeliefert werden.

Die Rückabwicklung braucht ein messbares Kriterium. Gemessen wird am Listenlauf aus Minute 15, nicht am Gefühl. Zurückgesetzt wird, wenn ein Formular nicht ankommt, die Startseite nicht erreichbar ist oder eine einzige Geldseite ins Leere läuft. Der oft genannte Schwellenwert von fünf Prozent ist für den Rest der Adressen richtig, für die Geldseiten ist er zu lasch.

Und die ehrliche Einschränkung: Ein sauberer Rückroll ist nur so lange eine Datenbankfrage, wie noch keine Anfragen und Bestellungen eingegangen sind. Legen Sie deshalb vorher fest, bis wann zurückgerollt wird und ab wann nur noch nachgebessert. In unseren Projekten ist das Ende des Zwei-Stunden-Fensters diese Grenze. Für Anfragen, die währenddessen eingegangen sind, wird das Postfach gesondert geprüft, bevor die Sicherung eingespielt wird.

Die ersten acht Wochen: Schwellenwerte statt Bauchgefühl

Nach einem Relaunch schwanken die Zahlen immer. Ohne vorher festgelegte Schwellen wird jede Schwankung zum Anlass für hektische Einzeländerungen. Diese Werte haben sich als Auslöser bewährt.

Beobachtung	Normal	Ursachenanalyse ab	Eingriff ab
Organische Klicks gesamt	−10 bis −15 % für 2 bis 4 Wochen	−20 % über 14 Tage	−30 % über 14 Tage
Klicks auf Geldseiten	kaum Bewegung	−15 % über 7 Tage	−25 % über 7 Tage
Indexierte Seiten	Anpassung nach oben oder unten	−10 % gegenüber Nullmessung	Kernseiten nicht indexiert
404 im Serverprotokoll	einzelne alte Bot-Pfade	neue Fehler auf Seiten mit Klicks	jede Adresse aus dem Mapping
Anfragen über Formular	unverändert	−20 % über 14 Tage	Ausfall einzelner Formulare

Als Geldseiten gelten die zehn bis zwanzig Seiten, über die Anfragen entstehen. Diese Liste stammt aus dem Inventar und wird vorher festgelegt. Sie werden täglich geprüft, alles andere im vereinbarten Prüfrhythmus.

Womit gemessen wird — und wann nicht. Die Search Console liefert die letzten zwei bis drei Tage unvollständig. Wer täglich auf ein Sieben-Tage-Fenster schaut, das zu einem Drittel aus Teildaten besteht, löst planmäßig Fehlalarme aus. Also genau den Aktionismus, den die Tabelle verhindern soll. Vergleichen Sie deshalb immer ein um drei Tage versetztes Fenster, und erwarten Sie in den ersten drei Tagen nach der Umstellung dort überhaupt keine belastbaren Zahlen.

Der einzige Frühindikator, der am selben Tag funktioniert, ist das Serverprotokoll. Werten Sie ab Tag 0 täglich aus: Anfragen des Googlebots auf die alte Adressmenge, Verteilung der Statuscodes, Anteil 404 und 5xx. Jede 404 auf einer Adresse aus dem Mapping ist ein Sofortfall — unabhängig davon, wie viele Klicks sie hatte, denn sie beweist einen Fehler in der Regelmenge.

Die Indexierung messen Sie im Bericht Seitenindexierung, gefiltert auf die eingereichte Sitemap — nicht mit einer site:-Abfrage, die nur Rauschen liefert. Auch dieser Bericht hat mehrere Tage Nachlauf. Für die tägliche Prüfung der Geldseiten eignet sich die URL-Prüfungs-API, die je Property zweitausend Abfragen am Tag zulässt. Und der Bericht zu den Core Web Vitals zeigt ein rollierendes 28-Tage-Fenster: In den ersten vier Wochen nach der Umstellung mischt er alte und neue Seiten und ist nicht auswertbar.

Halten Sie jede Änderung nach dem Start in einem kurzen Protokoll fest: Datum, Vermutung, Maßnahme, Ergebnis. Ohne dieses Protokoll lässt sich nach acht Wochen nicht sagen, was gewirkt hat.

Fünf Fehler, die wir regelmäßig sehen

• Das Inventar entsteht aus dem Hauptmenü statt aus sechs Datenquellen. Alles, was nicht verlinkt ist, verschwindet unbemerkt.
• Alle alten Adressen werden pauschal auf die Startseite geführt. Google stuft solche Weiterleitungen als „Soft 404“ ein und ignoriert sie — der Begriff taucht später genau so in der Search Console auf.
• Die Messung wird erst nach dem Start eingerichtet. Damit fehlt genau der Vergleichszeitraum, den Sie später brauchen.
• Die Sperre der Vorschauumgebung wandert mit auf die Live-Seite. Die Website verschwindet innerhalb weniger Tage aus dem Index.
• Die Weiterleitungsliste wird in Woche −2 geprüft und danach nicht mehr angefasst, obwohl die Redaktion bis Tag 0 weiter an Pfaden arbeitet.

Was im DACH-Raum zusätzlich zu prüfen ist

Ein neues System bedeutet neue Datenflüsse. Impressum, Datenschutzerklärung, Einwilligungsbanner und die Erklärung zur Barrierefreiheit gehören auf die Prüfliste. Eingebettete Dienste ändern häufig ihren Anbieter, ohne dass es auffällt.

Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz. Es betrifft Angebote im Verbrauchergeschäft, mit einer Ausnahme für Kleinstunternehmen bei Dienstleistungen. Ein Relaunch ist der günstigste Zeitpunkt, das mitzuerledigen.

Prüffragen vor der Freigabe

• Stammt unser Inventar aus sechs Quellen oder aus der Navigation?
• Sind die Vergleichsdaten exportiert und abgelegt — mit Vorjahreszeitraum?
• Hat jede alte Adresse ein Ziel, einen Sprung und eine schriftliche Begründung?
• Kennen wir unsere zehn Geldseiten namentlich?
• Wer darf am Tag der Umstellung die Rückabwicklung auslösen, und bis wann?
• Wer stellt nach 48 Stunden von 302 auf 301 um, und wo wird das bestätigt?

Häufige Fragen

Wir haben schon umgestellt und die Anfragen brechen ein. Was jetzt?

Erstellen Sie zuerst das Inventar nachträglich — mit denselben sechs Quellen, Zeitraum vor der Umstellung. Vergleichen Sie es mit dem heutigen Crawl. Die Lücke zeigt Ihnen die verlorenen Adressen, und die meisten davon lassen sich mit Weiterleitungen zurückholen. Parallel das Serverprotokoll der letzten Tage nach 404 filtern: Das findet die Fälle schneller als jede Auswertung in der Search Console.

Wie lange schwanken die Zahlen nach einem Relaunch?

Bei sauberer Vorbereitung zwei bis vier Wochen, bei größeren Strukturänderungen bis zu acht. Entscheidend ist nicht die Dauer, sondern ob die Kurve nach der dritten Woche wieder steigt. Fällt sie weiter, liegt ein Fehler vor und kein Nachlauf.

Müssen bei neuem Design alle Adressen geändert werden?

Nein. Design und Adressstruktur sind getrennte Entscheidungen. Jede geänderte Adresse kostet einen Teil der aufgebauten Stärke — ändern Sie nur, wenn die alte Struktur inhaltlich falsch war.

301 oder 302 — was ist der Unterschied in der Praxis?

Beide werden von Suchmaschinen als starkes Signal für die maßgebliche Adresse gewertet; die 301 ist das deutlichere. Der praktische Unterschied liegt im Browser: Eine 301 wird dauerhaft gemerkt, eine 302 nicht. Deshalb die ersten ein bis zwei Tage mit 302 fahren, damit ein Rückroll für alle Besucher wirksam bleibt, und danach auf 301 umstellen.

Wir wechseln auch die Domain. Was ändert sich?

Beide Properties müssen in der Search Console bestätigt sein, dann wird die Adressänderung gemeldet — das Werkzeug arbeitet ausschließlich auf Domain-Ebene, für einzelne Verzeichnisse gibt es keine Entsprechung. Google hält die Verknüpfung 180 Tage aufrecht. Die Weiterleitungen selbst laufen deutlich länger: Google empfiehlt mindestens ein Jahr, und darüber hinaus, solange Traffic über sie kommt. Dazu kommen DNS-Vorlaufzeit, E-Mail-Einträge und die Regel, die alte Domain nicht zu kündigen.

Quellen und Vertiefung

• Google Search Central: Weiterleitungen und die Google Suche
• Google Search Central: Websiteumzug mit Adressänderung
• Search-Console-Hilfe: Tool zur Adressänderung — Voraussetzungen und 180-Tage-Frist
• Search-Console-Hilfe: Datenexport aus Berichten — Begrenzung auf 1.000 Zeilen
• Search-Console-API: Nutzungsgrenzen, unter anderem 2.000 URL-Prüfungen je Tag und Property
• Barrierefreiheitsstärkungsgesetz — Text und Geltungsbereich

Passende nächste Schritte

Wer die Umsetzung übernimmt, findet die technische Seite unter Webentwicklung. Wer vor allem die Sichtbarkeit absichern will, unter SEO.