Wie ziehe ich eine Website per Search Console auf eine neue Domain um, ohne Rankings zu verlieren?

Woher bekomme ich die vollständige Liste meiner alten URLs, und warum reicht die Sitemap allein nicht?

Diesen Fehler habe ich schon bezahlt. Bei einem Kundenumzug im August 2026 habe ich die Liste der alten Adressen aus der Navigation der Altseite abgeleitet, weil sie vollständig aussah. Nachgemessen gegen den Bestand des Webarchivs liefen 167 von 263 alten Adressen auf eine Fehlerseite. In einer Navigation sieht sie niemand, Google kennt sie trotzdem.

Für meinen eigenen Umzug am 15. September 2026 habe ich die Grundgesamtheit aus mehreren Quellen gebaut. Die Sitemap führte 52 Pfade, die Search Console kannte über 16 Monate 44, das Webarchiv 14. Vereinigt waren es 68.

Warum eine Quelle nicht reicht, steckt in einer Rechnung: das Webarchiv kannte vier Blogartikel, die Search Console kannte vier, und nur EIN Artikel war in beiden derselbe. Zusammen sind es sieben. Wer nur eine Quelle nimmt, verliert drei Adressen still.

Ein Punkt wird gern übersehen: die Search Console führt die Variante mit www als eigene Zeilen. Welcher Property-Typ was zeigt, steht in Domain-Property oder URL-Präfix.

Welches Ziel bekommt jede alte URL: 301 in einem Sprung, 410 oder neu bauen?

Aus der Grundgesamtheit wird eine Karte, und diese Karte ist eine Datei, kein Bauchgefühl. Bei mir liegt sie als Datenstruktur im Repository, und Prüfskripte wie Weiterleitungsregeln werden daraus erzeugt. Die Prüfung misst genau das, was der Server ausliefert.

Am Ende standen 77 Einträge darin: die 68 Pfade aus den drei Quellen, die Weiterleitungsregeln aus der Konfiguration der alten Anwendung und vier noindex-Seiten, die in keiner Quelle auftauchten. Daraus wurden 54 Pfade eins zu eins, zwei mit besserem neuen Ziel, 17 auf 410 und vier, die noindex bleiben.

Die 59 Zielseiten mussten vorher existieren, hinter einem Tor: live deployt, aber gesperrt. Kein Inhalt darf zweimal öffentlich stehen, sonst baust Du Dir mit dem Umzug Deine eigene Dublette. Und bevor ein Pfad auf 410 geht, prüfe ich ihn gegen die Search Console: bei mir hatte die größte Seite einer eingestellten Produktlinie über 90 Tage null Impressionen, eine zweite eine Impression und null Klicks.

Warum ist die Sammelweiterleitung auf die Startseite der teuerste Fehler beim Umzug?

Weil sie aussieht wie Sorgfalt und wirkt wie Löschen. Google schreibt in der eigenen Umzugsanleitung, viele alte Adressen sollten nicht auf ein einziges unpassendes Ziel wie die Startseite umgeleitet werden, das verwirre Nutzer und könne als Soft-404 behandelt werden. Soft-404 heißt: die Seite antwortet technisch mit Erfolg, für Google ist sie trotzdem eine Fehlerseite.

Ich habe das selbst gebaut und wieder eingerissen. Beim Kundenumzug lief eine Gruppe von Themenseiten auf die Startseite. Eine davon stand indexiert auf Position 5,5, und ihr zentrales Fachwort kam auf der neuen Startseite überhaupt nicht vor.

Dazu kommt die Kette. Eine alte Produktseite auf die alte Startseite, die alte Startseite auf die neue Domain, das sind zwei Sprünge, und die neue Domain erbt eine Altlast, die sie nie hatte.

Zwei Fallen stecken in den Regeln selbst. Ein Suchmuster ohne Anker greift an jeder Stelle des Pfades und tötet jeden künftigen Beitrag mit demselben Wort in der Adresse. Und ein Muster wie /pfad/* trifft bei manchen Webservern auch /pfad/ selbst, also eine Endlosschleife. Beides findet nur, wer auch die ZIELE misst.

Welche Zahlen friere ich vor dem Schnitt ein, damit ich hinterher etwas zu vergleichen habe?

Ohne Vorher gibt es kein Nachher, sondern nur Meinungen. Zwei Tage vor dem Schnitt habe ich eine Nulllinie geschrieben, in der jede Zahl mit dem Befehl steht, der sie erzeugt hat.

Meine alte Domain, ungruppiert über drei Fenster: 25 Klicks und 4.242 Impressionen bei Position 29,89 über 28 Tage, 60 Klicks und 6.481 Impressionen bei Position 26,62 über 90 Tage, 81 Klicks und 7.223 Impressionen über 480 Tage. Die neue Domain stand in allen drei Fenstern bei null, drei von sieben Sitemap-Adressen im Index.

Zwei Dinge sind leicht falsch gemacht. Erstens: ungruppiert abfragen, denn eine nach Suchanfragen gruppierte Abfrage zählt deutlich zu niedrig, weil Google seltene Suchanfragen nicht ausliefert. Zweitens: die Search Console liefert mit rund drei Tagen Verzug, mein Fenster endet deshalb immer drei Tage vor heute. Sonst vergleichst Du 28 Tage mit 25 und hältst das für einen Einbruch.

Dazu kommt eine Liste der Adressen, die am Tag danach einzeln geprüft werden. Bei mir waren es neun, zuerst nicht die impressionsstärkste, sondern die klickstärkste: die Anleitung zum Freischalten von Instagram für die Search Console trug 23 von 60 Klicks der ganzen Domain über 90 Tage. Die impressionsstärkste hatte 1.928 Impressionen und null Klicks auf Position 32,6.

Warum prüfe ich am Schnitttag jede alte URL dreimal?

Weil eine Domain mehr als eine Adresse hat. Jede alte Adresse existiert mindestens dreimal: ohne www, mit www und unverschlüsselt über http.

Meine eigene Nulllinie macht das konkret. Über 480 Tage standen sechs Adressen mit www in den Daten, zusammen 583 Impressionen und 15 Klicks, darunter eine unverschlüsselte mit zehn Impressionen. Das sind 8,1 Prozent aller Impressionen und 18,5 Prozent aller Klicks dieses Fensters. Wer nur die Variante ohne www prüft, hält einen Umzug für fertig, bei dem fast ein Fünftel der Klicks ins Leere läuft.

Am Schnitttag habe ich deshalb jeden Eintrag der Karte dreimal gemessen und jede Zeile einzeln protokolliert, nicht stichprobenartig: 77 von 77 auf allen drei Varianten, jeweils ein Sprung auf eine Seite mit Status 200 oder ein sauberes 410.

Zwei Fallen haben mich fast erwischt. Meine Sitemap wird beim Bauen vorgerendert: ohne neuen Build hätte die Seite nach dem Neustart bis zu fünf Minuten weiter die alte Sitemap mit sieben Adressen ausgeliefert, nach dem Schnitt führte sie 58. Und eine Nebendomain zeigte auf die alte Hauptdomain, die auf die neue zeigte: eine Zweisprung-Kette aus einer vorher richtigen Regel.

Was bewirkt die Adressänderung in der Search Console, und was heißt die Warnung Duplizierte Weiterleitungsziele?

Die Reihenfolge zählt: erst stehen die Weiterleitungen, dann meldest Du die Adressänderung. Beide Domains müssen verifiziert sein, bei mir sind es zwei Domain-Properties.

Google prüft die Angabe sofort selbst. Bei mir meldete die Vorprüfung für vier Stichproben-Adressen jeweils Weiterleitung gefunden, für die Startseite zusätzlich die Warnung Duplizierte Weiterleitungsziele. Das sah nach einem Fehler aus, ist aber genau das Gebaute: die Variante mit www und die ohne zeigen beide direkt auf dasselbe Ziel. Die Alternative wären zwei Sprünge statt einem. Diese Warnung ist deshalb kein Grund, etwas zu ändern.

Die Adressänderung selbst ist ein Signal mit Verfallsdatum. Bei mir läuft sie seit dem 15. September 2026 und wirkt 180 Tage. Google schreibt dazu, dass danach keine Beziehung zwischen alter und neuer Seite mehr erkannt wird und die Weiterleitungen mindestens so lange stehen sollen, länger, solange über die Suche noch Zugriffe kommen. Das Werkzeug beschleunigt, es ersetzt keine Weiterleitung.

Ein Detail, das leicht untergeht: räume vorher die alte Property auf. Bei mir hing dort noch eine tote zweite Sitemap aus dem Vorjahr mit vier Adressen. Die habe ich am Schnitttag entfernt, damit die Zwei-Sitemap-Messung hinterher wirklich zwei vergleicht.

Woran sehe ich in den Wochen danach, ob der Umzug wirklich ankommt?

An zwei Sitemaps, nicht am Bauchgefühl. Google nennt in seiner Umzugsanleitung genau diese Methode: beide Sitemaps einreichen, die neue beginnt bei null indexierten Seiten, die alte hat viele, und dann dreht sich das Verhältnis. Meine alte Sitemap liefert der Server deshalb weiter statisch mit den Altpfaden aus und bleibt in der alten Property eingereicht, bis dort null steht.

Dafür läuft bei mir ein Wächter, täglich, 56 Tage lang. Er misst jede alte Adresse dreimal, prüft jede Zielseite auf Status 200 und beide Sitemaps gegen die Karte, und schreibt eine Zeile mit der Summe BEIDER Properties. Grün bedeutet Stille: gemeldet wird nur ein Übergang.

Die wichtigste Zahl dabei erwartet niemand: der gemessene Abstand zwischen zwei Crawls einzelner alter Adressen liegt bei bis zu 47 Tagen. Eine Adresse, die Google erst in sieben Wochen wieder besucht, kann ihre Weiterleitung vorher nicht gesehen haben. Deshalb liest sich die erste Woche wie ein Absturz, obwohl nichts kaputt ist, und deshalb misst der Wächter acht Wochen statt zwei.

Den Indexierungsstand der neuen Adressen prüfe ich wöchentlich einzeln statt über den site-Operator: der ist eine Schätzung, die Einzelprüfung die Auskunft des Index selbst. Ob die neue Domain auch in KI-Antworten ankommt, ist eine getrennte Frage, siehe KI-Zitate in der Search Console erkennen.

Was ändere ich nach dem Schnitt bewusst nicht, und wie lange bleiben die Weiterleitungen stehen?

Google rät bei Umzügen dazu, eine Sache auf einmal zu ändern. Daran habe ich mich gehalten: am Schnitttag war meine neue Startseite inhaltlich die gleiche wie die alte, Überschrift für Überschrift, das neue Layout kam eine Woche später. Wenn Domain, Inhalt und Gestaltung am selben Tag wechseln und die Zahlen fallen, weißt Du nicht, welche Änderung schuld ist.

Dasselbe gilt außerhalb der eigenen Seite. Das Website-Feld im Unternehmensprofil habe ich am Stichtag umgestellt, Profilnamen, Kurznamen und Verzeichniseinträge folgen einzeln und zeitversetzt. Gebündelt beurteilst Du keine der Änderungen mehr.

Die Weiterleitungen bleiben. Die Adressänderung wirkt 180 Tage, die Weiterleitungen selbst lasse ich mindestens zwölf Monate stehen, in meinem Fall bis September 2027. Die alte Domain wird nicht gekündigt: sie kostet ein paar Euro im Jahr und trägt jeden Link, den irgendwer vor Jahren gesetzt hat.

Zwei technische Dinge bleiben unangetastet. Der alte Anwendungscontainer läuft zwei Wochen weiter als Rückweg. Und die Programmierschnittstellen der alten Domain werden NICHT per 301 umgeleitet, sondern 14 Tage direkt weitergereicht: eine Weiterleitung macht aus einer sendenden Anfrage eine abrufende, und ein Formular auf der alten Adresse ginge still kaputt. Ob die neue Domain die gewünschten KI-Crawler einlässt, habe ich getrennt geprüft, siehe KI-Crawler erlauben oder blockieren.

Häufige Fragen

Quellen

• Google Search Central, Site moves with URL changes
• Google Search Console-Hilfe, Change of Address tool
• Google Search Central, Redirects and Google Search
• Google Search Central, How HTTP status codes affect Google Search