URLs migrieren, ohne Ihre Rankings zu verlieren

Die Migration, die "eigentlich keinen Einfluss auf SEO haben sollte", hat immer Einfluss auf SEO

Stellen Sie sich vor, ein Team entscheidet, dass aus /products.php?id=4471&cat=12 /products/oak-dining-table werden soll. Alle sind sich einig, dass das überfällig ist — die neuen URLs sind sauberer, leichter zu teilen, besser für das Redesign. Das Marketing gibt grünes Licht, weil es "nur eine URL-Änderung ist, der Inhalt bleibt ja gleich". Wochen nach dem Launch bricht der organische Traffic deutlich ein, und niemand hatte das eingeplant.

Das ist der am leichtesten vermeidbare Ranking-Verlust im SEO, und er passiert ständig, weil eine URL-Migration wie eine technische Randnotiz aussieht — dabei ist sie in Wirklichkeit etwas ganz anderes: Sie bitten Google, jahrelang aufgebautes Vertrauen von einer Adresse auf eine andere zu übertragen, Adresse für Adresse, ohne Spielraum für "passt schon ungefähr".

Diszipliniert umgesetzt ist eine Migration fast unsichtbar — ein kurzer Einbruch, der sich innerhalb weniger Wochen erholt. Nachlässig umgesetzt wird daraus ein monatelanges Loch im Traffic, das ein Redesign niemals verursachen sollte. Der Unterschied liegt fast ausschließlich in drei unspektakulären Artefakten: der Redirect-Map, den Canonical-Tags und der Sitemap. Bekommen Sie diese drei richtig hin, ist der Rest der Migration ganz normale Engineering-Arbeit.

Erstellen Sie die Redirect-Map, bevor Sie auch nur eine URL anfassen

Die Redirect-Map ist eine Tabelle, keine Regel. Jede alte URL bekommt eine konkrete neue URL. Kein Muster, kein Fallback auf die Startseite, kein "der Redirect wird das schon regeln" — eine Zeile pro URL, alt zu neu, von einem Menschen geprüft.

Das ist genau dort am wichtigsten, wo man am ehesten versucht ist, es zu überspringen: bei Query-String-URLs. ?category=lighting&sort=price_asc&page=2 ist keine einzelne URL, sondern eine kombinatorische Explosion davon, und die meisten dieser Varianten haben keinen echten Ranking-Wert — sie sind Crawl-Rauschen, das Ihr CMS versehentlich erzeugt hat. Die Disziplin besteht darin, sie in zwei Kategorien zu trennen:

• URLs, die tatsächlich ranken und Traffic bekommen. Ziehen Sie diese aus dem Performance-Bericht der Search Console und Ihrer Analytics, nicht aus einem Datenbank-Export. Wenn eine parametrisierte URL in den letzten 12-16 Monaten Impressionen und Klicks erzielt hat, bekommt sie einen expliziten 1:1-Redirect auf ihr sauberes Äquivalent.
• URLs, die reines Rauschen sind. Facettierte Filter, Session-IDs, Tracking-Parameter, Sortierreihenfolgen. Diese sollten einen 404 liefern oder auf die nächstgelegene Kategorieseite umleiten — sie haben nie erhaltenswerten Linkwert aufgebaut, und Tausende davon einzeln zu erfassen verschwendet Zeit, die Sie besser in die wirklich relevanten URLs investieren.

Wer diese Triage überspringt, landet entweder dabei, alles auf die Startseite umzuleiten (was Google ab einem gewissen Volumen als Soft-404-Muster einstuft), oder versucht, jede jemals existierende Parameterkombination per 301 umzuleiten (wodurch die Redirect-Map zu etwas aufgebläht wird, das niemand mehr pflegen oder überprüfen kann).

Redirects: ein Hop, der richtige Code, keine Ausnahmen

Sobald die Map steht, sind die Regeln für die Umsetzung einfach und unnachgiebig:

• 301, nicht 302. Ein 302 signalisiert Crawlern, dass der Umzug vorübergehend ist, was beeinflusst, welche URL Google als kanonisch behandelt und wie schnell umgestellt wird — Google hat erklärt, dass 301 und 302 Ranking-Signale ähnlich weitergeben, der eigentliche Preis eines 302 hier also nicht verlorener Linkwert ist, sondern ein langsamerer, weniger sicherer Übergang. Bei einer dauerhaften Änderung der URL-Struktur ist 301 von Tag eins an das korrekte, eindeutige Signal.
• Immer nur ein Hop. A leitet auf B um, nicht A auf B auf C. Ketten verwässern das Signal mit jedem zusätzlichen Hop, verlangsamen das Crawling und gehören zu den häufigsten Dingen, die kaputt sind, wenn jemand anderes eine Migration bereits "abgeschlossen" hat. Lassen Sie Ihre komplette Redirect-Map vor dem Launch durch einen Crawler wie Screaming Frog laufen und suchen Sie gezielt nach Ketten und Schleifen.
• Interne Links ebenfalls aktualisieren. Ein korrekter Redirect entschuldigt nicht, dass Navigation, Footer und Links im Content weiterhin auf alte URLs zeigen. Jeder interne Link, der noch auf einen Redirect zeigt, ist ein verschwendeter Crawl-Request und ein etwas schwächeres Signal als ein direkter Link. Reparieren Sie die Links — der Redirect soll ein Sicherheitsnetz sein, nicht der Hauptweg.
• Redirects deutlich länger als Googles genanntes Minimum aktiv lassen. Googles eigene Richtlinie verlangt mindestens ein Jahr Redirect-Pflege nach einem Site-Umzug. Alte Backlinks, Lesezeichen und gecachte Links laufen nicht nach Ihrem Zeitplan ab — behandeln Sie das eine Jahr also als Untergrenze, nicht als Ziel. Redirects genau zu diesem Zeitpunkt abzuschalten, ist ein häufiger Weg, um Linkwert von Links zu verlieren, die noch da draußen existieren.

Canonical-Tags erledigen Aufräumarbeiten, die die Redirect-Map nicht leisten kann

Websites mit Query-String-URLs haben so gut wie immer Duplicate-Content-Probleme, die die Migration lösen sollte, statt sie weiterzuschleppen. Existieren sowohl /product?id=4471 als auch /product?id=4471&ref=email, müssen beide — nach dem Redirect — auf dieselbe saubere URL auflösen, und diese saubere URL braucht ein selbstreferenzierendes Canonical-Tag. Lassen Sie die alten Parametervarianten nicht als auf sich selbst kanonisierte Seiten überleben — das verschiebt das Duplicate-Content-Problem nur in Ihre neue URL-Struktur, statt es zu lösen.

Prüfen Sie das vor dem Launch, nicht danach: Ziehen Sie jede indexierte URL aus dem Pages-Bericht der Search Console (unter Indexierung), gruppieren Sie sie nach dem sauberen Ziel, auf das sie zusammenlaufen sollen, und bestätigen Sie, dass das Canonical-Tag auf diesem Ziel auf sich selbst zeigt — nicht zurück auf ein Legacy-Muster, das ein Template versehentlich beibehalten hat.

Die Reihenfolge bei der Sitemap zählt mehr, als man denkt

Die Reihenfolge, in der Sie Ihre Sitemap anfassen, verändert tatsächlich, wie schnell Google die Migration neu verarbeitet:

1. Vor dem Launch: Stellen Sie sicher, dass Ihre aktuelle Sitemap genau widerspiegelt, was heute live ist. Eine veraltete Sitemap von vor der Migration ist eine schlechte Ausgangsbasis für den späteren Abgleich.
2. Beim Launch: Veröffentlichen Sie eine neue Sitemap, die nur die neuen, sauberen URLs enthält — keine weitergeleiteten URLs, keine Parametervarianten. Reichen Sie sie sofort in der Search Console ein.
3. Für 2-4 Wochen danach: Lassen Sie die alte Sitemap erreichbar (nicht löschen), damit Googles Crawler die darin gelisteten Redirects noch finden und verarbeiten kann, statt sie nur über langsameres, beiläufiges Crawling zu entdecken.
4. Nach diesem Zeitraum: Nehmen Sie die alte Sitemap außer Betrieb. Die Redirects selbst bleiben aktiv — Sie hören lediglich auf, Crawler aktiv auf die alte Map zu lenken, sobald sie ihren Zweck erfüllt hat.

Beobachten Sie in diesem Zeitraum täglich den Pages-Bericht: Die Zahl bei "Page with redirect" sollte steigen, die Zahl bei "Not found (404)" sollte konstant bleiben. Ein 404-Anstieg mitten in der Migration bedeutet eine Lücke in Ihrer Redirect-Map — nicht etwas, das Google einfach umschifft.

So sieht der Ranking-Einbruch aus, wenn alles richtig gemacht wurde

Selbst eine fehlerfreie Migration verursacht einen echten Einbruch — das ist kein Warnsignal, sondern Google, das neu crawlt und Signale den neuen Adressen zuordnet. So sieht eine gesunde Migration aus: Rankings schwächen sich für ein paar Wochen ab, die meisten Positionen erholen sich danach, und innerhalb weniger Monate liegen Sie auf Augenhöhe oder darüber (saubere URLs plus was auch immer sonst im Redesign mitgekommen ist) — wobei der genaue Zeitrahmen mit Crawl-Frequenz und Website-Größe variiert. So sieht eine ungesunde Migration aus: Der Einbruch vertieft sich weit über den ersten Monat hinaus, 404-Fehler tauchen im Pages-Bericht auf, und der Traffic hat sich bis zum dritten Monat nicht erholt. Diese Lücke zwischen "erwartetem Einbruch" und "Traffic-kostendem Fehler" lässt sich vollständig durch die oben genannte Redirect-Map, den Canonical-Audit und die Sitemap-Sequenzierung erklären — einen vierten, mysteriösen Grund gibt es selten.

Fazit

Eine URL-Migration ist keine Redirect-Regel und ein Stoßgebet. Sie ist eine Tabelle, die jede URL, die Traffic erzielt hat, auf genau ein neues Ziel abbildet, ein Canonical-Audit, das die Duplicate-Content-Lücken schließt, die die alte Struktur verdeckt hat, und eine Sitemap-Sequenz, die Google mitteilt, was sich geändert hat, ohne das Signal im Rauschen zu vergraben. Erledigen Sie diese drei Dinge diszipliniert, und der Einbruch dauert ein paar Wochen, nicht ein paar Quartale. Wenn Sie eine Änderung der URL-Struktur planen und die Redirect-Map vor dem Launch gebaut und geprüft haben wollen, statt sie erst nach dem Traffic-Einbruch zu flicken — unser SEO-Team plant genau diese Art von Migration vor dem Launch, nicht danach.