SEO-Migration ohne Ranking-Verlust: die Redirect-Strategie

Eine SEO-Migration übersteht den Umzug ohne dauerhaften Ranking-Verlust, wenn jede indexierte alte URL per serverseitiger 301-Weiterleitung direkt auf ihr inhaltliches Pendant zeigt — ohne Zwischenstationen, mit aktualisierten internen Links und Canonicals, einer neu eingereichten Sitemap und einem Monitoring, das die normalen Schwankungen über Wochen beobachtet. Der Kern ist die Redirect-Strategie: ein vollständiges URL-Inventar, ein sauberes 1:1-Mapping und die Disziplin, Ketten und Umleitungen ins Leere zu vermeiden. Genau hier entscheidet sich, ob Sichtbarkeit nur kurz wackelt oder strukturell verloren geht. Wenn Sie den Umzug auf eine entkoppelte Architektur planen, gehört dieser Plan vor die Migration der Stolperfallen bei der Headless-Migration, nicht danach.

Dieser Beitrag liefert den konkreten Ablauf — Inventar, Mapping, Redirect-Typen, interne Links, Sitemap, Monitoring — und sagt ehrlich, was eine saubere Strategie trotzdem nicht garantiert.

Was bedeutet eine SEO-Migration ohne Ranking-Verlust?

Eine SEO-Migration ist der Umzug einer Website auf neue URLs — sei es durch Domainwechsel, neue URL-Struktur, HTTPS-Umstellung oder den Wechsel auf eine entkoppelte Architektur. „Ohne Ranking-Verlust" meint nicht null Bewegung, sondern: keine dauerhaften, strukturellen Einbrüche. Vorübergehende Schwankungen gehören dazu. Google schreibt selbst, die Sichtbarkeit könne sich während des Umzugs temporär verändern und werde sich mit der Zeit wieder einpendeln (Google Search Central, Site Moves).

Das Ziel ist deshalb realistisch zu fassen: Ranking-Signale der alten URLs sollen möglichst vollständig auf die neuen übergehen, und die unvermeidliche Crawl- und Neuverarbeitungsphase soll so kurz und so kontrolliert wie möglich bleiben. Wie gross der Hebel ist, zeigen Migrationsstudien deutlich: Eine Auswertung von 892 Domain-Migrationen durch Dan Taylor ergab im Schnitt 523 Tage, bis die neue Domain das organische Traffic-Niveau der alten wieder erreichte — und 17 % schafften es auch nach 1'000 Tagen nicht (Dan Taylor, Studie 2024 in Search Engine Journal). Diese Zahlen gelten für Domainwechsel, nicht für jede URL-Änderung, aber sie machen klar, was auf dem Spiel steht.

Wie erstelle ich ein vollständiges URL-Inventar?

Das URL-Inventar ist die Grundlage jeder Redirect-Strategie: eine vollständige Liste aller URLs, die heute Traffic, Rankings oder Backlinks tragen — gegen die Liste der Ziel-URLs gestellt. Ohne dieses Inventar ist jedes Mapping Stückwerk, und vergessene URLs werden nach dem Go-Live zu 404-Fehlern.

In der Praxis ziehen wir die Liste aus mehreren Quellen zusammen, weil keine einzelne vollständig ist:

• Search Console — alle URLs mit Impressionen und Klicks der letzten 12 bis 16 Monate. Das sind die URLs, deren Rankings Sie schützen.
• Crawler (etwa Screaming Frog) — alle intern verlinkten URLs, inklusive Bilder, PDFs und Paginierung.
• Server-Logs — URLs, die tatsächlich aufgerufen werden, auch ohne interne Verlinkung.
• Backlink-Tool — externe Links zeigen, welche alten URLs fremde Autorität tragen und unbedingt ein Ziel brauchen.
• Bestehende XML-Sitemap — die offizielle Liste dessen, was indexiert sein soll.

Jede URL bekommt im Inventar drei Spalten: alte URL, geplante neue URL, Status. Der Status zeigt sofort, wo es kein 1:1-Pendant gibt — genau die Fälle, die später Kopfschmerzen bereiten.

Wie baue ich das 1:1-Mapping der Redirects?

Das 1:1-Mapping ordnet jeder alten URL genau eine neue Ziel-URL zu — die Seite mit dem inhaltlich nächstliegenden Pendant, nicht die bequemste. Dieses Mapping ist das Herzstück: Es entscheidet, ob ein Ranking-Signal sauber übergeht oder im Nichts landet. Pauschalregeln („alles auf die Startseite") sind hier der teuerste Fehler.

Drei Regeln halten das Mapping sauber:

Erstens: auf das inhaltliche Pendant umleiten, nicht auf die Startseite. Ein 301 auf eine themenfremde Seite oder die Startseite kann laut Google bzw. John Mueller sinngemäss als Soft-404 behandelt werden — die alte URL wird dann wie ein 404 aus dem Index entfernt und überträgt keine Ranking-Signale (GSQI / Glenn Gabe, 2016). Eine Produktseite gehört auf die nächste passende Produkt- oder Kategorieseite, nicht auf /.

Zweitens: serverseitige Redirects verwenden. Google stuft die Redirect-Methoden nach Zuverlässigkeit ein — serverseitige Weiterleitungen sind die zuverlässigste Methode, gefolgt von Meta-Refresh; JavaScript-Redirects bilden das Schlusslicht. Google rät ausdrücklich, JavaScript-Redirects nur einzusetzen, wenn serverseitige oder Meta-Refresh-Varianten unmöglich sind (Google Search Central, Redirects). Für eine Migration heisst das fast immer: serverseitige 301.

Drittens: keine Ketten. Jeder Redirect zeigt direkt auf das finale Ziel. Wenn alte URL A historisch auf B umgeleitet wurde und B nun auf C zieht, gehört A direkt auf C aktualisiert — sonst entsteht eine Kette A → B → C. Warum das schadet, steht im nächsten Abschnitt.

Eine Redirect-Strategie ist nur so gut wie ihr schwächstes Mapping: Eine einzige falsch umgeleitete Top-Seite kostet mehr Ranking, als hundert sauber gemappte Long-Tail-URLs einbringen.

Warum schaden Redirect-Ketten und falsche Codes?

Redirect-Ketten und falsche Status-Codes sind die zwei häufigsten Migrationsfehler, die Ranking-Signale verwässern. Eine Kette zwingt Crawler und Browser durch mehrere Sprünge, bis sie das Ziel erreichen — und jeder zusätzliche Sprung erhöht die Latenz und das Risiko, dass die Kette irgendwo bricht.

Google folgt zwar bis zu zehn Sprüngen in einer Redirect-Kette, rät aber ausdrücklich, direkt auf das finale Ziel umzuleiten; wo das nicht geht, soll die Kette kurz bleiben — idealerweise nicht mehr als drei, in jedem Fall weniger als fünf Sprünge (Google Search Central, Site Moves). Lange Ketten wirken sich zudem negativ auf das Crawling aus (Google Search Central, Crawl-Budget). Für ein typisches Schweizer KMU mit ein paar tausend Seiten ist das Crawl-Budget selten der Engpass — hier ist das ehrlichere Argument die Latenz und die Nutzererfahrung, plus das Risiko gebrochener Ketten. Für sehr grosse Sites wird die Crawl-Effizienz dagegen zum echten Faktor.

Beim Status-Code geht es um das Canonical-Signal. Google behandelt permanente Redirects (301, 308) als Signal, dass das Ziel die neue kanonische URL sein soll. Ein temporärer Redirect (302, 303, 307) sendet dieses Signal nicht — die Zielseite wird dann nur indexiert, wenn andere Canonical-Signale vorhanden sind, und man riskiert, dass die alte URL im Index bleibt (Google Search Central, Redirects). Wer aus Versehen einen 302 für eine permanente Migration setzt, übergibt die Ranking-Signale nicht zuverlässig. Welche Plugin-Einstellungen dabei kollidieren, klärt der Beitrag zu SEO-Plugins wie Yoast und Rank Math.