Website-Relaunch-Leitfaden

Ein Website-Relaunch verliert seine Rankings selten am Launch-Tag. Verloren gehen sie Wochen vorher im Kickoff, wenn alle über Farben, Bildwelten und das neue CMS sprechen und niemand fragt, welche alten Seiten eigentlich die Anfragen bringen.

Google beschreibt die Lage in seiner Dokumentation zu Website-Umzügen nüchtern. Wer URLs ändert, muss mit vorübergehenden Schwankungen im Ranking rechnen. Bei mittelgroßen Websites kann es einige Wochen oder länger dauern, bis Google nach und nach die neuen URLs zeigt. Das ist der Normalfall. Teuer wird erst der dauerhafte Verlust, und der entsteht aus Lücken, die sich vorher finden lassen: fehlende Weiterleitungen, gestrichene Seiten mit Traffic, ein vergessenes noindex.

Dieser Leitfaden geht einen Relaunch in der Reihenfolge durch, in der du entscheidest. Erst die Art des Projekts, dann die sechs Phasen, die Bestandsaufnahme, die SEO-Checkliste für den Go-Live, die ersten 30 Tage, die KI-Sichtbarkeit und die Kosten. Am Ende stehen die sieben Fehler, die wir für die teuersten halten.

Relaunch, Redesign oder Replatforming: Was brauchst du wirklich?

Bei einem Redesign bekommt die Website ein neues Erscheinungsbild, Adressen und Texte bleiben weitgehend stehen. Beim Replatforming wechselt das Fundament darunter, etwa CMS, Shopsoftware oder Hosting. Ein Website-Relaunch baut Seitenstruktur, Inhalte, Gestaltung und häufig auch das System in einem Projekt neu. Mit jeder Ebene, die sich ändert, wächst die Zahl der Signale, die Google neu zuordnen muss.

Relaunch bedeutet wörtlich Neustart. Im Webprojekt heißt das: Die Website geht mit neuer Struktur und meist neuen URLs an den Start. Genau das macht den Relaunch aus SEO-Sicht anspruchsvoll. Jede geänderte Adresse ist eine Stelle, an der Rankings, Backlinks und Lesezeichen verloren gehen können, wenn keine Weiterleitung sie auffängt.

Kommt ein Domainwechsel dazu, gehört die Adressänderung in der Search Console auf die Liste. Google sieht dieses Tool für den Wechsel von Domain oder Subdomain vor. Für den Umstieg von HTTP auf HTTPS ist es nicht nötig.

Unsere Empfehlung: Ändere nur, was sich ändern muss. Ist das CMS am Ende, die Struktur aber gut, ist ein Replatforming mit stabilen URLs die risikoärmere Wahl als der große Wurf. Passen Struktur und Inhalte nicht mehr zu deinem Angebot, führt am Relaunch kein Weg vorbei. Dann gehört die SEO-Migration in die erste Projektwoche.

Für Shops gilt dieselbe Logik mit mehr URLs. Wie ein Plattformwechsel im laufenden Betrieb aussieht, zeigt das Projekt Bike-Discount: Für den Umstieg von Shopware 5 auf Shopware 6 entstand ein komplett neuer Shop, der alle vorhandenen Schnittstellen zu Zahlarten, Warenbestand und ERP weiterverwendet. Heute trägt er laut Projektbericht rund 6.000 Bestellungen pro Tag.

Wer selbst vor diesem Schritt steht, findet den Fahrplan auf der Seite zur Shopware-Migration. Wird aus der Unternehmenswebsite dagegen erst ein Shop, ist das eher ein Neubau mit Sortiment, Zahlungsarten und Prozessen. Dann ist Onlineshop erstellen lassen der bessere Einstieg.

Die sechs Phasen eines Website-Relaunchs

Ein Website-Relaunch läuft in sechs Phasen: Bestandsaufnahme, Konzept und Struktur, UX und Design, Entwicklung und Migration, Go-Live und Monitoring. Als Orientierung nennen wir auf unserer Seite zum Website-Relaunch vier bis acht Wochen für ein Redesign, zwei bis vier Monate für den Relaunch einer Unternehmenswebsite und drei bis sechs Monate mit Schnittstellen oder mehreren Sprachen.

Danach folgt ein Monitoring-Fenster von 30 Tagen. Wie sich die Zeit auf die einzelnen Phasen verteilt, hängt stark am Projekt. Am stärksten bewegen zwei Dinge den Zeitplan: wann Texte und Bilder fertig sind und wie viele Feedbackschleifen jede Freigabe braucht.

Die wichtigste Zeile steht ganz oben. SEO beginnt in Phase 1, nicht zwei Wochen vor dem Go-Live. Und keine Phase beginnt, bevor das Ergebnis der vorherigen abgenommen ist.

Vergibst du das Projekt, halte Ziele, Seitentypen, Sprachen und Schnittstellen vorher in einem Lastenheft fest. Das macht Angebote vergleichbar. Und es verhindert, dass die SEO-Migration als Nachtrag im Change Request landet.

Vor dem Relaunch: die Bestandsaufnahme

Vor dem Relaunch brauchst du ein vollständiges URL-Inventar und gesicherte Ausgangswerte. Dafür gleichst du vier Quellen ab: einen Crawl der Website, die XML-Sitemap, die Leistungsdaten aus der Google Search Console und die Backlinks. Jede Quelle zeigt nur einen Ausschnitt. Erst zusammen ergeben sie die Liste der Seiten, die Rankings, Links und Anfragen tragen.

Wie groß die Lücken sein können, zeigt der Relaunch von Xtreme Events von WordPress auf Shopware 6. Crawl, XML-Sitemap und Search Console bildeten dort jeweils nur einen Teil der indexierten Seiten ab. Erst der Abgleich ergab den tatsächlichen Bestand von 1.125 Alt-URLs, darunter Seiten mit nennenswertem Suchvolumen, die in keiner anderen Quelle auftauchten. Am Ende standen 934 Weiterleitungen.

Crawl und Sitemap

Ein Crawler wie Screaming Frog oder Sitebulb erfasst alle intern verlinkten URLs mit Statuscode, Title, Canonical und Indexierungsstatus. Die XML-Sitemap ergänzt Seiten, die intern kaum verlinkt sind. Interessant ist, was beide übersehen: Seiten, die nur noch über alte Backlinks oder die Google-Suche erreichbar sind. Genau die tauchen in den nächsten beiden Quellen auf.

Search Console und Webanalyse: die Baseline

Exportiere vor dem Relaunch die Leistungsdaten aus der Google Search Console je URL und je Suchanfrage: Klicks, Impressionen, Position. Google hält diese Daten nur für die letzten 16 Monate vor. Ergänze aus der Webanalyse, welche Seiten Anfragen oder Umsatz bringen. Diese Baseline ist später dein einziger Beleg dafür, ob der Relaunch etwas gekostet hat.

Backlinks und Content-Audit

Seiten mit externen Backlinks brauchen auf jeden Fall eine Weiterleitung, auch wenn sie selbst kaum Traffic haben. Die Linkdaten liefert der Link-Bericht der Search Console, ausführlicher ein SEO-Tool wie Ahrefs, Semrush oder Sistrix.

Mit dieser Liste startet der Content-Audit. Für jede URL fällt die Entscheidung, ob sie bleibt, mit einer anderen zusammengelegt wird oder entfällt. Bei Xtreme Events lag ein Schwerpunkt auf Seitenpaaren, die bei denselben Suchbegriffen konkurrierten. Jedes Paar wurde mit Rankingdaten aus Semrush und der Search Console einzeln bewertet. Rankte eine Seite klar stärker, bündelte eine Weiterleitung die Signale auf ihr.

Die SEO-Checkliste für den Go-Live

Die SEO-Checkliste für den Go-Live umfasst Weiterleitungen nach der Redirect-Map, Canonicals auf die neuen URLs, eine neue XML-Sitemap in der Search Console, hreflang für alle Sprachversionen, keine Sperren aus der Testumgebung, saubere interne Links, stabile Core Web Vitals und übernommene strukturierte Daten. Prüfe jeden Punkt direkt nach dem Umschalten.

Die Grenzwerte der Core Web Vitals sind Googles Schwellen für eine gute Nutzererfahrung, gemessen am 75. Perzentil der Seitenaufrufe (web.dev). Ein Relaunch ist der Moment, in dem sie sich am leichtesten verschlechtern: neue Schriften, größere Bilder, ein neues Cookie-Banner, zusätzliche Tracking-Skripte. Miss deshalb vor und nach dem Go-Live dieselben Seitentypen.

301 oder 308: Welche Weiterleitung beim Relaunch?

Für Google sind beide gleichwertig. Laut der Google-Dokumentation zu Weiterleitungen sind 301 und 308 dauerhafte Weiterleitungen, die Google als Signal für die kanonische URL nutzt. 302, 303 und 307 gelten als vorübergehend und tragen dieses Signal nicht. Für einen Relaunch kommen also nur 301 oder 308 in Frage.

Der Unterschied liegt im HTTP-Standard. Bei einem 301 dürfen Browser laut RFC 9110 aus historischen Gründen eine POST-Anfrage als GET wiederholen, der 308 behält die Methode bei. Für Seiten-URLs spielt das keine Rolle, für umziehende Formular- oder API-Endpunkte schon. Der 308 stammt erst von 2014. RFC 9110 hält fest, dass ihn womöglich nicht jeder Client erkennt.

Next.js zum Beispiel setzt für dauerhafte Weiterleitungen standardmäßig einen 308. Das ist für Google kein Problem.

Kurz gesagt: Für Seiten ist der 301 der robuste Standard, ein 308 ist für Google gleichwertig. Wichtiger als der Statuscode ist das Ziel. Leitest du viele alte URLs pauschal auf die Startseite um, kann Google das laut Umzugs-Dokumentation als Soft 404 werten. Die Signale der alten Seiten kommen dann nirgends an.

Ketten vermeidest du ebenfalls. Google folgt laut seiner Dokumentation zu HTTP-Statuscodes bis zu zehn Weiterleitungen in Folge, jede zusätzliche Station kostet trotzdem Crawling und Ladezeit. Und lass die Weiterleitungen stehen: Google empfiehlt, sie so lange wie möglich zu behalten, in der Regel mindestens ein Jahr.

Was ein 301-Redirect technisch bedeutet, erklärt unser Wiki. Wie du die Redirect-Map für einen Shop mit Tausenden Produkt- und Kategorie-URLs aufbaust, steht im Beitrag Shop-Migration ohne SEO-Verlust.

Die noindex-Falle aus der Testumgebung

Eine Testumgebung soll nicht in den Index, also wird sie oft per noindex oder per Disallow in der robots.txt versteckt. Beides wandert beim Go-Live leicht mit. Ein noindex auf der neuen Website nimmt die Seiten nach und nach aus dem Index, eine gesperrte robots.txt hält Google vom Crawlen ab. Google nennt das Entfernen solcher Sperren ausdrücklich als Schritt beim Umzug.

Die beiden Sperren vertragen sich außerdem nicht. Laut Google wirkt noindex nur, wenn die Seite nicht per robots.txt blockiert ist. Sonst sieht der Crawler die Anweisung nie. Eine blockierte Seite kann trotzdem in den Suchergebnissen auftauchen, etwa wenn andere Seiten auf sie verlinken. Die saubere Lösung für die Testumgebung ist deshalb ein Passwortschutz. Dann gibt es nichts, was beim Go-Live versehentlich mit umzieht.

hreflang und Sprachversionen

Hat deine Website eine englische Version, verdoppelt sich die Fehlerquelle. Google verlangt, dass jede Sprachversion sich selbst und alle anderen Versionen nennt. Verweisen zwei Seiten nicht gegenseitig aufeinander, ignoriert Google die Angaben (Google-Dokumentation zu lokalisierten Versionen). Nach dem Relaunch müssen die hreflang-Angaben in allen Sprachen auf die neuen URLs zeigen. Mit x-default legst du fest, welche Seite Nutzer sehen, deren Sprache du nicht abdeckst.

Eine Falle, die leicht übersehen wird: Die englische Version geht später live und steht so lange auf noindex. Dann verweisen die deutschen Seiten per hreflang auf Seiten, die nicht in den Index dürfen. Bei Xtreme Events haben wir Canonical- und hreflang-Angaben in allen drei Sprachen abgeglichen.

Nach dem Go-Live: die ersten 30 Tage

In den ersten 30 Tagen nach dem Go-Live beobachtest du die Indexierung in der Search Console, 404-Fehler und Weiterleitungen, die Klicks und Rankings der wichtigsten Seiten im Vergleich zur Baseline und die Zugriffe der Crawler. Schwankungen in den ersten Wochen sind normal. Bricht eine wichtige Seite dauerhaft ein, ist das ein Fall für die Fehlersuche an genau dieser URL.

Tag 1

Ruf die Top-URLs aus der Baseline einzeln auf und prüf Statuscode, Weiterleitungsziel, Canonical und Meta-Robots. Reich die neue XML-Sitemap in der Search Console ein und melde die wichtigsten Seiten über die URL-Prüfung zur Indexierung an. Zur Kontrolle empfiehlt Google, auch die vorher gesicherte Sitemap mit den alten URLs einzureichen: Deren indexierte Seiten sinken mit der Zeit gegen null, während die neue Sitemap zulegt. Prüf auch Tracking und Consent-Banner, sonst fehlen dir ausgerechnet die Daten der ersten Tage.

Woche 1

Im Bericht zur Seitenindexierung tauchen jetzt die ersten 404-Fehler auf. Jeder davon ist entweder eine fehlende Weiterleitung oder eine bewusst gelöschte Seite, und du solltest wissen, welches von beiden. Die Server-Logs zeigen, welche alten URLs der Googlebot noch abruft.

Achte auch auf Serverfehler. Laut Google bremsen 5xx-Fehler und der Status 429 das Crawling, und das trifft eine gerade umgezogene Website besonders. Mehr dazu im Wiki-Eintrag zum Crawl-Budget.

Woche 2 bis 4

Jetzt vergleichst du je URL, nicht je Website. Ein leicht gesunkener Gesamtwert kann bedeuten, dass alles ein wenig schwankt. Er kann aber auch bedeuten, dass die Seiten mit den meisten Anfragen weggebrochen sind und der Rest zugelegt hat. Seiten, die zum Ende des Monitorings deutlich unter ihrer Baseline liegen, prüfst du einzeln: Weiterleitung, Inhalt, interne Links, Canonical.

Ganz abgeschlossen ist der Umzug nach 30 Tagen nicht immer. Google nennt für mittelgroße Websites einige Wochen oder mehr, bis die neuen URLs angekommen sind. Bei großen Shops lohnt deshalb ein längeres Beobachtungsfenster.

KI-Sichtbarkeit nach dem Relaunch

Für ChatGPT, Perplexity und die KI-Antworten von Google gilt dasselbe Fundament wie für die klassische Suche: Die Seite muss erreichbar, indexierbar und für die meisten KI-Crawler schon im ausgelieferten HTML lesbar sein. Ein Relaunch kann genau das unbemerkt brechen, etwa durch eine JavaScript-App ohne Server-Rendering oder eine neue robots.txt, die KI-Crawler aussperrt. Prüf beides vor dem Go-Live.

Für die AI Overviews und den AI Mode gibt es laut Google keine zusätzlichen Anforderungen. Eine Seite muss indexiert sein und mit Snippet in der Suche erscheinen dürfen. Neue maschinenlesbare Dateien, KI-Textdateien oder spezielles Markup braucht es dafür ausdrücklich nicht. Wer die Checkliste oben sauber abarbeitet, hat für Google den größten Teil erledigt.

Bei anderen KI-Crawlern ist JavaScript die größere Hürde. Eine Auswertung von Vercel fand im Dezember 2024, dass außer Gemini, das die Infrastruktur des Googlebot nutzt, und AppleBot keiner der großen KI-Crawler JavaScript ausführte, darunter GPTBot, ClaudeBot und PerplexityBot. Das ist eine Momentaufnahme, und die Crawler entwickeln sich schnell.

Auch Google nennt Server- oder Pre-Rendering weiterhin eine gute Idee, weil nicht alle Bots JavaScript ausführen können. Baut dein Relaunch auf eine Single Page Application, gehört Server-Side-Rendering deshalb in die Anforderungen, bevor das Frontend steht.

Die zweite Stelle ist die robots.txt. OpenAI trennt die Crawler für Suche und Training: OAI-SearchBot bringt Seiten in die Suchergebnisse von ChatGPT, GPTBot sammelt Inhalte für das Training der Modelle. Du kannst den einen zulassen und den anderen sperren. Bei Google steuert der Token Google-Extended die Nutzung für Gemini und beeinflusst laut Google weder die Aufnahme in die Google-Suche noch das Ranking.

Wichtig ist, dass jemand diese Entscheidung bewusst trifft. Eine aus der Testumgebung kopierte robots.txt trifft sie sonst für dich. Schau dabei auch in den Bot-Schutz beim neuen Hoster oder CDN: Google nennt diese Infrastruktur ausdrücklich neben der robots.txt, und eine Sperrregel dort hält Crawler fern, auch wenn die robots.txt sie zulässt.

Und die llms.txt? Die Datei ist ein Vorschlag von Jeremy Howard aus dem September 2024, inzwischen in Version 2 (Stand 10.08.2026), und kein verabschiedeter Standard. Für seine eigenen KI-Funktionen braucht Google laut eigener Aussage keine KI-Textdateien. Eine llms.txt kostet aber wenig und gibt Sprachmodellen eine Übersicht über die Website. Bei Xtreme Events haben wir sie redaktionell in drei Sprachen erstellt und die Crawler von OpenAI, Anthropic, Perplexity und Google gezielt freigegeben. Was in eine llms.txt gehört, prüft unser llms.txt-Check.

Inhaltlich zählt, was auch in der klassischen Suche zählt: Seiten, die echte Fragen direkt beantworten. Dazu gehören eine kurze Antwort unter jeder Überschrift, FAQ-Blöcke mit vollständigen Antworten und strukturierte Daten, die zum sichtbaren Text passen. Den letzten Punkt nennt Google ausdrücklich als Best Practice für seine KI-Funktionen.

Wie sichtbar deine Website heute in KI-Antworten ist, zeigt der KI-Sichtbarkeits-Check. Ob die Crawler überhaupt durchkommen, prüft der KI-Crawler-Check. Die strategische Seite davon heißt GEO, Generative Engine Optimization.

Wovon hängen die Kosten eines Website-Relaunchs ab?

Die Kosten eines Website-Relaunchs hängen an fünf Treibern: der Zahl der Seiten und dem Umfang der Content-Migration, dem Design, der technischen Basis, den Schnittstellen und der Mehrsprachigkeit. Eine belastbare Zahl gibt es erst nach der Bestandsaufnahme. Unseren Preisrahmen nach Projekttyp, vom Redesign bis zum Relaunch mit Schnittstellen, findest du auf der Seite zum Website-Relaunch.

Einen Posten solltest du früh einplanen: Barrierefreiheit. Das Barrierefreiheitsstärkungsgesetz gilt seit dem 28.06.2025, unter anderem für Dienstleistungen im elektronischen Geschäftsverkehr, die für Verbraucher erbracht werden. Ob dein Angebot darunter fällt, klärst du am besten vor dem Relaunch. Einen ersten Stand liefert der BFSG-Check.

Die SEO-Migration muss nicht bei dem Team liegen, das Design und Code baut. Entwickelt eine andere Agentur oder deine eigene IT die Website, kann eine SEO-Agentur den Teil verantworten, an dem die Rankings hängen, von der Bestandsaufnahme bis zum Monitoring nach dem Umschalten.

Prüf außerdem Förderung, bevor du unterschreibst. Das Merkblatt der KfW zum ERP-Förderkredit Digitalisierung (511/512, Stand 23.04.2026) nennt die „grundlegende Neugestaltung einer Unternehmenswebsite oder App mit neuen Funktionalitäten“ als Beispiel für ein förderfähiges Vorhaben. Voraussetzung in dieser Förderstufe ist laut Merkblatt, dass dabei digitale Systeme miteinander vernetzt werden. Den Antrag stellst du vor Beginn des Vorhabens bei einem Finanzierungspartner, etwa deiner Hausbank.

Geht dein Vorhaben über eine Unternehmenswebsite hinaus, etwa in Richtung Shop, Web-App oder Kundenportal, gibt dir der Projekt-Rechner eine erste Einschätzung zu Budget, Zeitrahmen und Aufwand.

Die sieben teuersten Relaunch-Fehler

Die teuersten Relaunch-Fehler sind ein fehlendes URL-Inventar, gestrichene Seiten mit Traffic, Sammelweiterleitungen auf die Startseite, temporäre Weiterleitungen im Dauerbetrieb, mitgewanderte Sperren der Testumgebung, Inhalte, die erst im Browser entstehen, und Weiterleitungen, die zu früh verschwinden. Hier stehen sie als Liste für den Projekt-Kickoff, in der Reihenfolge, in der sie entstehen.

1. Es gibt kein URL-Inventar. Ohne den Abgleich von Crawl, Sitemap, Search Console und Backlinks fehlen in der Redirect-Map genau die Seiten, die niemand auf dem Schirm hatte.
2. Seiten mit Traffic werden gestrichen. Was im neuen Konzept „nicht mehr passt“, hat vielleicht jahrelang Anfragen gebracht. Erst die Baseline lesen, dann streichen.
3. Alte URLs landen gesammelt auf der Startseite. Google kann das als Soft 404 werten, und die Signale der alten Seiten verpuffen.
4. Temporäre Weiterleitungen bleiben dauerhaft stehen. Ein 302 oder 307 ist für Google kein Signal, dass die neue URL die kanonische ist. Prüf den Statuscode, den der Server tatsächlich ausliefert.
5. Die Sperren der Testumgebung gehen mit live. Ein einziges noindex im Seiten-Template genügt, um alle Seiten dieses Templates aus dem Index zu nehmen.
6. Inhalte entstehen erst im Browser. Was nur per JavaScript geladen wird, sehen viele KI-Crawler nicht.
7. Die Weiterleitungen verschwinden nach ein paar Monaten, beim Serverumzug oder beim Aufräumen der Konfiguration. Google empfiehlt mindestens ein Jahr, für URLs mit Backlinks spricht nichts gegen eine dauerhafte Weiterleitung.

Häufige Fragen zu SEO beim Website-Relaunch

Was bedeutet Relaunch bei einer Website?

Relaunch heißt wörtlich Neustart. Gemeint ist ein Projekt, in dem eine Website mit neuer Seitenstruktur, überarbeiteten Inhalten, neuer Gestaltung und oft auf einem neuen System online geht, in der Regel unter neuen Adressen. Ändert sich nur das Erscheinungsbild, ist es ein Redesign.

Wie lange sollte ich Weiterleitungen nach einem Relaunch behalten?

Google empfiehlt, Weiterleitungen so lange wie möglich zu behalten, in der Regel mindestens ein Jahr. Für alte URLs mit externen Backlinks spricht nichts dagegen, sie dauerhaft bestehen zu lassen. Eine Weiterleitungsregel kostet kaum etwas, ein verlorener Backlink schon.

Muss ich jede alte URL weiterleiten?

Nein. Weiterleiten musst du jede URL mit Traffic, Rankings oder Backlinks, und zwar auf die inhaltlich passende neue Seite. URLs ohne all das, etwa alte Filter- oder Testseiten, dürfen einen 404 liefern. Falsch ist der bequeme Ausweg, sie alle pauschal auf die Startseite zu schicken.

Wann sind die Rankings nach dem Relaunch wieder stabil?

Google nennt für mittelgroße Websites einige Wochen oder mehr, bis die neuen URLs nach und nach in der Suche erscheinen, und rechnet in dieser Zeit mit Schwankungen. Liegt eine wichtige Seite nach dem Monitoring noch deutlich unter ihrer Baseline, prüf Weiterleitung, Inhalt und Canonical genau dieser Seite.

Kann ich Relaunch und Domainwechsel kombinieren?

Technisch ja. Für den Domainwechsel kommt das Tool zur Adressänderung in der Search Console dazu. Der Nachteil: Fallen die Rankings, weißt du nicht, ob es an der Domain, der Struktur oder den Inhalten liegt. Ist der Domainwechsel nicht zwingend, trenn die beiden Schritte.

Brauche ich nach dem Relaunch eine llms.txt?

Pflicht ist sie nicht. Google braucht für AI Overviews und den AI Mode nach eigener Aussage keine KI-Textdateien. Wichtiger sind Server-Rendering, eine robots.txt, die die gewünschten Crawler zulässt, und Inhalte, die Fragen direkt beantworten. Eine llms.txt ist eine günstige Ergänzung, wenn dieses Fundament steht.

Fazit: Der Relaunch entscheidet sich vor dem ersten Entwurf

Ein Website-Relaunch ohne dauerhaften Rankingverlust ist Handwerk mit fester Reihenfolge. Erst entscheiden, ob es ein Redesign, ein Replatforming oder ein Relaunch wird. Dann das URL-Inventar aufbauen, bevor jemand eine Seite streicht. Die Redirect-Map in der Testumgebung prüfen, beim Go-Live die Sperren entfernen und 30 Tage lang genau hinschauen. Wer dabei Server-Rendering und Crawler-Zugang mitdenkt, ist auch für KI-Suchen gerüstet.

Plan die SEO-Migration deshalb als eigenen Arbeitsstrang mit Budget und klarer Verantwortung, und zwar ab der ersten Projektwoche. Relaunch geplant? Wir sichern deine Rankings mit Redirect-Map und 30-Tage-Monitoring ab. Wie wir dabei vorgehen, steht auf der Seite zum Website-Relaunch.