SEO-Strategie beim Website-Relaunch: So vermeidest du den Traffic-Einbruch
Stephan Stensky 10.6.2026
Wie du durch klare Verantwortlichkeiten, präzises URL-Mapping und GEO-Monitoring das organische Ranking und deine KI-Sichtbarkeit beim Systemwechsel sicherst
Inhalt
- Was ist ein Website-Relaunch?
- Warum Website-Relaunches aus SEO-Perspektive scheitern
- Deine Taskforce: Wer trägt die Verantwortung?
- Technische Must-haves vor dem Go-Live
- KI-Sichtbarkeit: der blinde Fleck 2026
- Die ersten 48 Stunden: Tools und Monitoring
- Zwei Migrationen, eine bittere Lehre
Das Wichtigste in Kürze
- Ein Website-Relaunch erfordert vorab eine klare personelle Verantwortung und festgelegte Eskalationspfade für den Tag der Migration, um Fehler sofort beheben zu können.
- Ein vollständiges URL-Mapping basierend auf aktuellen Leistungskennzahlen ist essenziell, um Traffic-Verluste durch falsche oder fehlende Weiterleitungen zu vermeiden.
- Bei einem Marken- oder Domainwechsel reicht eine saubere 301-Weiterleitung nicht mehr aus, weshalb die KI-Sichtbarkeit in Systemen wie ChatGPT oder Perplexity als eigener Workstream geplant werden muss.
- Für die kritischen ersten 48 Stunden nach dem Go-Live ist ein direktes Monitoring-Setup über Server-Logs und Crawler notwendig, da die Daten der Google Search Console zu verzögert einlaufen.
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 oder Delivery Hero betreut. Dieser Artikel 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 ist das Risikoprofil:
- Redesign: Die Optik ändert sich, URLs, Struktur und Technik bleiben. SEO-Risiko niedrig bis mittel.
- Replatforming: Das CMS- oder Shop-System wechselt, etwa von OXID auf Shopify. SEO-Risiko mittel bis hoch, weil sich viele technische Grundlagen gleichzeitig ändern und zusätzlich oft Kundendaten, Orders etc. migriert werden.
- Domain-Migration: Domain, Marke oder beides wechselt. SEO-Risiko sehr hoch, vor allem in KI-Systemen.
SEO-Migration-Risikoskala
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. Wer einen SEO-Relaunch plant, nimmt die Organisation 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 SEO Spider, 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 Kick-off lege ich eine Rollenverteilung fest, zusätzlich zur Aufgabenliste. Pro Team eine namentlich benannte Person samt Backup, erreichbar am Go-Live-Tag und danach:
- Accountability für die gesamte Migration: Eine Person mit Entscheidungsbefugnis über alle Disziplinen, die SEO gegenüber Technik und Termin einordnet und am Go-Live-Tag über den Rollback entscheidet. Hier musst du sattelfest sein und je Problem einen Business-Case liefern, falls nötig.
- Responsibility für die Entwicklung: Redirects, Templates, Deployment sowie fehlende Canonicals oder leere Meta-Daten. Meist das Entwicklungsteam oder die Agentur.
- Responsibility für Server und Infrastruktur: .htaccess, Statuscodes, DNS und Hosting, oft ein eigener Dienstleister oder auch das Dev-Team.
- Responsibility für Analytics und Monitoring: Tracking und die Live-Checks der ersten 24 Stunden, wo die Frühwarnsignale zusammenlaufen und auf konsistenten Daten beruhen müssen.
| 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 | Entwicklungsteam oder Agentur | Redirects, Templates, Deployment, Canonicals, Meta-Daten |
| Server und Infrastruktur | Dienstleister oder DEV-Team | .htaccess, Statuscodes, DNS, Hosting |
| Analytics und Monitoring | Analytics- oder Data-Team | Tracking und Live-Checks der ersten 24 h, Frühwarnsignale |
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.
SEO-Migration-Gewichtung-Relevanz
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.
SEO-Migration-URL-Mapping
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. Es ändert sich jede URL. Gib auch externen Marketingagenturen frühzeitig Bescheid, sodass Feeds und Kampagnen angepasst werden.
Weitere technische Bausteine
Die folgenden Punkte prüfe ich vor jedem Go-Live (Auszug):
- robots.txt und XML-Sitemap: Beide zum Go-Live aktualisieren und die neue Sitemap in der Search Console einreichen. Die alte übergangsweise online lassen, bei Domain-Wechsel das Change-of-Address-Tool nutzen.
- Canonical-Tags: Doppelte oder leere Canonicals sind ein Klassiker beim Plattformwechsel.
- hreflang-Tags: Sprach- und Länderverweise korrekt verknüpfen und nicht auf die alte Struktur zeigen lassen.
- Staging-Umgebung: Für Google unsichtbar halten und aufpassen, dass kein noindex versehentlich mit live geht.
- Core Web Vitals: Ladezeit und Stabilität sind Ranking-Faktoren, ein langsamerer Relaunch ist ein Rückschritt.
- Strukturierte Daten: Schema-Markup mindestens auf altem Niveau halten.
- Backup und Rollback: Den alten Stand vollständig sichern und klären, bis wohin der Rollback möglich ist, falls nötig.
- llms.txt, falls vorhanden: Wie die robots.txt behandeln. Ein nachweislicher Hebel für die KI-Suche ist sie nach heutigem Stand nicht.
- Manueller Check: einzelner Templates nach vorab definierten To-dos.
Wer einen detaillierten Projektplan für den Website-Relaunch aufsetzt, versieht jeden dieser Punkte mit klaren Verantwortlichkeiten.
KI-Sichtbarkeit: der blinde Fleck 2026
Klassische Migrations-Checklisten gehen davon aus, dass saubere 301-Weiterleitungen die Sichtbarkeit erhalten. Für klassische Suchsysteme stimmt das. In KI-Suchsystemen wie OpenAI ChatGPT, Perplexity, Claude und Google Gemini greift die Annahme nicht mehr.
KI-Antworten speisen sich aus zwei Quellen: aus dem, was ein Modell im Training über Marken und Domains gelernt hat, und aus dem, was es zur Laufzeit live aus dem Web abruft und zitiert. Ein 301 verschiebt deine Seiten, aber weder die gelernten Marken-Assoziationen noch die externen Erwähnungen, die dich zur vertrauenswürdigen Quelle gemacht haben. Bei einem reinen CMS-Wechsel mit gleicher Marke und Domain bleibt das Grounding stabil. Bei einer echten Brand- oder Domain-Migration setzt es sich teilweise oder ganz zurück, trotz sauberer 301-Weiterleitungen.
Was ich bei jeder Brand- oder Domain-Migration plane und heute noch wichtiger ist:
- PR-Shift parallel zum Go-Live, damit externe Quellen die neue Marke aufgreifen.
- Konsistente Brand-Mentions in Verzeichnissen, bei Wikipedia und in Branchen-Datenbanken anpassen.
- Eigenes GEO-Monitoring, doppelt aufgesetzt (Brand Alt und Brand Neu), das prüft, ob die neue Marke in KI-Antworten erscheint.
Die klassische SEO-Autorität bleibt auch für KI-Systeme zentral: Wer organisch stark ist und sauber zitiert wird, taucht auch in KI-Antworten eher auf. 301-Weiterleitungen bleiben Pflicht, die KI-Sichtbarkeit kommt als eigener Workstream dazu. Denk auch bei der Risk-Mitigation daran: Eine Konsolidierung von zwei Brands kann aus Brand- und Operations-Sicht schlau sein, aus Sicht der Suchsysteme aber eben nicht.
Die ersten 48 Stunden: Tools und Monitoring
Die ersten 48 Stunden nach dem Go-Live entscheiden, ob aus der Migration eine schnelle Stabilisierung oder ein dreimonatiges Aufräumprojekt wird. Stoßen Crawler dabei wiederholt auf 5xx-Fehler oder defekte Redirects, prägt sich das im Index ein und das Vertrauen sinkt.
Die Google Search Console allein reicht nicht, weil ihre Daten meist 48 bis 72 Stunden Verzögerung haben. Du brauchst eigene Drittanbieter-Tools und separat getrackte Projekte, die du nicht kurz vor dem Relaunch aufsetzen kannst, sonst fehlen die Referenzdaten.
Mein Monitoring-Stack für die ersten 48 Stunden:
- Screaming Frog SEO Spider: Tägliche Crawls der neuen Seite, bei Bedarf mehrmals, für sofortige Sicht auf 4xx, 5xx, fehlende Canonicals oder Meta-Daten. Praktisch: Screaming Frog MCP mit Claude hilft bei der Interpretation.
- Server-Log-Analyse: Tools wie der Screaming Frog Log File Analyser oder GoAccess zeigen live, welche URLs der Googlebot mit welchen Statuscodes abruft. Die einzige Quelle ohne Verzögerung, aber vorab aufzusetzen.
- Sistrix, Ahrefs, SE Ranking und Co. für Sichtbarkeitsindex und Ranking-Bewegungen der ersten zwei Wochen.
- Search Console und Bing Webmaster Tools: Indexierungsstatus und Crawl-Statistiken.
- KI-Monitoring via Peec AI, Profound oder PromptWatch, um zu prüfen, ob die Marke in OpenAI ChatGPT, Perplexity und Claude erscheint. Achtung: Du hast hier erst Referenzdaten, wenn du das Projekt aufsetzt.
- Deine Checkliste mit manuellem Template-Check. Wirkt altmodisch, ist aber das Einzige, das interne Raffinessen, Setup und Prioritäten berücksichtigt.
Eine Übersicht weiterer SEO-Tools wie Seobility oder neuroflash findest du auf OMR Reviews. Welche Kombination passt, hängt von Größe, CMS und Migrations-Typ ab.
Zwei Migrationen, eine bittere Lehre
Zwei kurze Fälle aus meiner Praxis.
Fall 1: CMS-Relaunch eines europäischen Ferienpark-Anbieters
Frontend und Backend wurden zeitgleich getauscht. Es gab URL-Mapping, Plan, Team, Staging, Feature-Freeze – eigentlich perfekt.
Was fehlte, war eine einzige Person mit klarer Verantwortung für verschiedenste Business-Units und externe Agenturen. In den ersten 36 Stunden traten in mehreren Sprachversionen Canonical-Probleme auf, die niemand zeitnah eskalierte, weil die Teamstruktur unheimlich komplex war und Redirects teilweise nicht funktionierten. Zwei Dev-Teams, Entwickler*innen in Indien, den USA und Australien. Ein Traum.
Fall 2: Shop-Migration einer Premium-D2C-Brand für Accessoires
In diesem Projekt hatte die Dev-Seite eine optimistische Timeline, jedoch keinerlei Mapping. In wenigen Tagen konnten wir unterstützen, um letztlich festzustellen: Alle Editorial-Inhalte wie How-tos, Guidelines, Styleguides etc. werden nicht migriert, da die Templates nicht stehen. Bis heute sind die Rankings nicht zurück. Klares Problem in vorherigen Abstimmungsrunden.
Beide Migrationen folgten einem Plan. Die Kommunikation war das Problem.
Drei Punkte zum Mitnehmen, wenn du selbst einen Relaunch planst:
- Klär die Verantwortung vor dem Kick-off. Accountability, Eskalationspfade und Erreichbarkeit zum Go-Live sind essenziell. Ein URL-Mapping ist Pflicht.
- Bau dir ein Monitoring über mehrere Systeme. Die Search Console allein ist als Frühwarnsystem zu langsam (Screaming Frog, Sistrix, Peec AI, ahrefs, manuelle Checklist).
- Plane die KI-Sichtbarkeit als eigenen Workstream. Bei Brand- oder Domain-Wechseln holen dich 301-Weiterleitungen in ChatGPT und Perplexity nicht zurück.
Wer einen Website-Relaunch plant, klärt deshalb die einfachste Frage zuerst: Wer drückt am Tag des Go-Lives den roten Knopf? Gibt es darauf keine klare Antwort, ist das der eine Punkt, den du diese Woche lösen solltest. Den Rest dieses Artikels kannst du danach abarbeiten, mit oder ohne externer SEO-Agentur an deiner Seite.
