SEO-Relaunch: So ziehen Sie um, ohne Rankings zu verlieren

Ein SEO-Relaunch ist der Umzug der Adressen, Inhalte und Signale einer bestehenden Website auf eine neue Struktur, ohne die erarbeiteten Rankings zu verlieren. Er ist zuerst eine Inventur-Aufgabe und gehört an den Anfang des Projekts, nicht in die Woche vor dem Go-live.

Dieser Beitrag setzt voraus, dass die Entscheidung für den Relaunch gefallen ist. Umfang, Budget, Dauer und Agenturauswahl behandelt unser Leitfaden zum Website-Relaunch. Hier geht es um den Umzug selbst: die Tabelle, die Sie aufbauen, die Regeln für die Weiterleitungen, die Prüfungen auf Staging und das Monitoring danach.

Rankings fallen nach einem Relaunch aus mechanischen Gründen, nicht aus rätselhaften. Eine URL, die einen Fehler zurückgibt, verlässt den Index. Eine Seite, die es nicht mehr gibt, rankt nicht mehr. Interne Links, die ins Leere zeigen, übertragen keine Signale mehr. Nichts davon ist Pech, und alles davon lässt sich mit einer vor dem Go-live erstellten Tabelle verhindern.

Was die Sichtbarkeit wirklich kostet:

• Fehlende Weiterleitungen. Die alte Adresse liefert einen Fehler, und die Seite fällt samt allem heraus, was sie aufgebaut hat.
• Gelöschte Seiten. Eine Seite stillzulegen, die organische Einstiege brachte, entfernt diesen Traffic, mit oder ohne Relaunch.
• Zerbrochene interne Verlinkung. Links sorgen für Auffindbarkeit und signalisieren Wichtigkeit. Eine neue Navigation, die auf alte Adressen zeigt, beschädigt beides.
• Pauschal neu geschriebene Titel und Überschriften. Sie beschreiben, worum es auf einer Seite geht. Alle auf einmal zu ersetzen ändert, wofür die Seite relevant ist.
• Inhalte, die erst im Browser entstehen. Versteckt der neue Aufbau den Hauptinhalt hinter JavaScript, wird er womöglich gar nicht indexiert.

Was die Sichtbarkeit entgegen vieler Checklisten nicht kostet: eine rein gestalterische Überarbeitung bei unveränderten URLs und unveränderten Inhalten, denn dabei bewegt sich kaum etwas, was für die Suche zählt. Und eine temporäre Weiterleitung überträgt Signale sehr wohl: Laut Google Search Central übermitteln serverseitige Weiterleitungen Ranking- und Kanonisierungssignale. Der Grund für die dauerhafte Variante ist, dass sie den Umzug als endgültig meldet, nicht dass die andere Wert verlöre.

Diese Unterscheidung entscheidet, wohin das Budget fließt: in die URL-Inventur und die Redirect-Karte, nicht in das Umschreiben von Metadaten, die bereits funktioniert haben.

Die Mapping-Tabelle ist das eine Dokument, auf dem der gesamte Umzug läuft, und sie entsteht, bevor es Vorlagen gibt. Jede alte Adresse bekommt eine Zeile, jede Zeile eine Entscheidung. Eine URL ohne festgehaltene Entscheidung gilt als unbearbeitet, und genau so entdecken Firmen ihre Verluste sechs Wochen nach dem Go-live aus einem 404-Bericht.

Bauen Sie sie aus sechs Quellen in dieser Reihenfolge auf. Keine einzelne Quelle ist vollständig, und genau deshalb sind es sechs:

1. Indexierte URLs aus der Search Console, unter Indexierung und dann Seiten.
2. Ein vollständiger Crawl der aktuellen Website.
3. Die geltenden Sitemaps.
4. Seiten mit organischen Einstiegen und Conversions aus der Webanalyse.
5. URLs, auf die externe Links zeigen.
6. Ein Inhaltsexport aus dem CMS, der veröffentlichte, aber unverlinkte Seiten aufdeckt.

Diese Reihenfolge ist Branchenpraxis und keine Vorgabe von Google. Das gehört dazugesagt, weil die meisten Checklisten ihre eigene Reihenfolge so darstellen, als wäre sie dokumentiert. Dokumentiert ist, was passiert, wenn eine Adresse übersehen wird.

Die folgende Tabelle ist die Spezifikation, mit der wir arbeiten. Eine Liste mit Tipps herunterzuladen bringt wenig; eine Spaltenstruktur bringt etwas, weil sie das ist, was Sie tatsächlich ausfüllen.

Weiterleitungen folgen drei Regeln, und alle drei sind dokumentiert und keine Geschmacksfrage. Dauerhaft weiterleiten, wenn der Umzug dauerhaft ist. Jede Weiterleitung in einem Hop auflösen. Und sie mindestens ein Jahr bestehen lassen. Wer beim Relaunch Rankings verliert, verletzt meist eine dieser drei.

Dauerhaft, weil der Umzug dauerhaft ist. Laut Google Search Central teilt eine dauerhafte Weiterleitung mit, dass die ursprüngliche URL nicht mehr ausgeliefert werden soll. Genau dieses Signal wollen Sie, wenn eine Seite endgültig umgezogen ist.

Ein Hop, niemals eine Kette. Alt direkt auf neu. Ketten aus alt, Zwischenadresse und neu verbrauchen Crawl-Anfragen und schaffen Fehlerquellen. Das passiert leicht unbeabsichtigt: Eine Slug-Änderung, der Monate später eine zweite folgt, erzeugt eine Kette, sofern die erste Weiterleitung nicht auf die endgültige Adresse umgehängt wird. Prüfen Sie die Karte als Arbeitsschritt auf Ketten, nicht aus Gewohnheit.

Mindestens ein Jahr behalten. Die Google-Hinweise zum Website-Umzug nennen ein Jahr als Mindestdauer, länger schadet nicht. Beachten Sie die Richtung dieser Aussage: Es ist eine Untergrenze, kein Verfallsdatum. Es gibt keinen Grund, eine Weiterleitung zu entfernen, solange die alte Adresse Zugriffe erhält oder externe Links trägt.

Eine weitere Entscheidung gehört hierher: was mit bewusst entfernten Seiten geschieht. Leiten Sie nur dorthin weiter, wo es eine wirklich gleichwertige Seite gibt. Eine stillgelegte Seite auf die Startseite zu leiten, weil irgendetwas geschehen muss, ist schlechter als ein sauberer Fehlercode, weil es für jeden, der dem Link folgt, ein unpassendes Ziel erzeugt.

Mehrsprachige Websites tragen ein zusätzliches Fehlerbild, und es ist das, welches die meisten Checklisten vollständig auslassen. Ändern sich URLs in mehreren Sprachen gleichzeitig, brechen die Auszeichnungen, die diese Sprachversionen verbinden, im selben Moment, und das Ergebnis ist die falsche Sprachversion im falschen Markt.

Drei Anforderungen müssen nach dem Umzug erfüllt sein. Laut der Google-Dokumentation zu lokalisierten Versionen müssen Sprachauszeichnungen auf kanonische URLs verweisen, jede Version muss alle anderen einschließlich ihrer selbst aufführen, und für nicht abgedeckte Sprachen lässt sich ein Standardeintrag angeben.

Praktisch heißt das: Die Sprachauszeichnungen werden im Rahmen des Go-live gegen die neuen Adressen neu erzeugt und nicht den Weiterleitungen überlassen. Eine Weiterleitung sagt einem Crawler, wohin eine Seite gezogen ist; sie repariert keine Auszeichnung, die weiterhin auf die alte Adresse zeigt.

Hier zahlt sich eine stabile Kennung aus. Hat jede Sprache ihren eigenen lokalisierten Slug, muss etwas anderes als der Slug die Versionen verbinden. Eine dauerhafte Kennung, die sich nie ändert, auch wenn sich jede sichtbare Adresse ändert, macht das Neuerzeugen der Auszeichnungen maschinell statt manuell. Diese eine Entwurfsentscheidung würden wir als Erstes wiederholen; mehr dazu in unserem Beitrag zur Website-Architektur und Suchsichtbarkeit.

Auf Staging wird der Umzug verifiziert, und dazu gehört ein Schalter, der in der richtigen Reihenfolge umgelegt werden muss. Staging vor Arbeitsbeginn von der Indexierung ausschließen, die Produktion zum Go-live freigeben. Diese beiden zu vertauschen ist eine der häufigsten Arten, einen Monat zu verlieren, denn eine indexierte Staging-Umgebung ist zugleich ein Index- und ein Dublettenproblem.

Was vor dem Umschalten geprüft wird:

• Auflösung der Weiterleitungen. Die vollständige Liste alter URLs gegen Staging laufen lassen und bestätigen, dass jede in einem Hop am vorgesehenen Ziel ankommt. Die Liste prüfen, nicht eine Stichprobe.
• Interne Links zeigen auf finale Adressen. Nicht durch eine Weiterleitung. Inhalte ebenso prüfen wie Navigation und Schaltflächen, denn sie liegen getrennt.
• Canonical-Tags verweisen auf die neuen URLs. Selbstreferenzierend, nicht auf die alte Seite.
• Sprachauszeichnungen referenzieren einander, in beide Richtungen.
• Inhaltsgleichheit. Die neue Seite trägt die Substanz, die die alte hat ranken lassen. Eine Seite, die beim Umzug die Hälfte ihres Inhalts verliert, verliert den Grund ihrer Relevanz.
• Rendering. Bestätigen, dass der Hauptinhalt ohne Ausführung im Browser vorhanden ist. Laut Google Search Central rendert der Googlebot JavaScript, das Rendering ist jedoch verzögert und ressourcenabhängig, sodass erst danach entstehende Inhalte eher übersehen werden.
• Sitemaps. Aus der neuen Struktur erzeugt, mit korrekten Änderungsdaten.

Halten Sie das Ergebnis jeder Prüfung in der Mapping-Tabelle fest und nicht im Kopf. Die Statusspalte existiert, damit unvollständige Prüfung sichtbar wird statt angenommen.

Die folgende Checkliste ist nach Phasen gegliedert und nicht nach Themen, weil die Reihenfolge sie überhaupt erst wirksam macht. Punkte, die in der falschen Phase erledigt werden, sind genau die, die durchrutschen. Jeder Eintrag ist eine Handlung mit überprüfbarem Ergebnis und keine Ermahnung zur Sorgfalt.

Vor dem Inhalts-Stopp

1. Indexierte URLs aus der Search Console exportieren.
2. Die aktuelle Website vollständig crawlen und mit dem Export abgleichen.
3. Seiten mit organischen Einstiegen und Conversions aus der Webanalyse ziehen.
4. URLs mit externen Links zusammentragen.
5. Die Mapping-Tabelle mit allen URLs aus allen Quellen aufbauen, dedupliziert.
6. Für jede Zeile eine Entscheidung festhalten: behalten, weiterleiten, zusammenführen oder entfernen.
7. Position und Zugriffe der wichtigsten Seiten als Ausgangswert festhalten.

Auf Staging

1. Bestätigen, dass Staging von der Indexierung ausgeschlossen ist.
2. Weiterleitungen umsetzen und die gesamte Liste alter URLs dagegen testen.
3. Auf Ketten und Schleifen prüfen; jede Weiterleitung löst in einem Hop auf.
4. Interne Links auf finale Adressen umhängen, in Inhalten wie in der Navigation.
5. Canonical-Tags und Sprachauszeichnungen prüfen.
6. Inhaltsgleichheit der Seiten mit dem größten Suchwert prüfen.
7. Bestätigen, dass der Hauptinhalt ohne JavaScript-Ausführung vorliegt.

Am Go-live-Tag

1. Produktion für die Indexierung freigeben und prüfen, danach prüfen, dass Staging weiterhin ausgeschlossen ist.
2. Neu erzeugte Sitemaps einreichen.
3. Live-Weiterleitungen ein zweites Mal gegen die Liste stichprobenartig prüfen, in der Produktion.
4. Mit einem echten Versand bestätigen, dass Analytics, Ziele und Formular-Tracking auf den neuen Vorlagen auslösen.

In den ersten Wochen

1. Indexabdeckung auf Ausschläge bei Fehlern und ausgeschlossenen Seiten beobachten.
2. Die Ausgangswert-Seiten einzeln vergleichen.
3. Neu auftauchende 404 durch zusätzliche Zeilen in der Mapping-Tabelle beheben, damit sie die maßgebliche Quelle bleibt.
4. Weiterleitungen bestehen lassen, mindestens ein Jahr.

Jede Ursache für Trafficverlust nach einem Relaunch lässt sich danach einordnen, wie stark der Beleg dafür ist, und diese Einordnung ändert, was man dagegen tut. Von Google dokumentierte Ursachen bekommen Entwicklungszeit. Behauptungen ohne dokumentierte Grundlage bekommen Skepsis, insbesondere die mit konkreten Erholungszeiträumen.

Die folgende Tabelle trennt beides. Die letzte Zeile lohnt zweimaliges Lesen: Ein numerischer Erholungszeitraum ist nirgends dokumentiert. Google nennt zu erwartende Schwankungen während der erneuten Signalverarbeitung und keine Dauer. Angaben wie neunzig Tage oder drei bis sechs Monate stammen aus einzelner Anbietererfahrung ohne offengelegte Methodik, und das ist eine andere Klasse von Aussage als eine Dokumentation.

Beantworten Sie diese Frage stattdessen mit dem Mechanismus: Veränderungen werden sichtbar, sobald Google die betroffenen URLs erneut crawlt, je nach Crawl-Frequenz binnen Tagen bis Wochen, und die Konsolidierung der Signale über Weiterleitungen braucht weitere Zeit, die Google nur qualitativ beschreibt.

Im Mai 2026 hat diese Website ihren gesamten Inhaltsbestand in fünf Sprachen gleichzeitig auf lokalisierte URLs umgezogen. Das ist der Fall, den andere Migrationsleitfäden am schlechtesten behandeln, weil sich die Fehlerbilder vervielfachen, wenn jede Sprache am selben Tag ihre Adresse wechselt. Die folgende Darstellung stammt aus der Versionsgeschichte und nicht aus der Erinnerung.

Die Reihenfolge der Schritte, auf die es ankommt:

1. Eine stabile Kennung kam in die Inhaltsverzeichnisse, bevor irgendetwas umbenannt wurde. Jeder Beitrag behielt eine dauerhafte Kennung, während jede Sprache ihren eigenen sichtbaren Slug bekam. Ohne das durchtrennt ein Slug-Wechsel in fünf Sprachen die Verbindung zwischen den Sprachversionen.
2. Die Sprachauszeichnungen wurden auf explizite Pfade umgestellt, bevor die Slugs sich bewegten, nicht danach. Andersherum hätte es ein Zeitfenster mit defekten Sprachsignalen gegeben.
3. Slugs erzeugt, dann Dateien umbenannt. Ein einzelner Umbenennungs-Commit veränderte 491 Dateien.
4. Redirect-Karte gebaut, dann in den Build eingehängt. Stand 3. August 2026 enthält sie 383 dauerhafte Weiterleitungen. 358 davon sind Blog-URLs, also 93 % der Karte, und Spanisch und Französisch tragen je 96 Einträge, jeweils 25 % der Gesamtzahl.
5. Interne Links in den Inhalten wurden auf finale Adressen umgeschrieben, damit die interne Verlinkung nicht durch Weiterleitungen läuft.
6. Sitemaps mit Sprachalternativen, danach die Markdown-Spiegel und der maschinenlesbare Index.

Was schiefging, und das ist nützlicher als die Teile, die funktionierten:

Der erste Durchgang über die internen Links übersah Felder, die nicht wie Links aussahen. Schlüssel, die nach Handlungsaufforderungen benannt waren statt nach URLs, blieben unbearbeitet, und ein nachfassender Commit war nötig. Die Lehre lässt sich verallgemeinern: nach der Form des Werts scannen, nicht nach dem Feldnamen.

Drei Tage später zeigte sich eine zweite Lücke. Links innerhalb der Markdown-Inhalte waren vom Durchgang über die strukturierten Felder nicht erfasst und mussten separat repariert werden. Inhalte in zwei Darstellungsformen brauchen zwei Durchgänge, und der zweite ist der, den man vergisst.

Ein drittes Problem tauchte danach auf: fehlende Änderungsdaten in der statischen Sitemap, bemerkt nach dem Go-live statt davor.

Ein Traffic-Ergebnis dieser Migration nennen wir bewusst nicht. Es gibt keine isolierte Messung dafür, weil im selben Zeitraum laufend Inhalte hinzukamen. Der Wert der Darstellung liegt in der Abfolge und in den Fehlern, nicht in einer Zahl.

Das Monitoring nach dem Go-live betrifft einzelne Seiten und keine Gesamtsumme. Eine seitenweite Trafficlinie bewegt sich aus vielen Gründen und sagt nicht, ob der Umzug funktioniert hat. Die Seiten, die Sie als die wichtigsten notiert haben, einzeln gegen den festgehaltenen Ausgangswert geprüft, sagen es.

Was zu beobachten ist, in der Reihenfolge, in der es aussagekräftig wird:

• Indexabdeckung. Neue Fehler und neu ausgeschlossene Seiten erscheinen hier zuerst und deuten meist auf eine fehlende Weiterleitung oder einen gesperrten Pfad.
• Crawl-Aktivität auf den alten Adressen. Solange Google sie noch abruft, wird der Umzug noch verarbeitet.
• Die Ausgangswert-Seiten, eine nach der anderen. Position und Impressionen je Seite, verglichen mit dem Stand vor dem Inhalts-Stopp.
• Neue 404. Jeder einzelne ist eine Zeile, die in der Mapping-Tabelle gefehlt hat. Tragen Sie ihn in die Tabelle ein und nicht nur in die Serverkonfiguration, damit die Tabelle maßgeblich bleibt.
• Rendering der neuen Vorlagen, falls sich der Rendering-Ansatz geändert hat.

Widerstehen Sie dem Drang, in den ersten Tagen einzugreifen. Fehlerhafte Weiterleitungen und echte Fehler gehören sofort korrigiert, aber Titel umzuschreiben oder Seiten umzubauen, während sich die Signale noch konsolidieren, macht es unmöglich zu erkennen, welche Änderung was bewirkt hat. Die weiterführende Arbeit danach behandelt unser Beitrag zur Optimierung nach dem Launch.

Wenn Sie den Umzug lieber von Leuten durchführen lassen, die ihn über fünf Sprachen hinweg gemacht haben, gehört das zu unseren SEO-Leistungen.