Website Relaunch Teil 3: Rankings, Signale und AI Visibility sicher migrieren

Ein Relaunch überträgt keine Seiten. Er überträgt ein Signalsystem. Das war schon 2020 so, nur bestand dieses System damals aus URLs, Links, Inhalten und ein bisschen Markup. Inzwischen hängt daran eine zweite Ebene: ob Retrieval-Systeme deine Inhalte noch erreichen, verstehen und als Quelle verwenden können.

Die gute Nachricht zuerst, weil sie ein paar Budgets rettet: Du brauchst dafür keine separate KI-Migration. Google hat das im Mai 2026 in einem eigenen Dokument ungewöhnlich deutlich formuliert. Die generativen Funktionen der Suche greifen auf dieselben Crawling-, Indexierungs- und Ranking-Systeme zurück wie die normale Suche, und wer für generative Suche optimiert, betreibt aus Googles Sicht schlicht SEO. Dort steht auch, dass Sonderdateien wie llms.txt von Google Search nicht verwendet werden und dass Content-Chunking nicht nötig ist. (Google Search Central: Optimizing your website for generative AI features on Google Search, veröffentlicht 15.05.2026, zuletzt aktualisiert 10.07.2026)

Damit ist die Frage beantwortet, ob du für den Relaunch eine zusätzliche Maßnahmenliste brauchst. Brauchst du nicht.

Die schlechte Nachricht: Genau weil AI Search auf demselben Fundament steht, treffen es dieselben Fehler. Ein blockierter Crawler, eine kaputte Weiterleitungskette, eine Seite, die nach dem Relaunch ihre konkreten Fakten verloren hat und nur noch Marketingprosa enthält. Das kostet dich in beiden Systemen, und in einem davon merkst du es später, weil du es nicht misst.

Für deine Kalkulation heißt das: Der zusätzliche Aufwand für den AI-Search-Teil eines Relaunches liegt nicht bei zusätzlichen Maßnahmen, sondern bei zusätzlicher Prüfung und zusätzlicher Messung. Das sind, je nach Größe der Website, ein bis drei Personentage. Was auf dem Spiel steht, ist die Position in einem Kanal, in dem du nicht siehst, dass du fehlst, weil niemand nicht klickt.

Search Continuity heißt: Nach dem Relaunch findet ein Suchsystem dieselben Informationen unter einer eindeutig zugeordneten neuen Adresse wieder. Nicht dieselbe Seite, dieselbe Information.

Entitätssignale sind die Angaben, mit denen deine Website sagt, wer du bist, was du anbietest, wer die Inhalte verfasst hat und wo das Unternehmen sitzt. Autorenseiten, Impressum, Über-uns, Organization-Markup, Breadcrumbs, konsistente Firmen- und Produktnamen.

Zitierfähige Passage ist ein Absatz, der auch dann verständlich bleibt, wenn man ihn aus der Seite herauslöst. Ein Absatz, der mit "Darüber hinaus ist zu beachten" beginnt, ist es nicht.

AI Visibility heißt: In welchen KI-Antworten du auftauchst, mit welcher URL, und ob sich das reproduzieren lässt. Nicht: wie viele Leute von dort auf deine Website klicken.

Baseline ist der Startwert, gegen den du misst. Ohne sie kannst du nach dem Go-live nur noch behaupten, dass etwas besser oder schlechter geworden ist. Mehr dazu in meinem Beitrag zur Baseline für SEO und AI Search.

Ich schreibe seit Jahren, dass man Behauptungen mit eigenen Daten prüfen sollte, statt sie weiterzureichen. Im Mai 2026 hatte ich unfreiwillig Gelegenheit dazu, weil ich meine eigene Website umgezogen habe.

Die Ausgangslage

Das ist bewusst der einfachste denkbare Fall. Keine neue Domain, kein gleichzeitiger Content-Umbau, saubere 1:1-Zuordnung. Wenn hier etwas lange dauert, dauert es bei komplexeren Projekten länger, nicht kürzer.

Was Google gemacht hat

Aus der Search Console, Tagesauflösung:

Drei Tage bis zur ersten Sichtbarkeit der neuen URLs. Fünfeinhalb Wochen, bis die alten vollständig aus der Ausspielung verschwunden waren. Dazwischen ein langer Übergang, in dem beide Adressen parallel ausgeliefert wurden, bei einzelnen Suchanfragen sogar mit besserer Position auf der alten URL.

Was die KI-Systeme gemacht haben

Für die zweite Messachse habe ich meine Rankscale-Daten ausgewertet, gefiltert auf vier getrackte Prompts rund um Relaunch und Domainwechsel. Rankscale läuft täglich gegen mehrere Engines und protokolliert, welche URLs in den Antworten als Quelle auftauchen.

Die Zitationen auf meine eigene Domain in 30-Tage-Fenstern:

Der letzte Tag, an dem eine alte URL überhaupt noch als Quelle auftauchte, war der 22.06.2026. Das sind 42 Tage nach dem Go-live.

Die eigentliche Zahl

Vier Tage Unterschied.

Das ist deshalb relevant, weil derzeit reihenweise Beiträge behaupten, KI-Systeme bräuchten nach einer Migration pauschal Wochen oder Monate länger als Google. In meinem Fall stimmt das nicht. Bei sauberen Weiterleitungen, kleiner Website und ohne Domainwechsel liefen beide Systeme praktisch synchron.

Der Übergang ist wichtiger als das Ende

Interessanter als der Endpunkt ist das mittlere Fenster. Vom Go-live bis Anfang Juni wurden alte und neue URL fast gleich häufig zitiert, 15 zu 16. Derselbe Text, zwei Adressen, gleichzeitig als Quelle in Antworten auf dieselben Fragen.

Das hat eine praktische Konsequenz, die in keiner Relaunch-Checkliste steht: In den ersten sechs Wochen nach einem Relaunch sind deine AI-Visibility-Werte nicht vergleichbar. Wenn dein Monitoring die Sichtbarkeit pro URL zählt, verteilt sich deine Sichtbarkeit über zwei Adressen und sieht auf beiden halbiert aus. Wenn du in dieser Phase einen Report an die Geschäftsführung schickst, erklärst du gerade einen Einbruch, den es nicht gibt.

Miss in dieser Zeit auf Domain- oder Themenebene, nicht auf URL-Ebene. Und dokumentiere den Go-live-Termin in deinem Monitoring-Tool als Annotation, sonst diskutierst du in einem halben Jahr über eine Kurve, deren Ursache niemand mehr weiß.

Der Slash, der mich 25 Stunden gekostet hat

Beim Abgleich der Datenquellen ist mir etwas aufgefallen, das ich fast übersehen hätte. Die Search Console führt die alte URL mit abschließendem Slash:

/seo-wissen/seo-relaunch-domainwechsel/

Rankscale führt dieselbe URL ohne:

/seo-wissen/seo-relaunch-domainwechsel

Ich hatte das zunächst für ein reines Auswertungsproblem gehalten. Dann habe ich die Serverlogs geöffnet, und daraus wurde ein Vorfall.

Die neun 404 fielen alle in ein Fenster von rund 25 Stunden, vom 11.05. um 16:57 Uhr bis zum 12.05. um 18:11 Uhr. Betroffen waren:

Die Ursache lag bei mir, genauer bei einem Problem auf der Hostingseite während der Umstellung. Das alte System hatte slash-lose Aufrufe selbst auf die Variante mit Slash umgeleitet. Nach dem Wechsel griff die neue Weiterleitungsregel zunächst nur auf die Variante mit Slash. Wer ohne anfragte, bekam für einen Tag einen 404 statt eines 301.

Drei Dinge daran sind bemerkenswert.

Erstens: Betroffen waren ausgerechnet die beiden Seiten, um die es in diesem Artikel geht, plus zwei weitere zentrale Themenseiten.

Zweitens: In der Search Console taucht davon nichts auf. Googlebot war zu diesem Zeitpunkt noch gar nicht da, er kam erst am 14.05. Der Fehler war zu dem Zeitpunkt längst behoben. Ohne Logfile hätte ich nie erfahren, dass er existiert hat.

Drittens, und das ist der eigentliche Punkt: Die slash-lose Form ist genau die, in der Rankscale die URL gespeichert hat. Es ist also nicht so, dass Systeme immer die kanonische Schreibweise anfragen. Sie fragen die Form an, die sie gespeichert haben, und die kann von deiner abweichen.

Was du daraus mitnimmst: Teste vor dem Go-live beide Varianten jeder alten URL, mit und ohne abschließenden Slash. Und normalisiere Citation-Exporte, bevor du sie gegen deine Redirect-Tabelle hältst: Protokoll, www-Präfix, abschließender Slash, Groß- und Kleinschreibung, Query-Parameter. Ein einfacher Textvergleich liefert dir sonst null Treffer, und du schließt daraus, dass keine alten URLs mehr angefragt werden.

Ein Befund am Rande, der die Priorität verschiebt

Über die letzten zwölf Monate war meine Domain in diesem Fragencluster die am häufigsten zitierte Quelle: 294 Zitationen verteilt auf fünf URLs. Zum Vergleich landete sistrix.de bei 252 Zitationen, allerdings verteilt auf 15 URLs.

Das ist kein Grund zur Zufriedenheit, sondern eine Einordnung. Eine kleine Website kann in einem eng umrissenen Fachthema mehr Zitationen einsammeln als ein etabliertes Toolportal, wenn die Inhalte spezifisch genug sind. Und sie kann diese Position bei einem schlecht gemachten Relaunch in wenigen Wochen verlieren, ohne dass es jemand bemerkt, weil keine Klicks ausbleiben, die vorher da waren.

Grenzen dieses Falls

Damit klar ist, was du hier mitnehmen kannst und was nicht:

• Das ist ein Fall, keine Studie. Eine Website, ein Migrationstyp, ein Zeitraum.

• Die Zitationsdaten stammen aus Monitoring-Läufen, nicht aus organischen Nutzerabfragen. Ein Tool stellt täglich dieselben Fragen. Das ist ein brauchbares Messinstrument, aber es bildet nicht ab, was reale Nutzer fragen.

• Die 30-Tage-Fenster sind vom Auswertungszeitpunkt aus gerechnet und decken sich nicht exakt mit Kalendermonaten.

• Aus "keine Zitationen mehr sichtbar" folgt streng genommen "unterhalb der Auswertungsschwelle", nicht "null".

• Die Logauswertung endet am 15.07.2026. Die Aussage "mindestens 65 Tage" ist eine Untergrenze, kein Endwert.

• Bots werden im Log über das User-Agent-Feld erkannt. Das ist ein selbst gesetztes Textfeld und lässt sich fälschen. Ich habe die Zahlen nicht gegen die von den Anbietern veröffentlichten IP-Bereiche verifiziert.

Was du daraus ableiten kannst: Die Behauptung, KI-Systeme bräuchten nach Migrationen grundsätzlich sehr viel länger als Google, ist zumindest nicht allgemeingültig. Was du nicht ableiten kannst: dass es bei dir genauso läuft.

Die dritte Achse: was die Serverlogs zeigen

Search Console und Rankscale messen Ergebnisse. Die Serverlogs messen den Vorgang selbst. Ausgewertet habe ich 43.889 Bot-Zugriffe auf die Hauptdomain zwischen dem 30.04. und dem 15.07.2026, ohne einen einzigen fehlenden Tag.

Das Ergebnis passt nicht zu den beiden anderen Achsen:

Google-Impressionen und Crawler-Zugriffe sind Tageswerte, die Crawler-Kurve ist ein gleitender Sieben-Tage-Durchschnitt. Die KI-Zitationen liegen nur als 30-Tage-Fenster vor und sind deshalb als drei Einzelpunkte dargestellt, nicht als Kurve. Google fällt am 19.06. auf null. Die Crawler-Zugriffe liegen zwei Monate nach dem Go-live immer noch bei rund 50 Prozent.

Im Juli gingen immer noch 150 Anfragen auf die alten Pfade ein, alle korrekt mit 301 beantwortet. Zu diesem Zeitpunkt zeigte weder die Search Console noch das AI-Visibility-Monitoring die alten URLs überhaupt noch an.

Daraus folgt eine sehr konkrete Handlungsanweisung: Lass deine Weiterleitungen stehen. Google empfiehlt mindestens ein Jahr, und meine Logs zeigen, warum diese Empfehlung nicht übervorsichtig ist. Wer nach acht Wochen aufräumt, weil in den Tools nichts mehr auftaucht, kappt einen Kanal, der noch aktiv ist. Was du dann verlierst, siehst du nirgends, weil ein 404 auf eine alte URL in keinem Sichtbarkeitsreport erscheint.

Googlebot war nicht der Erste, sondern der Zehnte

Am Go-live-Tag stiegen die Bot-Zugriffe von rund 200 auf 1.361, also etwa auf das Siebenfache. Interessanter ist die Reihenfolge, in der die einzelnen Systeme zum ersten Mal eine neue URL abgerufen haben. Die Umstellung war am 11.05. um 14:41 Uhr durch.

Das erklärt nebenbei die erste GSC-Zeile aus der Tabelle oben. Die ersten Impressionen auf dem neuen Pfad kamen am 14.05., weil Googlebot vorher schlicht nicht da war.

Für die Praxis heißt das: Wenn dein Launch-Tag-Check nur aus einem Blick in die Search Console besteht, guckst du zwei Tage lang auf eine leere Seite, während sechs andere Systeme deine Website bereits erfasst haben. Wenn dabei etwas schiefgeht, erfährst du es erst, wenn es passiert ist.

Zwei Bots haben den Wechsel im gesamten Messfenster nicht mitbekommen: MistralAI hat am 02.07. eine alte URL abgerufen und nie eine neue, Claude-SearchBot war am 07.05. zweimal auf alten Pfaden und danach nicht wieder. PerplexityBot hat dagegen als Erster vollständig umgestellt und schon am 04.06. keine alte URL mehr angefragt.

Wenn du zu diesem Thema recherchierst, stolperst du über einen ganzen Satz beeindruckender Zahlen. Ein Teil davon hält der Prüfung stand, ein Teil nicht. Weil in Relaunch-Projekten mit genau diesen Zahlen Budgets begründet und Zeitpläne verteidigt werden, lohnt sich der Blick.

Belastbar: die SALT-Auswertung

SALT.agency hat 1.052 Domain-Migrationen ausgewertet, teils eigene Projekte, teils aus der Community eingesammelt. Der Median der Erholungszeit lag bei 304 Tagen, 13,9 Prozent zeigten auch nach drei Jahren keine vollständige Traffic-Erholung. Die Autoren weisen selbst darauf hin, dass keine Regressionsanalyse gegen Migrationsqualität gerechnet wurde. (SALT.agency)

Zwei Einschränkungen, bevor du das in eine Präsentation kopierst.

Erstens: Beim Anteil der Migrationen, die binnen 90 Tagen wieder auf Vorniveau waren, ist die Quelle selbst uneinheitlich. Der Titel nennt 27 Prozent, Drittquellen zitieren rund 23 Prozent. Nimm die Spanne, nicht eine der beiden Zahlen.

Zweitens, und das ist der wichtigere Punkt: Das sind Domain-Migrationen. Daraus folgt nicht, dass jeder Relaunch zehn Monate braucht. Mein eigener CMS-Wechsel unter gleicher Domain war nach knapp sechs Wochen durch. Wer die SALT-Zahlen für einen Template-Tausch heranzieht, argumentiert mit einer Kategorie, die er gar nicht plant.

Nicht belastbar: die 892 Migrationen

Auf mehreren Websites zirkuliert eine "Search Engine Journal Studie zu 892 Domain-Migrationen" mit 523 Tagen Durchschnitts-Erholung und 17 Prozent, die sich nie erholen. Mal datiert auf 2024, mal auf 2025, je nach Quelle. Eine Primärquelle habe ich nicht gefunden.

Eine Zahl, die in mehreren Beiträgen mit widersprüchlichen Jahresangaben auftaucht und deren Ursprung sich nicht auffinden lässt, gehört nicht in dein Projekt. Sie sieht nur so aus, als wäre sie recherchiert.

Das ist übrigens ein Muster, das dir aktuell überall begegnet: Zahlen, die durch generierte Ratgebertexte wandern und sich dabei gegenseitig bestätigen, ohne dass jemals jemand die Quelle geöffnet hat. Wenn du eine Zahl verwendest, öffne die Quelle. Wenn du sie nicht öffnen kannst, verwende sie nicht.

Der Rest ist Aufregung

Zum Relaunch-Thema kommt derzeit ein zweiter Geräuschpegel dazu: die Behauptung, ohne spezielle KI-Vorbereitung sei ein Relaunch heute unverantwortlich. Das ist bequem zu verkaufen, weil niemand es widerlegen kann, solange niemand misst.

Googles eigene Dokumentation sagt an dieser Stelle etwas anderes, und zwar ausdrücklich: keine Sonderdateien, kein Chunking, keine separaten AEO- oder GEO-Verfahren für die Google-Suche. Meine Position zu diesen Akronymen kennst du, das habe ich an anderer Stelle ausführlich begründet.

Ohne Ursache ist jede Maßnahme Aktionismus. Bevor du beim Relaunch KI-spezifische Maßnahmen einplanst, kläre, welches konkrete Problem sie lösen sollen. In den allermeisten Projekten lautet die Antwort: Zugang sichern und Kontinuität herstellen. Das ist unspektakulär und wirkt.

Wenn ein Retrieval-System deine Seite nicht abrufen kann, ist alles Weitere egal. Das klingt trivial, ist aber der Punkt, an dem Relaunches tatsächlich scheitern, und zwar aus einem Grund, den fast niemand auf dem Zettel hat.

robots.txt ist keine Freigabe

Die Robots-Regeln sagen einem regelkonformen Crawler, was er abrufen darf. Sie sind keine Zugangskontrolle. Dein Webserver, dein CDN, deine Web Application Firewall und dein Bot-Management entscheiden unabhängig davon, ob eine Anfrage überhaupt durchkommt.

Genau hier entstehen beim Relaunch neue Fehler, weil sich die Infrastruktur ändert. Neues Hosting, neuer CDN-Anbieter, frisch aktivierter Bot-Schutz, strengere Rate-Limits. Die robots.txt wird sorgfältig migriert, die WAF-Regeln werden auf Standardwerte gesetzt, und aggressive Standardregeln kennen KI-Crawler oft nicht und behandeln sie entsprechend.

Das Ergebnis: 403 oder 429 auf Anfragen, die deine robots.txt ausdrücklich erlaubt. In der Search Console siehst du davon nichts, weil Googlebot in den meisten Regelwerken auf einer Whitelist steht. In deinen Serverlogs siehst du es sofort.

Trainings- und Suchcrawler sind zwei verschiedene Schalter

Bei OpenAI erfüllen die Bots unterschiedliche Aufgaben:

Die praktische Folge: Du kannst dich gegen Training entscheiden und trotzdem zitierfähig bleiben. Das ist eine legitime unternehmerische Entscheidung, und sie ist eine andere Entscheidung als "alle KI-Bots raus". Wer beim Relaunch pauschal sperrt, weil es sauberer aussieht, verkauft Sichtbarkeit für ein Ziel, das er auch anders erreichen könnte.

Vorsicht bei der Prüfung: Der User-Agent ist ein selbst gesetztes Textfeld und lässt sich beliebig fälschen. Wenn du deine Logs auswertest, gleich die IP gegen die von den Anbietern veröffentlichten Bereiche ab, bevor du aus einem Zugriff einen Befund machst. Wie ich Crawler-Zugang grundsätzlich einordne, steht in meiner AI Crawler Strategie.

Was du konkret prüfst

Auf dem Staging, vor dem Go-live:

1. Ruf eine repräsentative Seite mit gesetztem KI-Crawler-User-Agent ab und prüfe den Statuscode. Ein curl -A "OAI-SearchBot" -I https://staging.deine-domain.de/wichtige-seite reicht für den ersten Blick.

2. Prüfe dasselbe für die Staging-Umgebung hinter dem CDN, nicht nur direkt gegen den Origin. Der Unterschied ist genau der Punkt.

3. Lass dir vom Betrieb die aktive Bot-Management-Konfiguration zeigen, nicht die geplante.

Am Launch-Tag, in dieser Reihenfolge:

1. robots.txt der Produktion abrufen und lesen. Nicht annehmen, lesen.

2. Statuscodes für drei bis fünf wichtige Seiten mit verschiedenen Crawler-User-Agents prüfen.

3. Jede geprüfte alte URL zusätzlich in der Variante ohne abschließenden Slash testen.

4. Serverlogs auf 403, 404, 429 und 503 bei bekannten Crawlern filtern.

Punkt 4 ist zeitkritisch, und zwar aus einem Grund, der in meinen eigenen Daten steht: Die schnellsten Systeme waren 26 Minuten nach der Umstellung auf der neuen Website, Googlebot kam erst nach zweieinhalb Tagen. Wer am Launch-Tag nur in die Search Console schaut, sieht zwei Tage lang nichts, während bereits ein halbes Dutzend anderer Systeme die Seite erfasst. Mein eigener 404-Vorfall war behoben, bevor Googlebot überhaupt vorbeikam. Sichtbar war er ausschließlich im Log.

Für Punkt 3 kannst du meinen AI Bot Log Analyzer nehmen. Der läuft lokal in deinem Browser, deine Logdateien verlassen den Rechner nicht. Das ist bei Access-Logs kein Komfortmerkmal, sondern eine datenschutzrechtliche Notwendigkeit, weil in diesen Dateien die IP-Adressen deiner Besucher stehen.

KPI für diese Ebene

Anteil erfolgreicher Crawler-Abrufe auf den neuen URLs, je Bot, in den ersten sieben Tagen. Zielwert: Statuscodes ausschließlich 200 und 304 auf indexierbaren Seiten, 301 auf den alten Pfaden. Alles andere ist ein Fund, kein Rauschen.

Failure Mode: Du prüfst nur Googlebot, weil das die Search Console anzeigt, und übersiehst wochenlang, dass alle anderen ausgesperrt sind.

Zugang gesichert, jetzt geht es darum, ob nach dem Relaunch noch dasselbe wiederzufinden ist.

Content-Parität heißt nicht Textübernahme

Der übliche Abgleich beim Relaunch lautet: Ist der Text übernommen worden? Das ist zu grob. Entscheidend ist, ob die Informationsdichte erhalten geblieben ist.

Was in Relaunches regelmäßig verschwindet, obwohl der Text formal "übernommen" wurde:

• konkrete Zahlen, die in eine Grafik gewandert sind, die niemand auslesen kann

• Tabellen, die zu Fließtext umgeschrieben wurden, weil das neue Design keine Tabellen mag

• FAQ-Blöcke, die in ein Akkordeon gewandert sind, das erst per JavaScript befüllt wird

• Definitionen, die durch einen Verweis auf eine Glossarseite ersetzt wurden

• Preisangaben und Leistungsumfänge, die durch "sprechen Sie uns an" ersetzt wurden

Jeder einzelne dieser Punkte kostet dich Zitierfähigkeit, ohne dass ein Ranking sofort fällt. Ein System, das eine konkrete Antwort sucht, findet auf der neuen Seite keine mehr.

Googles eigene Empfehlung für generative Suche zielt in dieselbe Richtung: Inhalte, die auf eigener Erfahrung und eigenen Erkenntnissen beruhen, statt allgemein verfügbarem Wissen. Der Relaunch ist der Zeitpunkt, an dem genau solche Inhalte am häufigsten weggeglättet werden, weil eine Agentur die Seiten "einheitlicher" machen soll.

Zitierfähige Passagen erkennen und schützen

Bevor du Texte umbaust, markier auf deinen zehn bis zwanzig wichtigsten Seiten die Absätze, die für sich allein stehen können. Typischerweise sind das:

• ein Absatz, der eine Frage direkt beantwortet, ohne Rückbezug auf den vorherigen Absatz

• eine Definition mit klarem Subjekt am Satzanfang

• eine Aufzählung mit konkreten Werten, Fristen oder Bedingungen

Diese Absätze werden beim Relaunch nicht angefasst. Nicht gekürzt, nicht in Kontext eingebettet, nicht durch eine sanftere Formulierung ersetzt. Wenn sie umziehen müssen, ziehen sie wörtlich um.

Entitätsparität als eigener Prüfpunkt

Deine Website kommuniziert nicht nur Dokumente, sondern Zusammenhänge: Unternehmen, Marke, Personen, Leistungen, Standorte, Themen. Diese Zusammenhänge werden bei einem Relaunch regelmäßig geschwächt, weil sie in Templates stecken und niemand ihnen einen Prüfpunkt gewidmet hat.

Die typischen Verluste:

Nimm diese sechs Punkte als Zeilen in deinen Content-Audit auf, mit Status vorher und nachher. Falls du eine Grounding Page betreibst, gehört sie auf die Liste der Seiten, deren URL sich nicht ändert.

Strukturierte Daten: mitnehmen, aber richtig einordnen

Strukturierte Daten gehören vollständig migriert und nach dem Go-live validiert. Das ist unstrittig, und beim CMS-Wechsel ist es der Punkt, der am häufigsten vergessen wird, weil man ihn nicht sieht.

Was du daraus nicht ableiten solltest: dass mehr Markup automatisch mehr Zitationen bringt. Google schreibt in seiner Dokumentation zu generativer Suche ausdrücklich, dass strukturierte Daten für die generativen Funktionen nicht erforderlich sind. Sie bleiben sinnvoll für Rich Results und für die eindeutige Zuordnung von Entitäten. Als Beschleuniger für KI-Zitationen sind sie nicht belegt. Ausführlicher habe ich das in meinem Beitrag zu strukturierten Daten für AI Search auseinandergenommen.

URLs, die funktionieren, bleiben

Ein Punkt, der beim AI-Search-Thema gerne in die falsche Richtung kippt: Sprechende, gut lesbare URLs sind vermutlich hilfreich. Daraus folgt nicht, dass du beim Relaunch funktionierende URLs kosmetisch umbauen solltest.

Eine URL, die rankt, zitiert wird und Backlinks trägt, ist ein Vermögenswert. Sie gegen eine hübschere zu tauschen, kostet dich garantiert einen Übergang von mehreren Wochen für einen Vorteil, der nicht belegt ist. Meine 38 beziehungsweise 42 Tage sind der Preis dafür, und ich hatte einen guten Grund für den Wechsel. Wenn du keinen hast, lass die URL stehen.

KPI für diese Ebene

Anteil der Top-20-Seiten, bei denen Titel, H1, zitierfähige Kernpassagen, Markup und interne Verlinkung nach dem Go-live nachweislich vorhanden sind. Zielwert: 100 Prozent, geprüft per Vorher-Nachher-Crawl, nicht per Stichprobe.

Failure Mode: Der Content-Audit prüft, ob Seiten existieren, nicht ob sie noch dasselbe leisten.

Wenn du es nicht messen kannst, steuerst du nach Gefühl. Nach einem Relaunch ist das besonders teuer, weil du in der kritischen Phase Entscheidungen triffst: zurückrollen oder aussitzen, nachbessern oder abwarten.

Drei Achsen, nicht eine

Der häufigste Denkfehler steckt in einem Satz, den ich regelmäßig höre: "Der ChatGPT-Traffic ist stabil, also hat der Relaunch die KI-Sichtbarkeit nicht beeinflusst."

Das lässt sich aus Referral-Traffic nicht ableiten. Wenn ein System deine Seite hundertmal als Quelle verwendet und niemand klickt, siehst du in Analytics fast nichts. Referral-Traffic misst Klicks. Zitationen misst du nur, wenn du Zitationen misst.

Die Baseline gehört vor den Go-live

Vor der Umstellung sicherst du:

• vollständigen Crawl der alten Website

• Export aller URLs aus Search Console, Analytics, XML-Sitemap, Backlink-Tool und CMS, als Vereinigungsmenge, nicht als Schnittmenge

• Rankings für die Priority Keywords

• einen AI-Visibility-Snapshot mit festem Prompt-Set

Der letzte Punkt ist der, der fehlt. Er kostet dich einen halben Tag und ist danach nicht mehr nachholbar. Wie du ein belastbares Set zusammenstellst, habe ich im Beitrag zum Prompt-Set fürs AI Visibility Monitoring beschrieben.

Wichtig: Notier zu jeder Zitation die vollständige URL, nicht nur die Domain. Sonst kannst du hinterher nicht unterscheiden, ob dein Relaunch die Sichtbarkeit erhalten oder nur die Domain gehalten hat, während die inhaltlich tragenden Seiten rausgefallen sind.

Zeitplan für die Zeit danach

Die Zeile "Woche 6 bis 8" ist der Punkt, der sich aus meinen Daten ergibt. Vorher vergleichst du Übergangszustände.

Die letzte Zeile ist die, die am häufigsten gestrichen wird, weil das Projekt formal abgeschlossen ist. In meinen Logs gingen zwei Monate nach dem Go-live noch 150 Crawler-Anfragen pro Monat auf die alten Pfade, zu einem Zeitpunkt, an dem keines der beiden anderen Systeme die alten URLs noch auswies. Wer die Weiterleitungen dann abschaltet, produziert 404 für Anfragen, die weiterhin kommen, und merkt es in keinem Report.

KPI für diese Ebene

Anteil deiner Baseline-Prompts, bei denen du nach zwölf Wochen wieder mit mindestens einer eigenen URL als Quelle auftauchst. Zielwert: mindestens auf Vorniveau. Darunter ist ein Befund, kein Rauschen.

Failure Mode: Es gibt keine Baseline, also gibt es auch keinen Zielwert, und die Diskussion endet bei "gefühlt läuft es wieder".

Das hier ist kein Ersatz für die Checklisten aus Teil 1 und Teil 2, sondern der Block, der dort fehlt. Arbeite ihn parallel ab, nicht danach.

Phase 1: Vor dem Relaunch

Phase 2: Staging, vor dem Go-live

Phase 3: Go-live und erste Woche

Phase 4: Wochen 2 bis 12

Wenn ihr diese 25 Punkte in eurem Projektwerkzeug als eigenen Strang anlegt, statt sie in eine Sammelaufgabe "SEO" zu packen, hat das einen Nebeneffekt: Jemand ist dafür zuständig. Das ist in der Praxis wichtiger als der Inhalt der Liste.

Für den Fall, dass dein Relaunch schon gelaufen ist und du wissen willst, ob du ein Problem hast. Eine Stunde, keine Tools außer Terminal und Browser.

Minute 0 bis 10: Zugang

Ruf drei wichtige Seiten mit verschiedenen Crawler-User-Agents ab und notier die Statuscodes.

Alles außer 200 ist ein Fund.

Minute 10 bis 20: Weiterleitungen

Nimm zehn alte URLs aus deinem Backlink-Tool und prüfe, was sie zurückgeben.

Gesucht: 301 direkt auf das Endziel. Gefunden wird oft: 302, Ketten oder 404.

Und danach dasselbe noch einmal ohne abschließenden Slash. Genau dort lag mein eigener Fehler, und er war in keinem Tool sichtbar.

Minute 20 bis 35: Inhalt

Nimm deine drei wichtigsten Seiten und lies sie im Quelltext, nicht im Browser. Steht die Kernaussage im HTML? Sind die konkreten Zahlen noch da oder nur noch in Bildern? Beantwortet die Seite die Frage, für die sie gebaut wurde, in einem Absatz, der für sich stehen kann?

Minute 35 bis 45: Entitäten

Existiert die Autorenseite noch? Ist das Organization-Markup vorhanden und validiert? Steht der Firmenname im Footer genauso wie im Impressum? Ist die Über-uns-Seite noch informativ oder nur noch schön?

Minute 45 bis 60: Sichtbarkeit

Stell deinen fünf wichtigsten Fragen in zwei verschiedenen Systemen und notier, welche URLs zitiert werden. Sind es deine neuen? Deine alten? Gar keine? Das ist keine Messung, das ist eine Stichprobe. Aber sie sagt dir in fünfzehn Minuten, ob du weiterschauen musst.

Wenn du nur eine Sache mitnimmst: Prüf die Statuscodes für KI-Crawler, in beiden Slash-Varianten. Das ist der eine Fehler, der still bleibt, teuer werden kann und sich in zehn Minuten finden lässt.

Der AI-Search-Teil eines Relaunches ist unspektakulärer, als er derzeit verkauft wird, und wichtiger, als er behandelt wird.

Unspektakulärer, weil es keine zweite Maßnahmenliste braucht. Googles eigene Dokumentation sagt das inzwischen ausdrücklich, und meine Daten stützen es: Bei einer sauber ausgeführten Migration bewegen sich klassische Suche und KI-Systeme fast im Gleichschritt. Vier Tage Unterschied sind kein eigenes Projekt.

Wichtiger, weil die Fehler in diesem Kanal still bleiben. Ein blockierter Crawler erzeugt keine Fehlermeldung in deinem Reporting. Eine Seite, die ihre konkreten Antworten beim Redesign verloren hat, sieht besser aus als vorher. Und niemand meldet dir, dass du in einer Antwort nicht vorgekommen bist.

Mein eigener Relaunch ist dafür das beste Beispiel, das ich liefern kann. Ein Hostingproblem hat 25 Stunden lang dafür gesorgt, dass alte URLs ohne abschließenden Slash einen 404 statt einer Weiterleitung bekamen. Betroffen waren ausgerechnet die Seiten, auf die es ankam. Ich habe davon zu dem Zeitpunkt nichts bemerkt, weil in keinem meiner Tools etwas auffällig war, und ich habe eine ganze Reihe davon im Einsatz. Gefunden habe ich es vier Monate später, in einer Logdatei, die ich für diesen Artikel ausgewertet habe.

Du brauchst kein Mehr an Komplexität, du brauchst ein besseres System. Konkret: drei Messachsen statt einer, eine Baseline vor dem Go-live statt einer Rekonstruktion danach, und ein Zuständiger für die 25 Punkte oben statt einer Sammelaufgabe namens SEO.

Der nächste sinnvolle Schritt hängt davon ab, wo du stehst. Steht dein Relaunch noch bevor, nimm dir Punkt 1 bis 7 der Checkliste vor, das ist ein halber Tag und danach nicht mehr nachholbar. Ist der Relaunch gelaufen, mach die 60-Minuten-Prüfung. Und wenn du deine Logs aus der Zeit noch hast, sieh sie dir an. Es ist der einzige Datensatz, der dir zeigt, was tatsächlich passiert ist, statt was deine Tools davon mitbekommen haben.

Wenn dabei Statuscodes auftauchen, die dort nicht hingehören, hast du deine Ursache gefunden, und dann ist die Reihenfolge klar: erst den Zugang reparieren, dann über Inhalte reden.