Website Relaunch SEO: Die Checkliste für 301-Weiterleitungen

Website Relaunch SEO entscheidet sich vor dem Go-live: Eine URL-Inventur aus der Search Console, eine dokumentierte 301-Redirect-Matrix und eine Launch-Tag-Checkliste müssen vorliegen, bevor die neue Website live geht. Ein Relaunch ist kein Thema für die letzten zwei Tage vor dem Launch, sondern Teil eines Migrationsplans mit vier bis sechs Wochen Vorlauf. In diesem Beitrag erhältst du die konkrete Website Migration Checkliste zum Abhaken, eine kopierbare Redirect-Matrix, die fünf häufigsten Fehler und ein 14-tägiges Monitoring mit klaren Notfallschwellen. So bleibt deine Sichtbarkeit auch dann erhalten, wenn sich URLs, Technik und Inhalte beim Relaunch ändern.

Seit über 20 Jahren arbeite ich zwischen Medien, Fotografie und Webdesign; seit 2008 begleite ich inhabergeführte Betriebe in Bozen und im DACH-Raum in genau der Phase, in der ein Relaunch die bisherige Sichtbarkeit gefährden kann. Aus dieser Praxis gilt: Der Relaunch ohne Rankingverlust ist kein Glücksspiel, sondern ein dokumentierter Prozess. Wer die alte URL-Liste, die Baseline-Werte und die Weiterleitungslogik schriftlich vorliegen hat, kann Sichtbarkeitsverluste früh erkennen und begrenzen.

Website Relaunch SEO: Warum ein Relaunch ohne Rankingverlust planbar ist

Google überträgt bei einer dauerhaften Weiterleitung in der Regel die Signale der alten Ressource auf die neue URL. Das setzt zwei Bedingungen voraus: Die Weiterleitung ist technisch korrekt gesetzt, und die Inhalte bleiben weitgehend erhalten. Wichtig ist außerdem die realistische Zeitrechnung: Die Verarbeitung einer großen Migration kann laut der Google-Dokumentation mehrere Tage bis Wochen dauern. Ein Relaunch am Freitagnachmittag verlängert diese Phase zusätzlich und ist deshalb keine Optimierung, sondern ein Risiko.

Die Search-Central-Dokumentation zu Site Moves empfiehlt, die bestehende URL-Struktur möglichst stabil zu halten und jede Änderung einzeln zu dokumentieren. Das bedeutet nicht, dass jede neue URL ein Fehler ist. Jede Änderung braucht einen dokumentierten Grund, eine eindeutige Ziel-URL und eine gemessene Baseline.

Website Relaunch SEO ist damit im Kern ein Prozess aus Inventur, Mapping, Launch und Monitoring – keine technische Einmalaufgabe am Launch-Tag.

Ein Relaunch verliert dann kein Ranking, wenn am Tag des Go-live für jede alte URL nachweisbar feststeht, wohin sie zeigt – und wenn du zwei Wochen lang misst, ob die Signale tatsächlich übergehen.

Hinzu kommt eine zweite Entwicklung: Sichtbarkeit verteilt sich zunehmend auch auf KI-Antworten. Für deinen Betrieb bedeutet das: Eine stabile URL- und Inhaltsstruktur erleichtert nicht nur die Zuordnung in klassischen Suchergebnissen, sondern auch die Aufnahme durch Sprachmodelle und Agenten. Eine sauber geplante Migration behandelt beide Zugriffswegse.

Schritt 1: URL-Inventur und Baseline aus der Search Console

Alles beginnt mit einer Bestandsaufnahme, die nichts mit Bauchgefühl zu tun hat. Ich arbeite dabei mit vier Quellen, die du kombinierst:

• Search Console: Der Performance-Bericht über die letzten 16 Monate liefert die tatsächlich sichtbaren URLs, Positionen, Impressionen und Klicks. Diese Daten bilden deine Baseline.
• Analytics: Die Einstiegsseiten zeigen, welche URLs intern verlinkt sind, auch wenn sie in der Search Console nicht auftauchen.
• Sitemap und CMS-Export: Diese Quellen listen alle je existierten URLs auf, auch die ohne messbare Sichtbarkeit.
• Server-Logs: Die Logs zeigen, welche alten URLs weiterhin regelmäßig angefragt werden – auch solche, die im Menü nicht mehr auftauchen.

Für jede URL dokumentierst du in einer Inventarliste oder CSV-Datei: alte URL, neue URL, Position, Impressionen, Klickrate, Sprache, Priorität, Status. Priorität A erhält jede Seite, die in den letzten zwölf Monaten Klicks oder eine Position unter 20 erzielt hat. Diese Seiten bilden dein eigentliches Vermögen; sie müssen nach dem Relaunch messbar identisch funktionieren.

Was eine URL für die Indexierung bedeutet und wie du sie sauber dokumentierst, habe ich im Glossar zum Thema URL zusammengestellt. Wer die technische Seite einmal sauber verstanden hat, arbeitet beim Relaunch schneller.

Zusätzlich zum klassischen SEO-Datenbestand legst du eine KI-Pfadliste an: Welche Dateien und Endpunkte liefern Inhalte an Assistenten aus – typischerweise llms.txt, brand.txt, ai.json, maschinenlesbare Sitemap-Dateien und Markdown-Fassungen. Diese Pfade gehören in die Redirect-Matrix, sonst erhalten KI-Systeme nach dem Umzug keine gültige Antwort. Details dazu habe ich im Beitrag zu Website-Markdown für KMU beschrieben.

Die fünf häufigsten Relaunch-Fehler: Symptom, Ursache, Gegenmaßnahme

Diese fünf Punkte tauchen in meinen Projekten immer dann auf, wenn Rankings nach dem Launch einbrechen. Die Reihenfolge entspricht meiner Häufigkeitsliste aus der Praxis.

1. Geänderte URL-Struktur ohne Weiterleitung

• Symptom: Die Startseite rankt weiter, während Unterseiten aus den Suchergebnissen verschwinden.
• Ursache: Die Navigation wurde neu aufgebaut, die alten Pfade wurden nicht in eine 301-Redirect-Matrix überführt.
• Gegenmaßnahme: Jede alte URL aus der Inventur erhält genau eine Ziel-URL. Eine pauschale Umleitung auf die Startseite ist keine Lösung.

2. Versehentlich gesetzte noindex-Tags

• Symptom: Die neue Website ist erreichbar, in der Search Console aber als „vom Index ausgeschlossen“ markiert.
• Ursache: Eine Staging- oder Testumgebung wird live geschaltet, oder das CMS setzt im Auslieferungsmodus automatisch noindex. Ein häufiger Fall: Ein X-Robots-Tag im HTTP-Header statt eines Meta-Tags, der bei jedem Request neu gesetzt wird.
• Gegenmaßnahme: Vor dem Go-live den Response-Header der Startseite und drei Unterseiten prüfen. Der Detailweg über Meta-Robots, robots.txt und llms.txt ist in Meta-Robots, robots.txt und llms.txt richtig einordnen beschrieben.

3. Fehlerhafte hreflang-Verknüpfungen bei DE/IT-Seiten

• Symptom: Die deutsche und die italienische Version konkurrieren um dieselbe Seite, oder eine Sprachversion fehlt in den Ergebnissen.
• Ursache: Die Verweise sind nicht reziprok, oder eine Sprachversion verweist nicht auf sich selbst. Google ignoriert eine unvollständige Auszeichnung.
• Gegenmaßnahme: Jede Sprachversion listet sich selbst und alle übrigen Versionen auf, dazu kommt x-default für eine Sprachauswahl oder eine neutrale Fallback-Seite. Details im Beitrag Mehrsprachige Website SEO richtig planen.

4. Verlorene Schema.org-Daten

• Symptom: Rich Results verschwinden, KI-Assistenten kennen deine Leistungen oder deine Adresse nicht mehr.
• Ursache: Die strukturierten Daten waren im alten Theme eingebaut und wurden beim Neuaufbau nicht übernommen.
• Gegenmaßnahme: Vor dem Launch ein JSON-LD-Inventar erstellen: Welche Typen (Organization, LocalBusiness, Article, Service) waren auf welchen Seiten vorhanden? Die Prüfung im Detail zeigt Schema Validierung für KMU.

5. Nicht angepasste Canonical-Tags

• Symptom: Google indexiert eine alte oder eine duplizierte Variante statt der gewünschten Seite.
• Ursache: Das Canonical-Tag zeigt noch auf die alte Domain oder auf eine Parameter-Variante, die nicht mehr existiert.
• Gegenmaßnahme: Jede neue Seite erhält ein absolutes, selbstreferenzierendes Canonical ohne Parameter. Kein Canonical auf eine Weiterleitung.

301-Weiterleitungen beim Relaunch: 301, 302 und 410 richtig unterscheiden

Eine 301-Weiterleitung signalisiert Google, dass die Ressource dauerhaft an eine neue Adresse verschoben wurde. Die Verwechslung der Statuscodes gehört zu den Hauptursachen für Rankingverluste. Die Zuordnung folgt drei klaren Regeln:

• 301 – dauerhafte Umleitung: Die alte Adresse ist endgültig weg, die neue ist der einzige gültige Ort. Das ist der Standard für alle URLs aus deiner Inventur, die im Relaunch eine Entsprechung haben.
• 302 – temporäre Umleitung: Der Inhalt ist vorübergehend woanders, etwa bei Aktionen, Kampagnen-Landingpages oder Testaufbauten. Google wertet 302 als temporär; Signale werden weniger zuverlässig übertragen als bei einer 301-Weiterleitung.
• 410 – Inhalt entfernt: Die Seite existiert nicht mehr und wird nicht wiederhergestellt. Für alte Kampagnen, abgelaufene Aktionen oder Testseiten ohne Ersatz ist 410 die passende Antwort. Der Server signalisiert damit einen dauerhaften Entzug, statt auf die Startseite umzuleiten.

Daraus folgt die Grundregel: 301 für dauerhaft, 302 für vorübergehend, 410 für endgültig entfernt ohne Ersatz. Eine pauschale Umleitung aller alten URLs auf die Startseite ist keine gute Idee. Sie führt zu irrelevanten Ersetzungen, die Google als Soft-404 behandeln kann, und die Signale deiner stärksten Unterseiten landen auf einer Seite, die inhaltlich nicht zu ihnen passt.

Die 301-Redirect-Matrix als Pflichtdokument

Die Redirect-Matrix ist das zentrale Dokument der Migration. Du brauchst sie auch Monate nach dem Launch: für neue 404-Funde, für externe Verweise und für KI-Zugriffe. Ich führe sie als CSV-Datei mit diesen Spalten:

alte_url;neue_url;status;sprache;prioritaet;bemerkung
https://alt.it/;https://neu.it/;301;it;A;Startseite, 1:1
https://alt.it/leistungen/;https://neu.it/leistungen/;301;de;A;1:1
https://alt.it/de/leistungen/;https://neu.it/de/leistungen/;301;de;A;1:1
https://alt.it/it/servizi/;https://neu.it/it/servizi/;301;it;A;1:1
https://alt.it/angebot-2023/;https://neu.it/archiv/angebot-2023/;301;de;B;Inhalt archiviert
https://alt.it/aktion-weihnachten/;https://neu.it/;410;de;C;Kampagne ohne Ersatz
https://alt.it/llms.txt;https://neu.it/llms.txt;301;all;A;KI-Pfad
https://alt.it/brand.txt;https://neu.it/brand.txt;301;all;A;KI-Pfad

Vier Regeln dazu, die ich in jedem Projekt durchsetze:

• 1:1-Zuordnung. Jede alte URL zeigt auf genau eine neue Seite. Keine Sammel-URL für mehrere alte Pfade.
• Keine Ketten. Kein Muster alte URL → Zwischen-URL → neue URL. Jede zusätzliche Hop ist eine Fehlerquelle und verlangsamt den Crawler. Im Test muss die alte URL nach genau einem Redirect auf der endgültigen Seite landen.
• Keine Weiterleitung auf die Startseite. Wenn es keine Entsprechung gibt, lautet die Antwort 410.
• Sprache und x-default mitführen. DE, IT und EN erhalten eigene Zeilen, damit hreflang und Weiterleitung dieselbe Sprachlogik abbilden.

Die Matrix wird in der Regel serverseitig umgesetzt: bei Apache über .htaccess oder Redirect-Direktiven, bei Nginx über return 301, in Content-Management-Systemen über eine eigene Redirect-Verwaltung. Wichtig ist, dass die Matrix in der Produktionsumgebung identisch vorliegt wie im Test: gleiche Datei, gleicher Stand, gleiche Versionierung.

Launch-Tag-Checkliste: der Tag des Go-live

Am Tag des Launches entscheidet sich, ob die Migration sauber war. Diese Checkliste gehe ich in jedem Projekt in derselben Reihenfolge durch.

Technik und Indexierung

• Stichprobe Weiterleitungen: Mindestens 20 URLs aus der Matrix – davon je zwei pro Prioritätsklasse und Sprachvariante – im Inkognito-Fenster abrufen. Erwartet wird: genau ein Redirect, Status 301, korrekte Zielseite, kein Kettenredirect.
• robots.txt prüfen: Die Sperrungen der Staging-Umgebung dürfen nicht live sein. Die robots.txt selbst gehört mit Screenshot und Datum ins Launch-Protokoll.
• X-Robots-Tag und Meta-Robots prüfen: kein noindex im Header, kein noindex im HTML. Beides gegenprüfen, weil der Header beim Umschalten des CMS-Modus häufig übersehen wird.
• Canonical-Tags prüfen: absolut, selbstreferenzierend, ohne Parameter, auf jeder getesteten Seite.

Sprachen, Inhalte und Verweise

• hreflang prüfen: reziprok, jede Version referenziert sich selbst, x-default gesetzt, Sprachcodes korrekt (de, it, en – nicht de-DE, wenn nicht regional differenziert).
• Schema.org prüfen: JSON-LD auf Startseite, Leistungsseite und Kontaktseite vorhanden und valide.
• Sitemap einreichen: neue Sitemap in der Search Console einreichen und die alte Sitemap-Datei nicht mehr referenzieren.
• Indexierung anstoßen: URL-Prüfung für die zehn wichtigsten Seiten aus der Prioritätsklasse A.

Verweise, KI-Pfade und Freigabe

• Interne Links nachverfolgen: alle internen Links auf alte Pfade prüfen. Ein toter interner Link erzeugt einen 404-Fehler und bindet Crawl-Budget.
• Externe Verweise prüfen: Branchenverzeichnisse, Presseberichte, Partnerseiten und Links von Kunden auf die alte Domain. Diese Stellen aktualisierst du proaktiv, statt auf einen Redirect zu warten.
• KI-Pfade prüfen: llms.txt, brand.txt und maschinenlesbare Sitemap-Dateien unter der neuen Domain abrufbar und korrekt verlinkt.
• Freigabepunkt: Erst wenn alle zwölf Prüfpunkte bestanden sind, gibst du den Traffic um. Verantwortlich ist eine Person, die den Go-live freigibt – nicht die Entwicklung allein.

Die technische Kette vom CMS bis zur Indexierung habe ich in Website-Indexierungskette prüfen: vom CMS bis zu Google beschrieben. Wenn du die Kette einmal verstanden hast, findest du Fehler in Minuten statt Stunden.

Monitoring in den ersten 14 Tagen: was du täglich prüfst

Die zwei Wochen nach dem Launch zeigen, ob die Migration gelungen ist. Mein Monitoring-Protokoll hat vier feste Blickpunkte:

1. 404-Logs auswerten (täglich). Jede 404-URL wird in die Redirect-Matrix aufgenommen und mit 301 oder 410 beantwortet. Die Logs zeigen zugleich, welche alten URLs weiterhin angefragt werden, etwa durch externe Links oder KI-Assistenten. Das ist die schnellste Quelle für neue Weiterleitungen.
2. Crawl- und Indexierungsstatus beobachten (täglich). In der Search Console prüfst du Seiten mit dem Status „Gefunden – derzeit nicht indexiert“. Stehen dort Prioritäts-A-Seiten, liegt in der Regel ein noindex, eine robots-Blockade oder eine falsche Weiterleitung vor.
3. Ranking und Klickrate gegen die Baseline vergleichen (wöchentlich). Position, Impressionen und Klickrate der Top-20-URL aus der Baseline mit dem Ist-Zustand vergleichen. In den ersten Tagen ist ein leichtes Schwanken erwartbar; anschließend steigen die Impressionen meist, weil Google die neuen URLs neu verarbeitet.
4. Core Web Vitals beobachten (wöchentlich). Google hat 2024 die Interaction to Next Paint (INP) als Core Web Vital eingeführt, als Ersatz für First Input Delay. Page Experience ist ein relevanter Ranking-Faktor: Ein schwereres Theme kann Ladezeit und Interaktionen messbar verschlechtern.

Notfallplan: die Schwellenwerte

Damit im Ernstfall niemand diskutiert, sondern handelt, legst du vor dem Launch drei Schwellenwerte fest. Meine praxisüblichen Ausgangswerte:

• Stufe 1 – Beobachten: Eine Prioritäts-A-Seite verliert über fünf aufeinanderfolgende Tage mehr als drei Positionen oder 20 Prozent ihrer Impressionen. Ursache prüfen, noch keine Änderung an der Struktur.
• Stufe 2 – Korrigieren: Der Verlust besteht seit zehn Tagen oder die URL verschwindet aus dem Index. Zuerst die Weiterleitung testen, dann robots.txt, X-Robots-Tag, Canonical und hreflang prüfen. In der Regel liegt die Ursache an einer dieser Stellen.
• Stufe 3 – Rollback: Nach 14 Tagen zeigt eine Prioritäts-A-Seite weiterhin einen Rückgang von mehr als 30 Prozent. Dann wird die alte Version parallel unter einer Subdomain bereitgestellt und per 301 auf die alte Struktur zurückgeführt; das Monitoring läuft weiter. Ein Rollback ist keine Niederlage, sondern eine saubere technische Entscheidung.

Ein Relaunch ohne Rankingverlust ist keine Frage des Glücks, sondern eine Frage der Dokumentation. Was du vor dem Launch nicht gemessen hast, kannst du nach dem Launch nicht verbessern.

KI-Sichtbarkeit beim Relaunch mitnehmen

Ein Punkt wird beim Relaunch oft vergessen: Neben der klassischen Website liefern viele Betriebe zusätzlich maschinenlesbare Pfade aus. Diese Dateien und Endpunkte verschwinden beim Neuaufbau, wenn niemand sie auf der Liste hat. Deshalb gehören in die Redirect-Matrix:

• llms.txt – eine projektinterne Übersicht für Sprachmodelle und Agenten,
• llms-full.txt und llms.html – ausführliche Text- und HTML-Fassungen für maschinelle Abrufe,
• brand.txt und ai.json – maschinenlesbare Unternehmensfakten,
• maschinenlesbare Sitemap-Dateien – für Agenten, die Inhalte gezielt abrufen,
• Markdown-Fassungen der Kernseiten, falls du sie auslieferst.

Der technische Grund ist einfach: Ein Assistent, der die alte Adresse kennt, erhält nach dem Umzug keine gültige Antwort, wenn die Weiterleitung fehlt. Mit korrekt gesetzter 301-Weiterleitung findet das System die neue Adresse. Die vollständige Pfadliste mit Prioritätsstufen findest du in der Übersicht zu Website-Markdown und URL-Synchronisierung.

Zeitplan und Verantwortlichkeiten: 4 bis 6 Wochen Vorlauf

Ein Migrationsplan ohne klare Zuständigkeiten scheitert an den Übergaben. Diese Aufteilung hat sich in der Praxis bewährt:

• Woche 1–2: Bestandsaufnahme. URL-Inventur, Baseline aus der Search Console, JSON-LD-Inventar, KI-Pfadliste. Verantwortlich: SEO/Marketing-Seite, Zuarbeit aus der Entwicklung.
• Woche 2–3: Mapping und Matrix. 301-Redirect-Matrix ausfüllen, Statuscodes vergeben, Sprachlogik festlegen. Verantwortlich: Entwicklung gemeinsam mit SEO.
• Woche 3–4: Umsetzung im Testsystem. Weiterleitungen, robots.txt, Canonicals, hreflang, Schema.org, Sitemap. Stichprobenprüfung im Test.
• Woche 4–5: Go-live und Launch-Tag-Checkliste. Verantwortlich: eine Person, die den Go-live freigibt – nicht die Entwicklung allein.
• Woche 5–6: Monitoring. Tägliche 404-Logs, wöchentlicher Baseline-Vergleich, Notfallplan nach Schwellenwerten.

Praxisbeispiel aus Bozen: ein Relaunch ohne Rankingverlust

Ein anonymisierter Bozener Betrieb aus dem technischen Handwerk, zweisprachig DE/IT, hatte über Jahre eine stabile Website mit rund 40 indexierten Seiten und drei Top-5-Positionen. Der Relaunch war technisch gut vorbereitet – neues Design, neues CMS, bessere Ladezeiten. Trotzdem wären nach dem Launch zwei Drittel der Unterseiten aus den Suchergebnissen verschwunden.

Der Grund lag in drei Details, die im Projektplan nicht vorgekommen waren:

• Die neue Navigation hatte die alte Pfadstruktur geändert, und es gab keine Redirect-Matrix – nur eine Startseiten-Umleitung.
• Die Staging-Umgebung wurde mit übernommenen noindex-Tags live geschaltet; zusätzlich blockierte die robots.txt die Sitemap.
• Die hreflang-Verweise zwischen der deutschen und der italienischen Fassung waren nur halb umgestellt, x-default fehlte.

Wir haben den Go-live um eine Woche verschoben, die Inventur mit 61 alten URLs aufgebaut, die Matrix mit 58 Einträgen gefüllt und drei Seiten mit 410 beantwortet. Nach dem Launch lag die Klickrate der Top-10-Seiten in Woche 3 über dem Vorjahreswert, die drei Top-5-Positionen waren nach sechs Wochen wieder stabil. Die entscheidende Lehre daraus war keine technische: Ohne dokumentierte Baseline gibt es keinen Beleg für Erfolg – und ohne Beleg diskutiert das Team nach dem Launch über Gefühle statt Daten.

Wenn du den technischen Unterbau nicht selbst abbilden willst, übernehmen wir bei Berger+Team Strategie und Umsetzung: Website-Strategie und technische Umsetzung – inklusive URL-Mapping, Redirect-Aufbau und Monitoring nach dem Launch.

Häufige Fragen zum Website-Relaunch

Wie lange brauche ich für einen Relaunch ohne Rankingverlust?

Plane 4 bis 6 Wochen Vorlauf ein, bei mehrsprachigen Websites mit vielen URLs eher acht Wochen. Der Zeitraum setzt sich zusammen aus URL-Inventur und Baseline (Woche 1–2), Mapping und 301-Redirect-Matrix (Woche 2–3), Umsetzung und Test (Woche 3–4), Go-live mit Launch-Tag-Checkliste (Woche 4–5) sowie 14 Tage Monitoring (Woche 5–6). Die reine Umsetzung der Weiterleitungen dauert technisch Stunden; die Dokumentation davor dauert Wochen.

Was passiert, wenn ich die alten URLs einfach auf die Startseite umleite?

Du riskierst den Verlust der Rankingsignale deiner Unterseiten. Google kann eine pauschale Umleitung als irrelevante Ersetzung behandeln; deine Landingpage ersetzt dann eine Leistungsseite, die auf „Maler Bozen“ optimiert war. Nutze stattdessen eine 1:1-Zuordnung und für Inhalte ohne Ersatz den Status 410 – das ist sauberer für Nutzer, Crawler und KI-Assistenten.

Wie finde ich alte URLs, die niemand mehr verlinkt hat?

Drei Quellen liefern die Antwort: die Search Console für tatsächlich geklickte URLs, die 404-Logs für weiterhin abgerufene Pfade und die alte Sitemap für alle je existierten URLs. Gerade die Kombination aus 404-Logs und alten Sitemap-Dateien findet Pfade, die kein internes Menü mehr kennt – externe Links oder KI-Assistenten rufen sie aber weiterhin ab.

Was ist der Unterschied zwischen noindex und X-Robots-Tag?

Beides signalisiert „nicht indexieren“, aber an unterschiedlichen Stellen: noindex steht als Meta-Tag im HTML-Head, der X-Robots-Tag kommt als HTTP-Header bei jeder Anfrage zurück. Der Header wird bei der Umstellung häufiger übersehen, weil er im Quelltext der Seite nicht sichtbar ist. Wichtig: Wird eine Seite in der robots.txt blockiert, verarbeitet Google das noindex-Tag nicht – die Seite kann trotzdem indexiert bleiben.

Muss ich bei hreflang jede Sprachversion selbst referenzieren?

Ja. Google verlangt reziproke Verweise: Jede Sprachversion listet sich selbst und alle anderen Versionen auf, und die Angaben müssen wechselseitig übereinstimmen. Optional kannst du eine x-default-Angabe setzen, wenn du eine Sprachauswahl oder eine neutrale Fallback-Seite anbietest. Fehlt eine Seite in der Liste, wird die gesamte Auszeichnung dieser Sprachgruppe ignoriert.

Wie schnell sehe ich nach dem Relaunch, ob die Migration funktioniert?

Erste Signale gibt es nach drei bis fünf Tagen: neue URLs erscheinen in der Search Console und die Impressionen steigen. Belastbar wird der Vergleich nach 14 Tagen, weil die Verarbeitung einer Migration laut Google mehrere Tage bis Wochen dauern kann. Führe das Monitoring als Tagesprotokoll mit 404-Logs, Indexierungsstatus und einem wöchentlichen Ranking- und Klickratenvergleich gegen die Baseline – nur so lassen sich die Schwellenwerte sauber anwenden.

Quellen

1. Google Search Central — Site Moves: Dokumentation zu Migrationen und URL-Änderungen
2. Google Search Central — Redirects and Google Search ranking: 301-Weiterleitungen
3. Google Search Central — Block indexing: noindex, X-Robots-Tag und robots.txt
4. Google Search Central — Internationalized sites: hreflang und x-default
5. Google Search Central — Consolidate duplicate URLs: Canonical-Tags
6. Google Search Central — Build and submit a sitemap
7. Google Search Central — Introduction to structured data: Schema.org und JSON-LD
8. web.dev — Interaction to Next Paint (INP) als Core Web Vital
9. Google Search Console — Performance-Bericht (Hilfe)