SEO-Site-Migration: So wechseln Sie, ohne Rankings zu verlieren

TL;DR: Eine Migration bleibt suchsichtbar, wenn jede wertvolle alte URL eine passende Zielseite erhält, permanente Server-Redirects sie direkt adressieren und Google die neue URL crawlen sowie indexieren kann. Inventarisieren und benchmarken Sie die alte Website vor dem Launch. Erstellen Sie eine 1:1-Redirect-Mapping-Tabelle, aktualisieren Sie interne Links und Canonical-Tags, reichen Sie neue Sitemaps ein und überwachen Sie dann die Überschneidung bei der Indexierung „alt → neu“. Nutzen Sie Change of Address bei Domain-Wechseln – nicht bei HTTP-zu-HTTPS- oder reinen Hosting-Änderungen.

Die erste Frage bei SEO-Site-Migrations lautet nicht, welches Plugin Sie installieren sollen. Sondern: Sehen Nutzer und Google nach dem Umzug unterschiedliche URLs?

Google Search Central unterscheidet Migrationen in Site-Moves mit URL-Änderungen und Site-Moves ohne URL-Änderungen. Diese Abgrenzung bestimmt den Großteil der Arbeit. Domain-Wechsel, HTTP-zu-HTTPS-Umzüge, geänderte Pfade und Domain-Consolidations gehören in die erste Kategorie. Host wechseln oder auf ein CDN umziehen, ohne dass alle sichtbaren URLs sich ändern, fällt in die zweite.

Wir haben selbst eine Domain-Migration durchgeführt, als unser Zwei-Personen-Team – Lida und ich – SEOJuice von seojuice.io auf seojuice.com umgestellt hat, im Januar 2026. Das Verschieben der Anwendung hat mir nicht wirklich Sorgen gemacht. Das Risiko bestand darin nachzuweisen, dass jede alte URL bei der richtigen neuen landet, dass die neue Seite keine internen Links der alten Domain „braucht“ und dass Google die URLs ersetzt – statt sie nur zu entdecken.

Diese Unterscheidung ist entscheidend. „Die neue Seite ist live“ ist ein Infrastruktur-Meilenstein. Es ist kein Beleg dafür, dass die Migration funktioniert hat.

Was zählt als SEO-Site-Migration?

Eine SEO-Site-Migration ist eine Änderung, die groß genug ist, um zu beeinflussen, wie Suchmaschinen eine Website erreichen, crawlen oder indexieren. Eine neue Domain ist das naheliegendste Beispiel – aber auch einige weniger spektakuläre Vorhaben erfordern dieselben Kontrollen.

• Domainwechsel: Umzug auf eine andere Domain im Zuge eines Rebrands, einer Übernahme oder einer Änderung der Top-Level-Domain.
• HTTP zu HTTPS: Das Protokoll ist Teil der URL. Deshalb ist das eine Migration mit URL-Änderungen, obwohl der Hostname gleich bleibt.
• Plattform- oder CMS-Wechsel: Eine neue Plattform kann Pfade, Parameter, Pagination, Case-Handling oder abschließende Slashes verändern. Behandeln Sie es als URL-Änderungs-Migration, wenn sich dadurch irgendeine resultierende URL unterscheidet.
• Redesign oder URL-Strukturierung: Ein visuelles Redesign ist nicht automatisch eine Migration. Es wird eine, wenn sich Pfade, Slugs, Navigation, Canonicals, gerendertes Content oder die Indexierbarkeit ändern.
• Domain-Consolidation: Mehrere Domains oder Hostnames in eine zusammenzuführen, erfordert für jede Quell-Domain ein eigenes Inventar und Redirect-Konzept.
• Hosting- oder CDN-Umzug: Wenn sich die nutzerseitig sichtbaren URLs identisch bleiben, ist das in erster Linie eine DNS- und Infrastrukturaufgabe – weniger ein Redirect-Projekt.

Ich würde diese Änderungen nur dann kombinieren, wenn die Business-Vorgabe stärker ist als das diagnostische Risiko. Google ist da sehr eindeutig: „Ändern Sie jeweils nur eine Sache.“ Ein gleichzeitiger Wechsel von Domain, CMS, Design und Taxonomie liefert Ihnen vier plausible Ursachen für jede verlorene Landingpage (tatsächlich mehr, sobald Rendering und Templates mitspielen).

Vor dem Launch: erst Inventar, dann Migration

Erstellen Sie ein belastbares Inventar der alten URLs

Ihre Redirect Map kann nur die URLs schützen, die darin enthalten sind. Crawl der alten Seite durchführen, anschließend diesen Crawl mit XML-Sitemaps, Search-Console-Exports, Analytics-Landingpages, Backlink-Daten (sofern verfügbar) und Server-Logs zusammenführen. Jede Quelle zeigt einen anderen Ausschnitt der Website.

Ein Crawler findet verlinkte Seiten, kann aber Waisen (Orphans) übersehen. Eine Sitemap kann alte URLs ausschließen, die trotzdem noch ranken. Analytics zeigt keine Seiten ohne aktuelle Besuche. Logs können Requests auf Dateien und Legacy-Pfade sichtbar machen, die in der aktuellen Navigation nicht mehr vorkommen. „Vollständig“ ist hier ein unangenehmes Wort (ich entscheide mich meist für „unabhängig abgeglichen“).

Beziehen Sie auch nicht-HTML-Assets in den Scope ein, wenn sie Suchwert haben oder externe Links bekommen. PDFs, herunterladbare Guides, Bilder und alte Kampagnenseiten werden leicht vergessen, weil sie in einem normalen Page-Crawl nicht auftauchen.

Schaffen Sie eine Basis außerhalb des Systems, das ersetzt wird

Exportieren Sie organischen Traffic auf Landingpages, wichtige Query- und Page-Performance, Informationen zu indexierten Seiten, Top-Ranking-URLs und die aktuellen Crawl-Ergebnisse. Segmentieren Sie nach Verzeichnis oder Seitentyp. Eine einzige Sitewide-Traffic-Zahl ist zu grob, um eine Migration zu debuggen.

Wenn der Traffic um 12 Prozent fällt, sagt Ihnen diese Zahl fast nichts. Wenn hingegen ein Produkt-Verzeichnis verschwindet, während der Blog stabil bleibt, haben Sie einen brauchbaren Hinweis. Prüfen Sie zuerst die Redirects dieses Verzeichnisses, Templates, Canonical-Tags und Indexierungsanweisungen.

Ich habe mir Baseline-Arbeit gespart, weil sich der Launch dringend angefühlt hat. Das hat vielleicht eine Stunde gekostet – und die spätere Diagnose langsamer sowie weniger sicher gemacht. Kein cleverer Trade.

Ordnen Sie jede alte URL der nächstpassenden Ersetzung zu

Google Search Central gibt die Kernanweisung:

Eine Redirect Map sendet jede alte URL zu ihrer echten neuen Entsprechung – 1:1:

# 1:1 redirect map (Nginx) - old URL to its closest new equivalent
location = /old-blog/why-seo/    { return 301 /blog/why-seo/; }
location = /products/old-widget/ { return 301 /shop/blue-widget/; }

# Anti-pattern: never mass-redirect everything to the homepage
# location / { return 301 /; }   # this creates soft 404s

„Sobald Sie die Liste der alten URLs haben, entscheiden Sie, wohin jede einzelne weiterleiten soll.“

Erstellen Sie ein Mapping mit genau einer Zeile pro alter URL. Fügen Sie das beabsichtigte Ziel, den erwarteten Response-Code, Seitentyp, Migrationsstatus sowie Gründe für die Stilllegung ein. Priorisieren Sie URLs mit organischen Besuchen oder externen Links, aber „priorisieren“ heißt nicht, dass Sie die Long-Tail-URLs ignorieren dürfen.

Das Ziel muss die Intention beibehalten. Eine alte Produktseite sollte zu demselben Produkt führen – oder zu dessen echtem Nachfolger. Ein migrierter Artikel muss zum Artikel führen. Die Startseite ist kein universeller Ersatz.

Bewahren Sie bestehende Pfade, wo es möglich ist. Jede unveränderte URL bedeutet: keine Redirect-Regel, keine Mapping-Entscheidung und damit weniger potenzielle Fehler. Teams überarbeiten Slugs oft während eines Redesigns, weil die neuen Versionen „cleaner“ aussehen. Ich würde fragen, welches messbare Problem dieses Aufräumen löst, bevor ich das Migrationsrisiko akzeptiere.

Entscheiden Sie, was nicht weitergeleitet werden soll

Ein 1:1-Mapping heißt nicht, dass jede gelöschte Seite zwangsläufig irgendwohin „durchgereicht“ werden muss. Wenn eine Seite keine Entsprechung hat und kein nützlicher Nachfolger existiert, kann ein korrektes 404 oder 410 klarer sein als ein irrelevantem Redirect.

Das erfordert redaktionelles Urteilsvermögen – keine Tabellenkalkulations-Formel. Ein abgekündigtes Produkt auf sein Ersatzmodell umzuleiten, kann sinnvoll sein. Eine gelöschte Eventseite auf einen thematisch unpassenden Events-Index umzuleiten, unter Umständen nicht. Relevanz zuerst.

Bereiten Sie die Zielseiten für das Crawling vor

Importieren Sie den Content, konfigurieren Sie HTTPS, bereiten Sie die production robots.txt Datei vor, prüfen Sie die relevanten Search-Console-Properties und kontrollieren Sie Indexierungsanweisungen auf Seitenebene. Validieren Sie Canonical-Tags, hreflang (falls verwendet), strukturierte Daten (URLs), Pagination und XML-Sitemaps gegen den Production-Hostname.

Staging-Seiten sind typischerweise mit robots.txt-Regeln, noindex-Anweisungen, Authentifizierung oder einer Kombination davon geschützt. Diese Schutzmaßnahmen dürfen nicht „ins Production-Live“ überlaufen. Wenn Seiten nach dem Launch weiterhin fehlen, decken die Checks in Warum steht meine Seite nicht bei Google? die robots-Kontrollen, noindex-Anweisungen und die URL-Inspektion ab.

Für große Websites: migrieren Sie zuerst einen Abschnitt, wenn die Architektur es erlaubt. Google empfiehlt: „Zunächst nur einen Teil der Seite zu verschieben, um mögliche Auswirkungen auf Traffic und Suchindexierung zu testen.“ Ein gestufter Umzug ist nicht immer möglich, aber es lohnt sich, darüber nachzudenken, bevor Sie auf ein Alles-oder-Nichts-Cutover setzen.

Während des Launches: sorgen Sie dafür, dass alle Signale übereinstimmen

Nutzen Sie direkte, permanente Server-Redirects

Google empfiehlt: „Serverseitige permanente Weiterleitungen von den alten URLs zu den neuen URLs – so wie Sie es in Ihrem Mapping angegeben haben.“ Wenn Redirect-Mechaniken nicht vertraut sind, lesen Sie zuerst Was ist ein Redirect?. Unser Vergleich in 301 und 302 Weiterleitungen geht auf die Entscheidung „permanent vs. temporär“ ausführlicher ein.

Wie Patrick Stox, Lead Author im Web-Almanac-SEO-Kapitel, es formuliert:

„Stellen Sie sicher, dass Ihre Redirects 301 oder 308 statt 302 oder 307 sind, wenn Sie einen permanenten Move machen und möchten, dass URLs auf der neuen Website indexiert werden – statt auf der alten.“

Der Statuscode ist keine Formsache. Googles Redirect-Dokumentation erklärt, was bei einem permanenten Redirect passiert: „Googlebot folgt dem Redirect, und die Indexierungs-Pipeline nutzt die Weiterleitung als Signal dafür, dass das Redirect-Ziel kanonisch sein soll.“

Jede alte URL sollte direkt auf ihr endgültiges Ziel zeigen. Vermeiden Sie Old-to-Intermediate-to-Final-Ketten. Testen Sie auf Loops, die durch überlappende Regeln für HTTPS, www, abschließenden Slash, CDN, Server und die Anwendung entstehen können.

Danach prüfen Sie die Live-Response – nicht nur die Konfigurationsdatei. Eine Regel kann isoliert korrekt sein und trotzdem mit einer anderen Ebene kollidieren. An genau dieser Stelle höre ich auf, der Migrations-Excel/Sheet einfach zu vertrauen (und, ganz fair, auch meinem eigenen Gedächtnis) und crawle die Production.

Keine Mass-Redirects von Seiten auf die Startseite

Google warnt ausdrücklich:

„Leiten Sie nicht viele alte URLs auf eine einzige irrelevante Ziel-URL weiter, etwa auf die Startseite der neuen Website.“

Ein Mass-Redirect zur Startseite verdeckt fehlende Mapping-Arbeit; er ersetzt sie nicht. Suchmaschinen und Nutzer erwarten eine bestimmte Ressource. Wenn Sie jede Anfrage auf eine generische Seite umleiten, verlieren Sie diese Beziehung.

Wenn viele URLs einen legitimen Nachfolger teilen, kann ein Many-to-one-Mapping sinnvoll sein. Mehrere Duplicate-Produkt-URLs können alle zur kanonischen Produktseite auflösen. Das Problem ist die Irrelevanz, nicht die Mathematik.

Aktualisieren Sie interne Links, Canonicals und generierte Referenzen

Redirects sind Fallback-Infrastruktur. Sie sollten nicht zum neuen internen Linking-System der Website werden.

Aktualisieren Sie Navigation, Breadcrumbs, Artikel-Links, Module für „Ähnliche Inhalte“, Canonical-Tags, hreflang-Referenzen, strukturierte Daten, Sitemap-Einträge und Asset-Referenzen so, dass sie direkt die finalen URLs nutzen. Googles Anweisung lautet: „Ändern Sie die internen Links auf der neuen Seite von den alten URLs zu den neuen URLs.“

Was wir bei SEOJuice über mehrere Websites hinweg sehen: Template-Level-Links sind oft wichtiger als einzelne redaktionelle Links, weil ein veralteter Baustein dieselbe Redirect-Abhängigkeit in hunderten Seiten reproduzieren kann. Prüfen Sie zuerst die Templates, danach den Content-Body.

Reichen Sie Sitemaps ein und nutzen Sie Change of Address korrekt

Reichen Sie die neue XML-Sitemap in Search Console ein. Google sagt, das hilft dabei, die neuen URLs kennenzulernen. Wenn Sie separate Sitemaps für alte-URLs und neue-URLs führen, haben Sie zudem einen praktischen Weg, den Austausch zu überwachen.

Bei einem Domain-zu-Domain-Move reichen Sie Change of Address in der alten Search-Console-Property ein. Googles präzise Anweisung ist, Anfragen für „alle Subdomains sowie die www- und non-www-Varianten des alten Domainnamens“ einzureichen. Das Tool ergänzt permanente Redirects – es ersetzt sie nicht.

Nutzen Sie Change of Address nicht bei HTTP-zu-HTTPS-Migrationen. HTTPS ändert zwar die URL, aber Google schließt diesen Fall explizit vom Tool aus. Zudem ist es nicht nötig bei reinen Hosting-only Moves und Pfadänderungen innerhalb derselben Domain.

Nach dem Launch: Beobachten Sie die Ersetzung – nicht nur den Traffic

Eine Migration ist nicht abgeschlossen, nur weil DNS auflöst und die Startseite rendert. Sie ist abgeschlossen, wenn Nutzer und Crawler die beabsichtigten Inhalte dauerhaft erreichen und die neuen URLs die alten URLs in Googles Index ersetzen.

Überwachen Sie Search-Console-Indexierungsberichte, Crawl-Errors, Rankings und organischen Traffic auf Landingpages im Vergleich zur Baseline. Google beschreibt das erwartete Indexierungs-Muster sehr klar:

„Im Zeitverlauf würde die Anzahl der Seiten, die aus der Sitemap mit den alten URLs indexiert werden, auf null sinken – bei entsprechendem Anstieg der Indexierung der neuen URLs.“

Diese Überschneidung ist hilfreicher als das bloße Aktualisieren eines einzelnen Traffic-Charts. Wenn ein Bereich auf der neuen Seite nicht nach oben geht, prüfen Sie seine Redirects, Canonical-Tags, internen Links, Sitemap-Aufnahme, gerenderten Content und Indexierungsanweisungen. Unser Guide zu wie Google Indexierung funktioniert erklärt den Crawl- und Canonicalization-Prozess hinter dieser Ersetzung.

Ein temporärer Rückgang ist möglich, während Google die geänderten URLs erneut crawlt und neu indexiert. Es gibt keine glaubwürdige universelle Prozentzahl oder eine feste Recovery-Frist. Seitengröße, Crawl-Frequenz, internes Linking, Redirect-Qualität und Umfang der Änderung unterscheiden sich. Ein deutlicher Verlust auf Seiten- oder Verzeichnisebene ist ohnehin aussagekräftiger als eine Branchen-Durchschnittszahl.

Redirects weiterlaufen lassen

Google sagt: „Behalten Sie die Redirects so lange wie möglich bei, im Allgemeinen mindestens 1 Jahr.“ Nützliche Redirects dauerhaft zu behalten kann außerdem helfen, Besucher mit alten Bookmarks und Links von Websites zu erreichen, die Sie nicht kontrollieren.

Brechen Sie die alte Domain oder unterstützende Infrastruktur nicht zu früh ab. Ein Redirect, der beim Launch-Crawl funktioniert, aber nach Monaten verschwindet, kann später weder Nutzer noch Crawler helfen, die auf einen alten Link stoßen.

Die Ausfälle, die ich zuerst untersuchen würde

Prüfen Sie erst Accessibility und Redirects, bevor Sie Titel umschreiben oder ein Algorithmus-Update verantwortlich machen. Migrationsfehler sind oft mechanisch: Eine Seite ist blockiert, ein Redirect kollidiert mit einer anderen Regel oder ein Canonical zeigt auf den falschen Host.

Die Reihenfolge zählt. Metadaten auf einer URL zu reparieren, die Google nicht crawlen kann, ist reine Beschäftigungstherapie.

Eine Hosting-only Migration ist eine andere Baustelle

Wenn jede nutzerseitig sichtbare URL gleich bleibt, bauen Sie kein Redirect-Projekt „künstlich“ auf. Google definiert diesen Fall als Wechsel des Hosting-Providers oder Umzug auf ein CDN, ohne dass sich die sichtbare URL ändert.

Bereiten und testen Sie die neue Infrastruktur vor, reduzieren Sie – wo passend – die DNS Time-to-Live, ändern Sie DNS und überwachen Sie Requests, die aus beiden Umgebungen bedient werden. Google rät, die alte Infrastruktur erst abzuschalten, wenn Sie sicher sind, dass alle Nutzer – einschließlich Googlebot – korrekt Content aus dem neuen Setup erhalten.

Es gibt keine Redirect Map und keine Change-of-Address-Anfrage, weil sich die URLs nicht bewegt haben. Die Haupt-Risiken liegen bei Verfügbarkeit, Performance, DNS-Konfiguration, Server-Responses und bei Unterschieden, was die neue Infrastruktur für Crawler ausliefert.

Wie SEOJuice nach einer Migration passt

Nachdem wir seojuice.io auf seojuice.com umgezogen haben, brauchten wir vor allem eine wiederholbare Inspektion des Live-Ergebnisses. Nicht noch ein weiteres Launch-Spreadsheet.

SE0Juices kostenloser SEO-Audit prüft migrationskritische Bereiche, darunter robots.txt, Sitemaps, Canonical-Tags, HTTPS-Konfiguration, Redirects und interne Links. Er kann Links sichtbar machen, die noch auf die alte Domain zeigen, Redirect-Ziele, die Fehler zurückgeben, übrig gebliebene noindex-Anweisungen sowie Canonical- oder HTTPS-Mismatches.

Die Grenze ist wichtig. Der Audit zeigt, was falsch ist und wo. Er schreibt keine Server-Redirect-Regeln und reicht auch nicht für Sie Change of Address ein. Diese Schritte bleiben bei Ihnen – was vermutlich der Bereich ist, in dem Domain-Änderungen auch bleiben sollten.

Häufig gestellte Fragen

Was ist eine SEO-Site-Migration?

Eine SEO-Site-Migration ist eine Änderung, die beeinflusst, wie Suchmaschinen eine Website erreichen, crawlen oder indexieren. Beispiele sind Domain-Umzüge, der Wechsel von HTTP zu HTTPS, das Ändern von CMS-Plattformen oder URL-Strukturen, das Konsolidieren von Domains und das Umziehen von Hosts. Der entscheidende Punkt ist, ob sich die sichtbaren URLs ändern – denn geänderte URLs brauchen Mapping und Redirects.

Verliere ich Rankings, wenn ich meine Seite migriere?

Nicht unbedingt. Permanente Redirects helfen Google, das Ziel als kanonisch zu behandeln und die alte URL zu ersetzen. Beim erneuten Crawling und Reindexieren kann es zu Schwankungen kommen. Anhaltende Verluste sprechen oft dafür, fehlende Redirects, irrelevante Ziele, Redirect-Loops, temporäre Redirects, geänderten Content, Canonicals und blockierte Indexierung zu prüfen.

Müssen alte URLs 1:1 weitergeleitet werden?

Jede wertvolle alte URL sollte einzeln bewertet und zur nächstpassenden relevanten Ersetzung weitergeleitet werden. Schicken Sie keine irrelevanten Seiten zur Startseite. Wenn es keine passende Ersetzung gibt, kann ein korrektes 404 oder 410 genauer sein als ein irreführender Redirect.

Wann sollte ich das Change-of-Address-Tool von Google nutzen?

Nutzen Sie es für einen Umzug von einer Domain auf eine andere. Reichen Sie die notwendigen Anfragen für Subdomains sowie die www- oder non-www-Varianten der alten Domain ein. Verwenden Sie es nicht für HTTP-zu-HTTPS-Änderungen, Pfadänderungen innerhalb einer Domain oder Hosting- und CDN-Moves. Change of Address ersetzt keine permanenten Redirects.

Wie lange sollten Migration-Redirects aktiv bleiben?

Google empfiehlt, Redirects so lange wie möglich beizubehalten – im Allgemeinen mindestens ein Jahr. Nützliche Redirects dauerhaft zu halten kann alte Bookmarks und externe Links schützen, sofern die Ziele weiterhin relevant bleiben.

Wie prüfe ich, ob die Migration funktioniert hat?

Vergleichen Sie nach dem Launch Traffic, Rankings, indexierte URLs und Crawl-Ergebnisse mit der Baseline. Crawlern Sie alte URLs, um direkte permanente Redirects zu bestätigen, crawlen Sie die neue Seite auf alte interne Links und prüfen Sie robots-Anweisungen, Canonicals, Sitemaps und Server-Responses. In Search Console sollte die indexierte Anzahl der alten Sitemap sinken, während die der neuen Sitemap steigt.