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
Entwicklungsteam 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.
Der Zeitplan: von T-30 bis T+90
Eine Migration läuft über Monate und folgt drei Phasen. Meine Checkliste hängt an jeder Phase konkrete Aufgaben und Verantwortlichkeiten auf:
| Phase | Zeitraum | Fokus |
|---|
| Pre-Launch | T-30 bis T-7 | URL-Mapping finalisieren, Staging testen, Rollen verteilen, Monitoring und Referenzdaten aufsetzen |
| Launch | T-0 | Go-Live früh in der Woche, Live-Checks pro Template, Hotfix-Bereitschaft |
| Post-Launch | T+0 bis T+90 | Monitoring über mehrere Systeme, Indexierung und Rankings tracken, Recovery dokumentieren |
Die komplette Checkliste mit allen Aufgaben, Prüfpunkten und Verantwortlichkeiten gibt es als Google Sheet. [Link zur Checkliste einsetzen]
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 ChatGPT, Perplexity, Claude und Gemini greift die Annahme nicht mehr, und genau dort läuft die Recherche deiner Zielgruppe längst mit.
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. Dieses Zusammenspiel heißt Grounding. Ein 301 verschiebt deine Seiten. Die gelernten Marken-Assoziationen und die externen Erwähnungen, die dich zur vertrauenswürdigen Quelle gemacht haben, bleiben davon unberührt. 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.
Wie schnell sich das Grounding nach einem Wechsel neu bildet, hängt von der Quelle ab:
| Quelle | Zieht nach der Migration mit? | Dein Hebel |
|---|
| Deine eigenen URLs | Schnell und meist zuverlässig, am sichersten in Googles Modellen | Sauberes URL-Mapping und 301-Weiterleitungen |
| Externe Erwähnungen und Zitate | Verzögert | PR-Shift zum Go-Live, wichtige Quellen vorab informieren, Verzeichnisse und Wikipedia aktualisieren |
| Trainingswissen der Modelle | Langsam und nur teilweise, relevant erst bei Marke- plus Domain-Wechsel | Konsistente Brand-Mentions, GEO-Monitoring, Geduld |
[Grafik: Wie schnell zieht jede Quelle mit?]
Ein harter, endgültiger Reset ist das also nicht. Mit PR, konsistenten Signalen und Zeit bildet sich das Grounding neu, bei starken Marken messbar schneller. Genau deshalb gehören diese drei Hebel in jeden Plan mit Brand- oder Domain-Komponente:
- 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:
| Tool / Quelle | Wofür | Wann aufsetzen |
|---|
| Screaming Frog | Tägliche Crawls: 4xx, 5xx, fehlende Canonicals, leere Meta-Daten. Praktisch: Screaming Frog MCP mit Claude hilft bei der Interpretation | Vor dem Go-Live, inklusive Crawl der alten Seite als Referenz |
| Server-Log-Analyse (Log File Analyser, GoAccess) | Live-Sicht, welche URLs der Googlebot mit welchen Statuscodes abruft. Die einzige Quelle ohne Verzögerung | Vorab |
| Sistrix, ahrefs, SE Ranking | Sichtbarkeitsindex und Ranking-Bewegungen der ersten zwei Wochen | Mehrere Wochen vorab, für Referenzdaten |
| Search Console und Bing Webmaster Tools | Indexierungsstatus, Crawl-Statistiken, Change-of-Address | Bestehend, Daten mit 48 bis 72 Stunden Verzögerung |
| KI-Monitoring (Peec AI, Profound, PromptWatch) | Erscheint die Marke in ChatGPT, Perplexity und Claude? | Vorab, sonst fehlen Referenzdaten |
| Manuelle Checkliste mit Template-Check | Interne Raffinessen, Setup und Prioritäten | Vor dem Go-Live definieren, samt Backup-Person |
Der manuelle Template-Check wirkt altmodisch, ist aber das Einzige, das deine internen Besonderheiten berücksichtigt. Welche Tool-Kombination passt, hängt von Größe, CMS und Migrations-Typ ab.
Vier Migrationen aus der Praxis
Fall 1: CMS-Relaunch eines europäischen Ferienpark-Anbieters. Frontend und Backend wurden zeitgleich getauscht. Es gab URL-Mapping, Plan, Team, Staging und 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.
[Screenshot: GSC-Verlauf Fall 1]
Fall 2: Shop-Migration einer Premium-D2C-Brand für Accessoires. Die Dev-Seite hatte eine optimistische Timeline, jedoch keinerlei Mapping. In wenigen Tagen konnten wir unterstützen, um letztlich festzustellen: Alle Editorial-Inhalte wie How-tos, Guidelines und Styleguides werden nicht migriert, weil die Templates nicht stehen. Bis heute sind die Rankings nicht zurück. Ein klares Versäumnis aus den vorherigen Abstimmungsrunden.
[Screenshot: GSC-Verlauf Fall 2]
Fall 3: Shop-Migration eines Premium-Süßwaren-Anbieters. Hier war die Taskforce klar besetzt. In den ersten 48 Stunden fanden wir per Log-File-Analyse rund 800 URLs, die der Googlebot abrief, die aber in der Redirect-Map fehlten. Die Korrektur lief innerhalb von zwölf Stunden. Die Sichtbarkeit lag nach sechs Wochen wieder über dem Niveau vor dem Launch.
Fall 4: Brand-Migration einer Tech-Plattform. Neue Domain, neuer Markenname, technisch sauber umgesetzt. Die organische Google-Sichtbarkeit erholte sich nach acht Wochen. Die KI-Sichtbarkeit erholte sich nicht von allein. Sie brauchte rund sechs Monate gezielte PR-Arbeit und neue Brand-Citations.
Alle vier Migrationen folgten einem Plan. Den Unterschied machten Verantwortung, Kommunikation und Monitoring. Bei den Rocket-Internet-Ventures war die Lehre dieselbe: Die teuerste Migration ist die, bei der niemand vorher die SEO-Verantwortung übernommen hat.
Drei Punkte zum Mitnehmen, wenn du selbst einen Relaunch planst:
- Klär die Verantwortung vor dem Kickoff. 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, ahrefs, Peec, manuelle Checkliste).
- 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 Leitfadens kannst du danach abarbeiten, mit oder ohne externe SEO-Agentur an deiner Seite. Und wenn du dabei Unterstützung willst: Genau solche Migrationen begleiten wir bei Boost it. [interner Link: Kontakt oder Service-Seite]
FAQ: Website Relaunch und SEO
Wie lange dauert die Erholung nach einem Website Relaunch?
Bei sauberer Migration rechne ich mit vier bis acht Wochen bis zur Stabilisierung. Erste Signale liefern Crawler sofort, deshalb sollte sich die Zeiteinheit zur Fehlerkorrektur in Stunden messen lassen, nicht in Tagen. Schwere Fehler wie ein fehlendes URL-Mapping kosten schnell sechs Monate und mehr.
Verliert man durch einen Relaunch zwangsläufig Rankings?
Nein. Kurzfristige Schwankungen in den ersten Wochen sind normal. Nachhaltige Verluste entstehen fast immer durch fehlendes URL-Mapping, kaputte Weiterleitungen oder unklare Verantwortung, und genau diese drei Punkte lassen sich vorab lösen.
Was ist ein URL-Mapping?
Die vollständige Liste aller alten URLs mit Zuordnung zu den neuen, inklusive einer Entscheidung pro URL: migrieren, konsolidieren (301) oder löschen (410). Ein fehlendes Mapping ist die häufigste Einzelursache für Traffic-Verluste nach einem Relaunch.
301 oder 410: Was ist wann richtig?
301 für jede relevante Seite mit inhaltlich vollwertiger Gegenseite. 410 für Seiten ohne Traffic, Backlinks und strategische Bedeutung. Tauchen später doch Signale auf, etwa externe Links, ziehst du einen 301 auf die passende neue URL nach.
Was bedeutet Grounding in der KI-Suche?
KI-Antworten speisen sich aus zwei Quellen: dem im Training gelernten Wissen über Marken und Domains und dem, was Modelle zur Laufzeit live aus dem Web abrufen und zitieren. Dieses Zusammenspiel heißt Grounding. Ein 301 verschiebt deine Seiten. Die gelernten Marken-Assoziationen und externen Erwähnungen bleiben davon unberührt.
Brauche ich eine llms.txt?
Als Hebel für die KI-Suche nach heutigem Stand: nein. Es gibt keinen belastbaren Nachweis, dass eine llms.txt Rankings oder KI-Zitate verbessert. Falls vorhanden, behandle sie wie die robots.txt und halte die gelisteten URLs nach der Migration aktuell.
Wann ist der beste Zeitpunkt für den Go-Live?
Früh in der Woche, mit Puffer für Hotfixes und außerhalb deiner Hauptsaison. Wer Donnerstagnachmittag migriert, hat einen Tag für Korrekturen und danach nur den Wochenend-Notdienst.
Über den Autor
Stephan Stensky ist Gründer von Boost it, einer Agentur für holistisches, organisches Wachstum mit Fokus auf SEO, GEO und Performance Marketing. Vor Boost it begleitete er bei Rocket Internet globale Ventures wie Foodpanda, Delivery Hero, Linio und Dafiti bei Wachstum, Internationalisierung und Migrationen. Heute arbeitet er mit ambitionierten Marken daran, dort sichtbar zu sein, wo Entscheidungen fallen: in Suchsystemen, in KI-Antworten und überall dort, wo sich die relevante Zielgruppe befindet.
LinkedIn: https://www.linkedin.com/in/stephanstensky/
_format(webp).webp)
.png)
