Das Wichtigste in Kürze
- Ein Website-Relaunch ist zuerst ein SEO-Projekt. Die meisten Traffic-Einbrüche sind ein Organisationsproblem: Niemand trägt am Go-Live-Tag klar die SEO-Verantwortung.
- Das URL-Mapping ist das Herzstück: jede alte URL nach Relevanz migrieren, konsolidieren (301) oder löschen (410).
- Die ersten 48 Stunden entscheiden. Eigene, vorab aufgesetzte Tools sind Pflicht, weil die Search Console als Frühwarnsystem zu langsam ist.
- KI-Sichtbarkeit ist der blinde Fleck 2026: Bei Marke- oder Domain-Wechseln setzt sich das Grounding trotz 301 teilweise zurück. Plane sie als eigenen Workstream.
- Die wichtigste Frage zuerst: Wer drückt am Tag des Go-Lives den roten Knopf?
Ein Website Relaunch ist ein SEO-Projekt und zugleich ein Technik- und Design-Projekt. Heikel wird er vor allem wegen der vielen Beteiligten: Redirects sind geplant, CMS-Features monatelang gebrieft, der Go-Live-Termin steht. Was fehlt, ist die Zuständigkeit am Tag der Migration. Wer leitet das Projekt, priorisiert Tickets im Ernstfall und ordnet SEO gegenüber den anderen Disziplinen ein?
In den letzten zehn Jahren habe ich Migrationen vom Mittelständler mit 10 Millionen Euro Umsatz bis zum Branchen-Champion mit 900 Millionen begleitet. Davor habe ich bei Rocket Internet Ventures wie Foodpanda, Delivery Hero, Linio und Dafiti gearbeitet. Nach Dutzenden Migrationen ist meine These simpel: Die teuerste Migration ist die, bei der niemand vorher die SEO-Verantwortung übernommen hat.
Dieser Leitfaden ist meine SEO-Migrations-Checkliste aus der Praxis, für alle, die einen Relaunch verantworten und danach möglichst wenig offene Fragen haben wollen.
Was ist ein Website Relaunch?
Ein Website-Relaunch ist jeder tiefe Eingriff in das, was Suchmaschinen, große Sprachmodelle (LLMs) und Nutzer*innen auf deiner Seite bewerten: Domain, URL-Struktur, CMS, Design, Navigation, Hosting, Template oder eine Kombination daraus. Ob SEO-Migration, Relaunch oder Website-Migration, gemeint ist meist derselbe Vorgang.
Wichtiger als das Label ist das Risikoprofil:
| Migrations-Typ |
Was sich ändert |
SEO-Risiko |
| Redesign |
Die Optik; URLs, Struktur und Technik bleiben |
Niedrig bis mittel |
| Replatforming |
CMS oder Shop-System (z. B. von OXID auf Shopify), oft samt Kundendaten und Bestellungen |
Mittel bis hoch |
| Domain-Migration |
Domain, Marke oder beides |
Sehr hoch, vor allem in KI-Systemen |
(Grafik: Risikoprofil nach Migrations-Typ)
Das "SEO Website Migration 1x1": aus 1 + 1 wird selten 2, es sei denn, du führst nach einer Übernahme zwei Plattformen zusammen. Sonst ist eine Migration vor allem Risikominimierung. Der Business Case ist defensiv: Geht es schief, verlierst du nachhaltig Umsatz.
Warum Website Relaunches aus SEO-Perspektive scheitern
Beim Relaunch passiert in den Suchmaschinen vieles gleichzeitig: Bots müssen neu crawlen, indexieren und bewerten, das Crawl-Budget (die Zahl der URLs, die Suchmaschinen pro Zeitfenster abrufen) verteilt sich auf neue Pfade, die Linkkraft externer Verweise wandert nur über saubere 301-Weiterleitungen mit, und Nutzersignale wie Klickrate und Verweildauer setzen sich zurück.
Ab dem Tag der Migration rechne ich mit vier bis acht Wochen bis zur Stabilisierung, und in dieser Phase verzeihen Suchmaschinen wenig. Erste Erkenntnisse gibt es aber sofort, weil Crawler jede Änderung zeitnah abgreifen. Die Zeiteinheit zur Fehlerkorrektur sollte sich in Stunden messen lassen, nicht in Tagen!
Die größten Fehler entstehen durch Unwissenheit, schlechte Umsetzung oder fehlende Ansprechpartner*innen. Letzteres vor allem, wenn niemand klar die SEO-Verantwortung trägt. Die Technik ist zwar komplex, aber beherrschbar. Woran Migrationen wirklich scheitern, ist die Organisation. Wer einen SEO-Relaunch plant, nimmt sie deshalb mindestens so ernst wie die Technik. Es nützt nichts, Fehler zu finden, wenn das Entwicklungsteam längst Feierabend hat.
Wo es konkret schiefläuft, sehe ich fast immer an den gleichen Stellen:
- URL-Mapping ist falsch oder zu oberflächlich? Bei Tausenden von URLs verliert man leicht den Überblick.
- URL-Mapping übergeben, einzelne Redirects greifen aber nicht? Crawle die alte Domain parallel mit Screaming Frog, damit keine URL durchs Raster fällt.
- Frontend und Backend werden getrennt ausgerollt? Plane zwei Wochen Feature-Freeze mit Recovery-Puffer und Rollback-Kriterien pro Komponente.
- Externe Agentur oder Dienstleister im Spiel? Lege vor dem Go-Live fest, wer in den ersten 24 Stunden für Hotfixes erreichbar ist.
- Go-Live-Timing ohne Puffer? Wer Donnerstag um 16 Uhr migriert, hat einen Tag für Hotfixes, danach nur den Wochenend-Notdienst. Plane den Go-Live Anfang der Woche.
- Migration mit Brand- oder Domain-Wechsel? Plane den Umzug von PR und Brand-Mentions parallel, sonst startest du in der KI-Suche bei null. Auch Feeds und das Google Business Profile müssen mitziehen.
- Ansprechpartner*innen gebrieft, aber Nachbereitung wackelt? Es braucht eine Checkliste und ein Backup, damit die Prüfungen pro Template-Typ standardisiert ablaufen, egal von wem.
Die beste Absicherung ist eine Staging-Umgebung: Läuft die Migration erst dort und dann kontrolliert live, fängst du die meisten Probleme ab, bevor sie live auftauchen.
Deine Taskforce: Wer trägt die Verantwortung?
Vor jedem Relaunch stelle ich dieselbe Frage: Wer entscheidet am Go-Live-Tag, ob die Migration weiterläuft oder zurückgerollt wird, und an wen meldest du Probleme, damit sie nach Business Case priorisiert werden? In sieben von zehn Projekten gibt es darauf keine klare Antwort, weil jede Disziplin für sich arbeitet und alle denken: Wird schon.
In komplexen Migrationen mit interner IT, Agentur, Content-Team und Marketing gibt es zu viele Übergaben. Greift eine Weiterleitung in der .htaccess (der Konfigurationsdatei des Webservers) nicht, fehlt ein Canonical-Tag (das HTML-Tag, das Google die maßgebliche URL-Version nennt) oder bleiben Meta-Daten leer, braucht es jemanden, der entscheidet und löst.
Vor jedem Kickoff lege ich deshalb eine Rollenverteilung fest, zusätzlich zur Aufgabenliste. Im Kern ist das eine einfache RACI-Logik: Eine Person ist accountable, die Teams sind responsible. Pro Team eine namentlich benannte Person samt Backup, erreichbar am Go-Live-Tag und danach:
| Rolle |
Owner |
Verantwortung |
| Gesamtsteuerung |
Eine Person mit Entscheidungsbefugnis (du) |
Ordnet SEO gegenüber Technik und Termin ein und entscheidet am Go-Live über den Rollback |
| Entwicklung |
CMS oder Shop-System (z. B. von OXID auf Shopify), oft samt Kundendaten und BestellungenEntwicklungsteam oder Agentur |
Redirects, Templates, Deployment, Canonicals, Meta-Daten |
| Server & Infrastruktur |
Dienstleister oder Dev-Team |
.htaccess, Statuscodes, DNS, Hosting |
| Analytics & Monitoring |
Analytics- oder Data-Team |
Tracking und Live-Checks der ersten 24 Stunden, Frühwarnsignale |
Für die Gesamtsteuerung gilt: Hier musst du sattelfest sein und je Problem einen Business Case liefern, falls nötig. Jede Rolle bekommt eine Reaktionszeit und einen Eskalationsweg, und hinter jedem Team steht ein konkreter Name. Das kostet zwei Stunden vorab und spart oft Wochen Recovery-Zeit.
Achtung bei großen Projekten: Hier werden gern Skripte ausgeführt, um die .htaccess zu generieren. Funktioniert etwas nicht, braucht es auch den Owner dazu.
Technische Must-Haves vor dem Go-Live
Vor jedem Go-Live hake ich eine Reihe technischer Bausteine ab und strukturiere eine transparente Checkliste.
URL-Mapping: das Herzstück der Migration
Das URL-Mapping ist die vollständige Liste aller alten URLs mit Zuordnung zu den neuen URLs inklusive einer Qualifizierung pro URL. Ein fehlendes Mapping ist die häufigste Einzelursache für Traffic-Verluste nach einem Relaunch. Grundlage jeder Entscheidung ist Relevanz: Bewerte jede URL anhand der KPIs, die du ohnehin monitorst, etwa GA4-Umsatz, Impressionen, Klicks, Position, Backlinks und KI-Erwähnungen. Kleiner Tipp: Gewichte die einzelnen Metriken und du bekommst ein Scoring-Modell als Orientierung.
Bei Boost it stecken wir an dieser Stelle enorm viel Aufwand rein, weil hier über Gewinn und Verlust der Migration entschieden wird.
(Grafik: Beispielhaftes URL-Scoring mit gewichteten Metriken)
Migrieren, konsolidieren oder löschen
Pro URL gibt es drei Optionen:
- Migrieren. Die Seite ist relevant und wird migriert, inklusive Inhalt, Meta-Daten, Bildern, Alt-Texten und interner Verlinkung.
- Konsolidieren. Mehrere schwächere Seiten fließen in eine stärkere. Du behältst die leistungsstärkste URL und leitest den Rest per 301 darauf. Das stärkt die Autorität, riskiert aber Umsatz, wenn die neue Seite nicht alle Suchintentionen der Vorgänger abdeckt. Detailliert prüfen.
- Löschen. Seiten ohne Traffic, Backlinks und strategische Bedeutung bekommen den Status 410. Tauchen doch noch Signale auf, etwa externe Links, leitest du per 301 auf die passende neue URL.
(Grafik: Redirect-Map, drei Entscheidungen pro URL)
Ein gesetzter 301 allein reicht jedoch nicht. Jede Weiterleitung braucht eine inhaltlich vollwertige Gegenseite. Meine Faustregel: Was vorher funktioniert hat, muss danach weiter funktionieren.
Auch Bilder, PDFs und Mediendateien haben URLs und gehören ins Mapping, und die interne Verlinkung zeigt direkt auf die neuen Ziele. Denk daran: Es ändert sich jede einzelne URL. Gib deshalb auch externen Marketingagenturen frühzeitig Bescheid, damit Feeds und Kampagnen angepasst werden.
Weitere technische Bausteine
Die folgenden Punkte prüfe ich vor jedem Go-Live:
- URL-Struktur. Kurz, sprechend, ohne Session-IDs oder dynamische Parameter, so weit ist es klar. Wichtiger ist, dass die Struktur vorab abgestimmt und dann konsequent angewendet wird.
- robots.txt und XML-Sitemap. Die robots.txt regelt, was Crawler dürfen. Die Sitemap zeigt ihnen, was sie crawlen sollen. Beide müssen am Go-Live auf die neue Website verweisen und in der Search Console eingereicht sein. Es hilft, die alte Sitemap übergangsweise online zu lassen. So crawlt Google die alten URLs erneut, erkennt die Weiterleitungen schneller und überträgt die Signale zügiger auf die neuen URLs. Bei einem Domain-Wechsel meldest du den Umzug zusätzlich über das Change-of-Address-Tool der Search Console. Das Gleiche gilt für die Bing Webmaster Tools, die eine eigene Funktion für Domain-Umzüge bieten.
- Canonical-Tags. Doppelte oder leere Canonicals sind ein klassischer Fehler beim Plattformwechsel. Hier schleichen sich oft simple Fehler ein, etwa ein falsches Protokoll, uneinheitliche Trailing Slashes oder eine nicht angepasste URL-Syntax.
- hreflang-Tags. Bei mehrsprachigen Seiten müssen die Sprach- und Länderverweise korrekt verknüpft sein. Ein Klassiker ist, dass sie nach dem Relaunch noch auf die alte Struktur zeigen.
- Staging-Umgebung. Die Testversion hältst du per robots.txt, Basic-Auth oder noindex-Header für Google unsichtbar. Indexierte Staging-Seiten kosten Vertrauen. Häufiger ist der umgekehrte Fehler: Die Staging-robots.txt oder ein sitewide noindex gehen versehentlich mit live, und plötzlich darf kein Crawler die Live-Seite besuchen.
- Core Web Vitals. Ladezeit, Interaktivität und visuelle Stabilität sind Ranking-Faktoren. Ein langsamerer Relaunch ist ein Rückschritt. Oft sind es unkomprimierte Bilder oder Videos, die den neuen Build ausbremsen.
- Strukturierte Daten. Das Schema-Markup für Produkte, Artikel und FAQ muss mindestens das alte Niveau halten.
- Backup und Rollback-Fähigkeit. Vor dem Go-Live sicherst du den alten Stand vollständig, inklusive Datenbank und Konfiguration. Nur so ist der Rollback aus der Taskforce mehr als ein Plan auf dem Papier. Stimm ihn vorab ab und kläre, bis zu welchem Schritt er überhaupt möglich ist.
- llms.txt, falls vorhanden. Behandle sie wie die robots.txt. Ändert sich das URL-Schema, müssen die dort gelisteten URLs mitziehen. Ein nachweislicher Ranking- oder Citation-Hebel für die KI-Suche ist sie nach heutigem Stand nicht. Manche Systeme erzeugen sie inzwischen automatisch, prüfe also, ob bei dir überhaupt eine existiert.
- Manueller Check. Einzelne Templates nach vorab definierten To-dos prüfen, von der Kategorieseite bis zum Checkout.
Wer einen detaillierten Projektplan aufsetzt, versieht jeden dieser Punkte mit klaren Verantwortlichkeiten.
_format(webp).webp)
.png)
