Website-Relaunch ohne Sichtbarkeitsverlust: Die SEO-Checkliste

„Nach einem Relaunch verliert man immer etwas Sichtbarkeit, das kommt nach 3 bis 6 Monaten zurück.“ Den Satz höre ich regelmäßig. Und er ist eine Ausrede. Ich habe Relaunches begleitet, bei denen kein einziges Ranking verloren gegangen ist. Ein Kunde generierte nach einem Relaunch 5.000 Klicks an einem Tag über ein einziges Keyword.

Website-Relaunches gehören zu den riskantesten Momenten im Leben einer Website. Neues Design, neues CMS (Content-Management-System), neue Domain: Jede dieser Änderungen kann Sichtbarkeit vernichten, die über Jahre aufgebaut wurde. Muss nicht sein. Wenn du den Relaunch wie ein technisches Manöver behandelst und nicht wie ein kreatives Event, bleibt Sichtbarkeit stehen und wächst danach weiter.

Der häufigste Fehler passiert vor dem ersten Klick

Der häufigste Fehler passiert vor dem ersten Klick. Der Relaunch scheitert nicht am Go-Live-Tag, er scheitert in der Planungsphase, weil niemand die strategische Übersicht erstellt hat.

Bevor du eine einzige URL anfasst, musst du vier Fragen beantworten:

1. Was haben wir? Bestandsaufnahme: alle existierenden Seiten, ihr Traffic, ihre Backlinks.
2. Was rankt? Google Search Console exportieren: die URLs mit Klicks und Impressionen.
3. Was nutzen unsere Kunden? Die Seiten mit Conversions, Anfragen und Verkäufen.
4. Wie gehen wir den Relaunch an? URL-Mapping erstellen, Redirect-Plan, Content-Entscheidungen.

Abb. 1: 4 Fragen, die vor jedem Relaunch beantwortet werden müssen

Ein Industrieunternehmen erlitt 2021 einen massiven Sichtbarkeitseinbruch nach einem unbegleiteten Relaunch ohne Redirects. Die neue Seite war langsamer als die alte, der Einbruch Jahre später noch spürbar. Beim SEO-Audit fanden wir Altlasten: zwei Seiten, die auf dasselbe Keyword rankten. Überbleibsel der alten Website, nie aufgeräumt.

Teuerster Fehler: Keine Ahnung haben, was man verliert. Nicht zu wissen, was man hat, ist teurer als jeder einzelne falsche Redirect.

Die Redirect-Strategie: Warum 301 auf die Startseite ein Anti-Pattern ist

Redirects sind das Rückgrat jedes Relaunchs. Aber Redirect ist nicht gleich Redirect. Viele setzen einen pauschalen 301-Redirect auf die Startseite als Default-Fallback. Schlechte Idee.

Alte Backlinks enthalten Ankertexte mit Keywords. Leitest du alle alten URLs auf die Startseite um, fließt der Link Juice mit den alten Ankertexten auf die Startseite. Die Startseite rankt dann plötzlich für Keywords, für die eigentlich Unterseiten ranken sollen. Ergebnis: Keyword-Kannibalisierung.

Die Redirect-Kaskade: 4 Stufen für jede alte URL

Für jede alte URL, die es auf der neuen Seite nicht mehr 1:1 gibt, arbeitest du diese Kaskade von oben nach unten ab:

1. 301 auf das identische Produkt oder die identische Seite. Gleicher Inhalt, neue URL.
2. 301 auf ein ähnliches Produkt oder eine verwandte Seite. Thematisch passend, gleiche Suchintention.
3. 301 auf die übergeordnete Kategorie. Die Kategorie, in der das alte Produkt oder die alte Seite eingeordnet war.
4. 301 auf die Startseite: nur wenn Backlinks mit Link Juice vorhanden sind. Und auch dann nur als letzter Ausweg, nicht als Default.

Gibt es kein sinnvolles Redirect-Ziel und keine relevanten Backlinks, ist ein 410 Gone die bessere Wahl. Ein 410 sagt Google: Diese Seite existiert nicht mehr, ersatzlos. Google entfernt die URL aus dem Index. Sauberer als ein Redirect, der ins Nichts führt.

Abb. 2: Die Redirect-Kaskade von der besten zur letzten Option

Wenn Rankings existierten, gab es Interesse

Grundregel: Hatte eine alte URL Rankings und Klicks, gab es Nachfrage für dieses Thema. Auf diese Nachfrage kannst du nach dem Relaunch nicht verzichten.

Rankings dürfen nie in einem 404-Error enden. 404-Fehler nach einem Relaunch sind verlorener Traffic, verlorene Kunden, verlorener Link Juice. Jede URL mit Rankings oder Backlinks braucht ein Redirect-Ziel oder eine neu aufgebaute Seite, die das Thema sauber übernimmt.

CMS-Wechsel: Worauf du achten musst

Ein CMS-Wechsel ist technisch aufwändiger als ein reines Redesign. Contao zu WordPress, WooCommerce zu Shopify, Eigenentwicklung zu Standard-System – die Grundprinzipien bleiben dieselben. Über den Erfolg entscheiden ein paar technische Basics, das CMS selbst spielt für SEO eine untergeordnete Rolle.

Das CMS ist egal, die technischen Basics nicht

Ehrlicherweise ist mir das CMS relativ egal. WordPress, Shopify, Shopware, Contao: Jedes System kann SEO-technisch funktionieren. Entscheidend ist, ob du die technischen Basics kontrollieren kannst:

• Trailing Slashes: Hatte die alte Seite URLs mit Trailing Slash (/produkte/) und die neue liefert sie ohne aus (/produkte), entstehen ohne Redirect-Regel doppelte URLs. Das gilt in beide Richtungen.
• www vs. non-www: Gleiche Domain-Variante wie vorher verwenden oder sauber umleiten.
• robots.txt: Die neue Seite muss Google Zugriff auf alle relevanten Bereiche geben.
• Canonical Tags: Die Canonicals müssen auf die richtigen URLs zeigen.

Bei Shopify fällt mir auf, dass die Plattform beim Crawling 429-Fehler wirft: Rate Limiting für Crawler. Aus SEO-Sicht nicht ideal, weil Googlebot dadurch weniger Seiten pro Crawl-Session erfasst.

Onlineshop-Plattform wechseln ohne SEO-Verlust

Der Spezialfall des CMS-Wechsels ist der Shop-Plattformwechsel, etwa von WooCommerce zu Shopify oder von Magento zu Shopware. Hier ändern sich fast immer alle Produkt- und Kategorie-URLs, weil Shop-Systeme feste URL-Muster erzwingen: Shopify presst jede Produkt-URL in /products/ und jede Kategorie in /collections/. Deswegen ist das URL-Mapping auf Produkt- und Kategorieebene der kritische Schritt, die Redirect-Kaskade gilt pro Produkt. Dazu kommen zwei Punkte, die beim normalen CMS-Wechsel keine Rolle spielen: Redirects für Varianten- und Filter-URLs und die vollständige Mitnahme des Product-Schemas mit Preis, Verfügbarkeit und GTIN.

Die Sunk Cost Fallacy: Neu bauen statt migrieren

Viele Kunden hängen an ihrer bestehenden Seite und wollen sie „migrieren“: Inhalte übernehmen, Struktur beibehalten, alles 1:1 übertragen. Manchmal sinnvoll. Oft eine Sunk Cost Fallacy.

Neu bauen ist häufig schneller, günstiger und sauberer. Du startest mit einer durchdachten Struktur, statt die Fehler der alten Seite mitzuschleppen. Für eine mittelständische Firmenwebsite rechne ich mit 30 bis 40 Arbeitsstunden für den WordPress-Aufbau, inklusive Content-Übernahme und SEO-Grundeinrichtung.

Der Schlüssel: Auch beim Neuaufbau brauchst du Redirects von den alten URLs auf die neuen. Klingt widersprüchlich, ist es aber nicht. Das „Neu bauen“ meint Seitenstruktur und CMS, die Redirect-Planung bleibt davon unberührt.

Domain-Wechsel und Rebranding: Mehr als nur Redirects

Ein CMS-Wechsel ist technisch anspruchsvoll. Punkt. Ein Domainwechsel mit Namenswechsel ist strategisch anspruchsvoll, weil es hier um Markenidentität geht und nicht um Server.

Warum Redirects bei einem Rebranding nicht reichen

301-Redirects von alter-name.de auf neuer-name.de übertragen den Link Juice, das stimmt. Die Markenwahrnehmung übertragen sie nicht. Google, Branchenverzeichnisse, KI-Systeme: alle kennen den alten Namen. Wenn du den Wechsel nicht aktiv kommunizierst, passiert Folgendes: Die alte Marke verschwindet, die neue existiert für Suchmaschinen und Menschen noch nicht. Lücke. Würde ich nicht riskieren.

Pro-Tipp: Nutze das Change of Address Tool in der Google Search Console. Es teilt Google den Domainwechsel direkt mit und beschleunigt die Neuindexierung – einer der wenigen Fälle, in denen Google dir ein Tool gibt, das tatsächlich hilft.

Die Mindestanforderung: Ein Blogpost mit beiden Namen

Wer seinen Firmennamen ändert, braucht mindestens einen öffentlichen Beitrag, der beide Namen nennt: „AlteFirma heißt jetzt NeueFirma.“ Simpel. Aber so ein Beitrag schafft die textuelle Brücke, die Google und Large Language Models (LLMs) brauchen, um die Verbindung überhaupt herzustellen.

Besser wäre eine kleine PR-Kampagne (PR = Public Relations). Pressemitteilung raus, Social-Media-Ankündigung, alle Branchenverzeichnisse aktualisieren. Naja, klingt nach Aufwand, ist es auch. Aber je mehr Quellen den Zusammenhang zwischen altem und neuem Namen bestätigen, desto schneller lernt Google die neue Entity. Jason Barnard (CEO Kalicube, Experte für Brand SERPs und Knowledge Panels) nennt das Prinzip „Corroboration“. Seine These: Google braucht mehrere unabhängige Quellen, die dieselbe Information bestätigen, bevor eine Entity im Knowledge Graph aktualisiert wird. Halte ich für plausibel, deckt sich mit dem, was wir bei Kunden sehen.

Co-Branding-Phase beim Domain-Wechsel einplanen

Beide Namen für 3 bis 6 Monate parallel führen: „NeueFirma (vormals AlteFirma)“ im Footer, in der About-Seite, im Google-Unternehmensprofil. Das gibt Suchmaschinen und KI-Systemen Zeit, die neue Zuordnung zu lernen.

Parallel dazu: NAP-Daten (NAP = Name, Adresse, Telefon) auf allen Portalen gleichzeitig umstellen. Nicht scheibchenweise über Monate verteilt, das fragmentiert die Entity.

Drei Relaunches, drei Ergebnisse

Drei Fälle aus der Praxis zeigen, was saubere Vorbereitung bewirkt: ein Theme-Relaunch im laufenden Betrieb, ein CMS-Wechsel mit 500% Wachstum und eine Domain-Konsolidierung.

Abb. 3: Drei Relaunches, drei Ergebnisse im Überblick

Fall 1: Nahtloser Relaunch eines Online-Shops

Ein Schokoladen-Online-Shop brauchte ein neues Theme und neue Plugins, WordPress und WooCommerce blieben als Plattform bestehen. Die Vorbereitung: Alle URLs gemappt, relevante Kategorien behalten, Produkte konsolidiert, Redirects für jede geänderte URL gesetzt.

Der Shop kam praktisch ohne Sichtbarkeitseinbruch durch den Relaunch, die Rankings gingen direkt weiter hoch. Kurz danach explodierte das Keyword „Dubai Schokolade“. Der Shop stand auf Platz 2 bei Google und hatte an einem einzigen Tag 5.000 Klicks nur über dieses eine Keyword. Das wäre nicht möglich gewesen, wenn der Relaunch Sichtbarkeit gekostet hätte.

Dass das CMS gleich geblieben ist, war vermutlich ein Faktor. Google musste weniger Ressourcen für die Rendering-Pipeline aufwenden. Aber der eigentliche Grund war die Vorbereitung: Alles umgeleitet, nichts vergessen, keine verwaisten URLs.

Fall 2: CMS-Wechsel einer Arztpraxis

Eine Schweizer Chirurgie-Praxis wechselte von Contao zu WordPress. Vor dem Relaunch: rund 500 Klicks pro Monat, durchschnittliche Position 27. Zehn Monate später: über 3.000 Klicks pro Monat, durchschnittliche Position 5. Ein Wachstum von 500%.

Der Relaunch war nicht nur ein CMS-Wechsel: Wir haben gleichzeitig die Inhalte überarbeitet, die Seitenstruktur neu aufgebaut und die technische Basis verbessert. Aber ohne saubere Redirects und eine ordentliche Übergabe wäre das Wachstum nie so steil gewesen.

Fall 3: Domain-Konsolidierung

Ein E-Commerce-Unternehmen betrieb neben seinem Haupt-Shop eine zweite Domain, die kaum Umsatz generierte. Statt die zweite Domain weiterzupflegen, haben wir sie URL für URL auf den Haupt-Shop umgeleitet. Der Link Juice der alten Domain fließt jetzt in den Haupt-Shop, der Pflegeaufwand ist weg.

Der gefährlichste Moment: Staging auf Production

Die häufigste technische Ursache für Sichtbarkeitsverlust nach einem Relaunch ist keine vergessene Redirect-Regel. Die häufigste Ursache ist ein vergessenes noindex-Tag.

Entwickler arbeiten auf einer Staging-Umgebung. Die Staging-Seite darf nicht indexiert werden, deswegen steht dort ein <meta name="robots" content="noindex"> oder ein Disallow: / in der robots.txt. Beim Go-Live wird die Staging auf die Production übertragen. Und niemand prüft, ob die Indexierungssperre mit übertragen wurde.

Google deindexiert dann die gesamte Website. Innerhalb weniger Tage verschwindet die Seite aus dem Index. Das passiert häufiger als man denkt und ist komplett vermeidbar.

Die 48-Stunden-Checkliste nach Go-Live

Die ersten 48 Stunden nach einem Relaunch entscheiden darüber, ob Probleme früh erkannt oder erst Wochen später bemerkt werden. Direkt an den Go-Live-Tag gehören 5 Prüfschritte, 3 weitere in die erste Woche. Ein vergessenes noindex fällt so nach Minuten auf statt nach Wochen.

Sofort nach Go-Live

1. Crawl durchführen. Die gesamte neue Seite einmal mit Screaming Frog oder einem vergleichbaren Tool crawlen. Broken Links, 404er, Redirect-Ketten identifizieren.
2. Redirects stichprobenartig prüfen. Die 20 wichtigsten alten URLs manuell testen. Jede muss auf der richtigen neuen Seite ankommen.
3. robots.txt prüfen. Die Live-Version muss alle wichtigen Bereiche freigeben, Staging-Regeln gehören entfernt.
4. robots meta tag prüfen. Seiten, die indexiert werden sollen, müssen frei von noindex sein. Stichprobe im Quellcode oder per Crawl.
5. Google Search Console prüfen. Sitemap einreichen. Indexierung beantragen für die wichtigsten Seiten.

Innerhalb der ersten Woche

1. Google Search Console auf Crawl-Fehler prüfen. Neue 404er, Soft 404er und Server-Fehler tauchen dort zuerst auf.
2. Rankings monitoren. Die 10 wichtigsten Keywords täglich checken. Schwankungen von 1 bis 3 Positionen sind nach einem Relaunch normal, Verluste von 10 und mehr Positionen sind ein Alarmsignal.
3. Sitemaps prüfen. Die Sitemap darf ausschließlich neue URLs enthalten.

Go-Live-Timing

Der beste Zeitpunkt für einen Relaunch: Nicht Freitag um 17 Uhr. Am besten an einem Dienstag oder Mittwoch, vormittags. So hast du den Rest der Woche, um auf Probleme zu reagieren. Nicht zur Hauptgeschäftszeit: falls etwas schiefgeht, verlierst du weniger Umsatz.

Abb. 4: Die 48-Stunden-Checkliste nach Go-Live

Traffic-Verlust nach dem Relaunch: So findest du die Ursache

Wenn der Relaunch schon gelaufen ist und der Traffic weg: Panik hilft nicht, eine feste Prüfreihenfolge schon. Die 5 häufigsten Ursachen, sortiert nach Wahrscheinlichkeit:

1. noindex oder gesperrte robots.txt aus dem Staging übernommen. Der Klassiker, siehe oben.
2. Fehlende oder falsche Redirects. 404-Fehler und Redirect-Ketten in der Search Console prüfen.
3. URL-Struktur ohne Mapping geändert. Alte URLs laufen ins Leere. Rankings hängen an URLs, nicht an Inhalten allein.
4. Canonical-Fehler. Canonicals zeigen auf die Staging-Domain oder auf widersprüchliche Ziele.
5. Performance- oder Rendering-Verschlechterung. Das neue Theme rendert wichtige Inhalte nur noch per JavaScript.

Jede dieser Hypothesen lässt sich mit zwei Werkzeugen prüfen: einem GSC-Vergleich auf URL-Ebene (welche URLs hatten vor dem Go-Live Impressionen und haben danach keine mehr?) und einem frischen Crawl. Wer die Ursache zügig findet und behebt, holt Rankings in der Regel deutlich schneller zurück, als die oft zitierten 3 bis 6 Monate vermuten lassen. Bei Shop-Systemen wie Shopware kommt die Varianten- und Filterlogik als Verdächtiger dazu. Genau diese Forensik ist der Kern unseres SEO-Audits: Hypothesen, Checks, Recovery-Plan.

Was Webdesigner beim Relaunch falsch machen

Das größte Risiko beim Relaunch kommt nicht von der Technik. Das größte Risiko kommt von übereifrigen Webdesignern oder Agenturen, die versuchen, grafisch das Rad neu zu erfinden. 3 Dinge leiden zuerst: Bedienkonzept, Navigation und die Auffindbarkeit von Content.

Kunden, die den alten Shop oder die alte Website regelmäßig besucht haben, finden sich plötzlich nicht mehr zurecht. Das Bedienkonzept hat sich komplett geändert, die Navigation ist anders aufgebaut. Der Content steht an anderen Stellen oder ist sogar ganz weg.

Ein Relaunch darf das Design modernisieren. Ein Relaunch darf die Technik verbessern. Aber ein Relaunch sollte das Bedienkonzept nicht ohne guten Grund über den Haufen werfen. Content sollte sich zum Teil wiederfinden lassen. Die Seitenstruktur sollte für wiederkehrende Besucher nachvollziehbar bleiben.

Relaunch und KI-Sichtbarkeit: Warum auch ChatGPT deine Redirects braucht

Die meisten planen einen Relaunch ausschließlich aus Google-Perspektive. Das reicht 2026 nicht mehr. ChatGPT, Perplexity und Googles AI Overviews (AI = Artificial Intelligence) zitieren Websites, und sie zitieren spezifische URLs. Die Redirect-Planung muss deshalb 2 Welten abdecken: Suchmaschinen-Rankings und KI-Zitationen.

LLMs aktualisieren langsamer als Google

Google crawlt deine neue Seite innerhalb von Tagen. LLMs aktualisieren ihre Wissensbasis deutlich langsamer. Deine alte URL läuft nach dem Relaunch ins Leere, aber ChatGPT zitiert sie möglicherweise weiter. Der Verlust bleibt unbemerkt, weil die Search Console KI-Zitationen nicht trackt.

Saubere Redirects schützen deswegen Google-Rankings genauso wie KI-Zitationen. Die Redirect-Kaskade gilt für GEO (Generative Engine Optimization) exakt so wie für klassisches SEO.

Schema-Markup beim Relaunch vollständig migrieren

FAQ-Schema, Organization-Markup und HowTo gehen bei Relaunches am häufigsten verloren, weil das Markup im CMS unsichtbar bleibt. LLMs fehlen dann strukturierte Ankerpunkte, um deine Inhalte einzuordnen. Ein Relaunch ohne FAQ-Schema kann Sichtbarkeit in AI Overviews kosten. Vor dem Go-Live deshalb das Markup der 10 wichtigsten Seiten exportieren, nach dem Launch gegenprüfen.

Content-Konsolidierung beim Relaunch: Zusammenlegen statt Aufsplittern

Viele Relaunches verteilen Content auf mehrere Unterseiten, wegen der besseren Übersicht. Eine Seite, die vorher klar für ein Thema stand, wird von LLMs als Quelle zitiert. Verteilt der Relaunch den Inhalt auf drei Unterseiten, verliert sie diesen Status. Zusammenlegen ist in der Regel besser als Aufsplittern, weil LLMs zusammenhängende, tiefe Inhalte bevorzugen.

Bei wenig Autorität steht sogar noch mehr auf dem Spiel als der Zitierquellen-Status: Im SEO-Contest 2026 blieb eine Unterseite, die eine Startseiten-Sektion fast wortgleich doppelte, auf der jungen Domain dauerhaft bei „gecrawlt, nicht indexiert“. Nach 6 Tagen wurde sie eingestampft und per 301 auf die Startseite konsolidiert, damit war das Indexierungsproblem gelöst. Der Beitrag zur Google Sandbox dokumentiert den Fall.

Wenn du einen Relaunch planst und eine zweite Meinung willst: Wir schauen uns deine aktuelle Situation an, bevor die erste URL angefasst wird. Zum SEO-Audit.

Häufige Fragen zum Thema Website Relaunch

Quellen

Die 4 wichtigsten Dokumentationen zu Redirects, HTTP-Statuscodes (HTTP = Hypertext Transfer Protocol) und Website-Umzügen:

• Google Search Central: Websiteumzug mit URL-Änderungen
• Google Search Central: HTTP-Statuscodes und Redirects
• Screaming Frog: How to Audit Redirects
• Google Search Console: Change of Address Tool