25. Oktober 2026 · 10 Min.

URL-Migration ohne SEO-Schiffbruch: erst messen, dann umleiten

Google hat am 23. Oktober seine URL-Empfehlungen präzisiert. So entscheidet man, welche Adressen wirklich geändert werden müssen — und migriert mit Mapping, 301/308, Canonicals und Monitoring ohne unnötiges SEO-Risiko.

URL-Migration ohne SEO-Schiffbruch: erst messen, dann umleiten

Eine schönere URL ist noch kein guter Migrationsgrund

Google hat seine Dokumentation zu crawlbaren URL-Strukturen am 23. Oktober 2026 aktualisiert und die Empfehlung zu Worttrennern präzisiert: Bindestriche markieren Wortgrenzen klarer als Unterstriche. Gleichzeitig bleiben die wichtigeren Grundlagen unverändert: URLs müssen technisch crawlbar, stabil, verständlich und frei von unnötiger Variantenexplosion sein.

Die gefährliche Reaktion auf so eine Aktualisierung lautet: „Dann ersetzen wir morgen alle Unterstriche.“ Eine bestehende URL ist aber nicht nur Text. Sie kann indexiert sein, externe Links tragen, in Kampagnen stehen, von Kunden gespeichert worden sein und in Analytics-Zeitreihen vorkommen. Jede Änderung ist eine Migration mit Übergangsphase.

Dieser Artikel zeigt deshalb zwei Dinge getrennt: wie neue URLs sauber entworfen werden und wie bestehende URLs nur dann umziehen, wenn der Nutzen das Risiko rechtfertigt.

Was Google tatsächlich empfiehlt

Die aktualisierte URL-Dokumentation nennt klare technische und redaktionelle Leitplanken:

Wörter nach Möglichkeit mit Bindestrichen statt Unterstrichen trennen;
lesbare Begriffe statt langer, undurchsichtiger IDs verwenden;
Wörter in der Sprache des Publikums nutzen;
reservierte Zeichen korrekt percent-encoden;
Inhalte nicht allein über URL-Fragmente wie #produkt wechseln;
Parameter mit = und & in einer üblichen Form schreiben;
unnötige Parameter entfernen;
Groß- und Kleinschreibung bewusst behandeln, weil URLs case-sensitive sind;
für regionale Seiten eine nachvollziehbare Struktur wie /de/ oder /en/ verwenden.

Das sind Empfehlungen für Verständlichkeit und effizientes Crawling, kein Versprechen auf einen Ranking-Sprung durch Kosmetik. Vor allem sagt die Dokumentation nicht, dass jede bestehende URL mit Unterstrich sofort ersetzt werden muss.

Neue URLs: langweilig ist gut

Eine gute neue URL erklärt Inhalt und Hierarchie ohne internes Datenmodell offenzulegen. Für einen deutschsprachigen Ratgeber über Wärmepumpen ist zum Beispiel /de/ratgeber/waermepumpe-kosten/ verständlicher als /index.php?id=481&cat=7.

Wir verwenden dafür wenige stabile Regeln:

Kleinbuchstaben für Pfade und Slugs.
Bindestriche als Worttrenner.
Eine Sprache pro Locale-Pfad.
Keine Session-ID, Tracking-ID oder Sortierung im kanonischen Pfad.
Keine Jahreszahl, wenn der Inhalt dauerhaft aktualisiert wird.
Keine CMS-Kategorie, die voraussichtlich bald umbenannt wird.
Ein Inhalt, eine bevorzugte kanonische URL.

„Kurz“ ist dabei kein Selbstzweck. /p/42 ist kürzer, aber weniger verständlich als /produkte/hafenlampe/. Stabilität und Bedeutung schlagen minimale Zeichenanzahl.

Bindestrich gegen Unterstrich: kein Anlass für Aktionismus

Google empfiehlt Bindestriche, weil sie eine Wortgrenze signalisieren. Unterstriche werden historisch häufiger verwendet, um zusammengehörige Begriffe zu markieren — etwa in Funktionsnamen. Für neue Slugs ist die Entscheidung damit einfach: Bindestrich.

Für eine bereits indexierte Adresse ist die Entscheidung anders. Wir ändern /summer_clothing/ nicht isoliert, nur um /summer-clothing/ zu erhalten. Zuerst prüfen wir:

hat die alte URL organische Klicks und Impressionen?
besitzt sie relevante externe Links?
wird sie in Newslettern, PDFs, Apps oder Anzeigen genutzt?
entstehen ohnehin weitere strukturelle Verbesserungen?
können alte und neue Adresse dauerhaft korrekt betrieben werden?

Wenn nur der Trenner schöner wird, ist der erwartete Nutzen meist zu klein für eine Migration. Wenn gleichzeitig Taxonomie, Sprache oder technische Plattform bereinigt werden, kann die Änderung Teil eines geplanten Umzugs sein.

Vor jeder Änderung ein URL-Inventar

Eine Migration scheitert oft nicht am Redirect-Code, sondern an vergessenen Adressen. Deshalb verbinden wir mehrere Quellen:

XML-Sitemaps und CMS-Export;
aktuelle interne Links aus einem vollständigen Crawl;
Search-Console-Seiten und Suchanfragen;
Webserver- oder CDN-Logs;
Analytics-Landingpages;
bekannte Backlinks;
Anzeigen, E-Mails, QR-Codes, PDFs und App-Deep-Links.

Jede gefundene URL erhält Status, Traffic, wichtigste Sprache, gewünschtes Ziel und verantwortlichen Owner. Varianten mit Großbuchstaben, Slash-Unterschieden, Parametern oder alten Dateiendungen werden nicht vorschnell gelöscht. Sie sind Hinweise auf reale Zugriffswege.

Das Inventar ist zugleich die spätere Prüfliste. Was vor der Migration nicht bekannt ist, kann danach kaum zuverlässig überwacht werden.

Die Entscheidungsmatrix: behalten, zusammenführen, umziehen, entfernen

Nicht jede URL braucht ein neues Gegenstück. Wir ordnen sie in vier Gruppen:

Behalten: Inhalt und Adresse passen. Kein Redirect nötig.

Zusammenführen: Mehrere sehr ähnliche Seiten werden zu einer substanziellen Zielseite. Alte URLs dürfen auf dieses relevante gemeinsame Ziel zeigen.

Umziehen: Inhalt bleibt im Wesentlichen gleich, erhält aber eine neue Adresse. Dafür gibt es ein direktes 1:1-Mapping.

Entfernen: Inhalt existiert nicht mehr und hat keinen sinnvollen Ersatz. Dann ist ein echter 404- oder 410-Status ehrlicher als ein Redirect zur Startseite.

Google warnt ausdrücklich davor, viele unpassende alte URLs pauschal auf eine einzelne Seite umzuleiten. Das verwirrt Nutzer und kann als Soft 404 behandelt werden. Ein Redirect ist eine Aussage über inhaltliche Nachfolge, kein Besen für Fehlerberichte.

Ein Mapping ist ein Vertrag

Das zentrale Migrationsartefakt ist eine versionierte Tabelle mit mindestens:

alter vollständiger URL;
neuer vollständiger URL oder gewünschtem 404/410;
Redirect-Typ;
Locale;
altem und neuem Canonical;
Status von internen Links, Sitemap und hreflang;
Teststatus;
fachlichem Owner.

Für große Sites ergänzen wir Priorität, Traffic und Backlinks. Das Mapping wird von Redaktion, Entwicklung und SEO gemeinsam geprüft. So landet ein alter Produktberater nicht versehentlich auf einer Produktkategorie, nur weil der Pfad ähnlich aussieht.

Ein gutes Mapping ist vollständig und deterministisch: Eine alte URL hat genau ein beabsichtigtes Ergebnis. Reguläre Ausdrücke dürfen die technische Umsetzung vereinfachen, ersetzen aber nicht die fachliche Zuordnung.

301 oder 308 — Hauptsache permanent und serverseitig

Google empfiehlt für dauerhafte Umzüge serverseitige permanente Redirects. 301 und 308 sind dafür geeignete Signale; der neue Zielort soll in den Suchergebnissen erscheinen. Ein temporärer 302 oder 307 signalisiert dagegen, dass die Quell-URL möglicherweise die bevorzugte Adresse bleiben soll.

Für eine normale Content-Migration ist die praktische Reihenfolge:

direkte serverseitige 301- oder 308-Weiterleitung;
Ziel antwortet mit 200;
Ziel-Canonical zeigt auf sich selbst;
keine Zwischenstation;
keine JavaScript-Weiterleitung, wenn der Server es lösen kann.

Ob 301 oder 308 zum Stack passt, hängt unter anderem davon ab, wie HTTP-Methoden behandelt werden. Für normale GET-Seiten ist wichtiger, dass der Status dauerhaft, konsistent und direkt ist.

Redirect-Ketten sind technische Schulden

Nach mehreren Relaunches entsteht schnell alt → weniger alt → neu → neu mit Slash. Google kann mehrere Hops verfolgen, empfiehlt aber direkte Ziele und möglichst kurze Ketten. Jede zusätzliche Station kostet Latenz, macht Fehler wahrscheinlicher und belastet den Betrieb.

Beim nächsten Umzug schreiben wir deshalb nicht nur Redirects vom letzten Stand. Jede bekannte historische URL wird direkt auf das endgültige Ziel aktualisiert. Danach testen wir:

curl -I https://example.com/alter-pfad

Die erwartete Antwort enthält genau einen permanenten Redirect und anschließend eine 200-Seite. Ein automatischer Test sollte Kreise, mehrfache Hops, externe Ziele und Redirects auf Fehlerseiten melden.

Canonical, Sitemap und interne Links müssen dieselbe Geschichte erzählen

Ein Redirect allein reicht nicht, wenn andere Signale widersprechen. Nach dem Umzug sollten:

interne Links direkt auf die neuen URLs zeigen;
jede neue Seite ein selbstreferenzierendes Canonical besitzen;
die neue XML-Sitemap nur kanonische Ziel-URLs enthalten;
hreflang-Verweise die neuen Locale-URLs verbinden;
strukturierte Daten und Open-Graph-URLs aktualisiert sein;
alte URLs aus Navigation, Footer und Content verschwinden;
temporäre noindex-Regeln entfernt sein.

Google nennt Sitemap, Canonical und Redirect unterschiedlich starke Signale. Sie müssen nicht technisch identisch funktionieren, sollten aber dieselbe bevorzugte URL benennen. Widersprüche verlängern die Übergangsphase und erschweren die Diagnose.

Parameter kontrollieren, nicht alle verbieten

Parameter sind nicht grundsätzlich schlecht. Filter, Pagination oder Kampagnenmessung können sie brauchen. Problematisch wird es, wenn Kombinationen unendlich viele fast gleiche crawlbare URLs erzeugen.

Wir unterscheiden deshalb:

inhaltlich relevant: Parameter verändert sichtbaren, eigenständig nützlichen Inhalt;
darstellend: Sortierung oder Ansicht ändert sich, Inhalt bleibt weitgehend gleich;
messend: UTM- oder Referral-Parameter;
zustandsbezogen: Session, Warenkorb oder persönliche Ansicht.

Nur die erste Gruppe ist ein Kandidat für indexierbare URLs. Mess- und Session-Parameter gehören nicht in Canonicals oder interne Navigationslinks. Bei facettierter Navigation definieren wir ausdrücklich, welche Kombinationen crawlbar sein sollen, statt jede denkbare Filterfolge zu verlinken.

JavaScript-Routing braucht echte Adressen

Google rät davon ab, Fragmente zu verwenden, um den Hauptinhalt einer Seite zu wechseln. /produkte#lampen und /produkte#stuehle sind aus Sicht eines modernen Routings keine verlässlichen eigenständigen Content-URLs.

Eine Single-Page-App sollte für indexierbare Zustände die History API und echte Pfade verwenden. Jede wichtige URL muss:

direkt aufrufbar sein;
beim Reload denselben Inhalt liefern;
serverseitig oder per statischem Export eine brauchbare Antwort geben;
einen eigenen Title, H1, Canonical und Statuscode haben;
ohne vorherige Client-Navigation erreichbar sein.

Tabs, Akkordeons und rein lokale UI-Zustände dürfen Fragmente nutzen. Der Test ist einfach: Soll genau dieser Zustand über Suche gefunden und geteilt werden? Dann braucht er meist eine echte URL.

Locales nicht nur übersetzen, sondern verbinden

Google nennt Locale-Verzeichnisse wie /de/ und /en/ als verständliche Option für internationale Sites. Entscheidend ist Konsistenz:

jede Sprache besitzt eine eigene stabile URL;
hreflang verweist wechselseitig auf passende Übersetzungen;
Canonical bleibt innerhalb derselben Sprache, sofern es keine echte Dublette ist;
Sprachumschalter führt auf das inhaltliche Gegenstück, nicht pauschal auf die Startseite;
Sitemap und Navigation enthalten dieselben Locale-Pfade.

Bei einer Migration braucht jede Sprachversion ihr eigenes Mapping. Ein deutscher Altpfad darf nicht aus Bequemlichkeit auf eine englische Seite zeigen, wenn eine deutsche Nachfolge existiert.

Rollout: erst im Test, dann bei niedriger Last

Google empfiehlt, eine neue Site gründlich zu testen, das Mapping vorzubereiten und einen Umzug möglichst in einer verkehrsärmeren Phase zu starten. Für kleine und mittlere Websites kann ein gemeinsamer Umschaltpunkt klarer sein; sehr große Sites können abschnittsweise migrieren.

Unser Ablauf:

Vorher: Staging crawlen, Mapping vollständig testen, Canonicals und Statuscodes prüfen, neue Sitemap vorbereiten, Monitoring-Dashboard speichern.

Umschalten: Redirects und neue Seiten gemeinsam veröffentlichen, internen Cache leeren, Sitemap einreichen, Stichproben über verschiedene Templates durchführen.

Erste 48 Stunden: 404/5xx, Redirect-Schleifen, Crawlrate, Serverlast und wichtigste Landingpages eng beobachten.

Folgewochen: Indexierung alter und neuer URLs, Klicks, Impressionen, Canonical-Auswahl und Backlinks vergleichen. Temporäre Schwankungen sind laut Google normal.

Redirects nicht nach dem ersten grünen Dashboard löschen

Google empfiehlt, Redirects möglichst lange und generell mindestens ein Jahr zu behalten. Aus Nutzersicht kann ein dauerhafter Betrieb sinnvoll sein, solange alte Links, Lesezeichen, PDFs oder QR-Codes existieren.

Nach dem Launch aktualisieren wir trotzdem alle kontrollierbaren Links auf das direkte Ziel. Redirects bleiben als Sicherheitsnetz, nicht als regulärer Navigationsweg. So sinken Latenz und Serverlast, ohne alte Zugänge abzuschneiden.

Ein Kalendertermin „Redirects nach drei Monaten löschen“ ist daher keine Aufräumstrategie. Die Entscheidung braucht Daten zu verbleibenden Requests und externen Verweisen.

Die Abnahmeliste für eine sichere URL-Migration

Jede alte URL hat ein fachlich passendes Ziel oder einen bewussten 404/410.
Permanente Umzüge nutzen direkte serverseitige 301/308.
Es gibt keine Schleifen und keine vermeidbaren Ketten.
Neue Ziele liefern 200 und selbstreferenzierende Canonicals.
Interne Links, hreflang, strukturierte Daten und Social-Metadaten sind aktualisiert.
Die Sitemap enthält nur neue kanonische URLs.
robots.txt und noindex blockieren die neuen Seiten nicht.
Groß-/Kleinschreibung und Slash-Regeln sind konsistent.
Filter- und Tracking-Parameter erzeugen keine indexierbare Variantenflut.
Search Console, Logs und Analytics werden gegen die gespeicherte Baseline überwacht.
Redirects bleiben mindestens ein Jahr und bei realer Nutzung länger aktiv.

Stabile URLs gewinnen gegen perfekte URLs

Die neue Google-Empfehlung macht eine gute Konvention für künftige Seiten noch klarer: lesbare Wörter, Bindestriche, wenige Parameter und echte crawlbare Pfade. Sie macht bestehende URLs mit Unterstrich aber nicht plötzlich wertlos.

Unser pragmatischer Rat lautet daher: neue Adressen sauber bauen, alte nur mit einem belegbaren Produkt- oder Strukturgrund ändern. Wenn eine Migration nötig ist, behandeln wir sie wie ein Release — mit Inventar, Mapping, Tests, direktem Rollback und mehreren Wochen Monitoring. So entsteht eine bessere Informationsarchitektur, ohne die bereits aufgebaute Auffindbarkeit leichtfertig über Bord zu werfen.

Quellen