SEO-Relaunch ohne Traffic-Verlust: Checkliste aus über 20 Jahren Praxis

Kurzantwort

Ein Website-Relaunch - egal ob neues Design, neues CMS oder neue URL-Struktur - gehört zu den riskantesten Momenten im gesamten SEO-Lebenszyklus einer Website. Der häufigste Fehler ist, SEO als letzten Schritt kurz vor dem Livegang zu behandeln, statt als durchgehende Anforderung während der gesamten Planung. Die wichtigsten Absicherungen sind eine vollständige Redirect-Map aller bestehenden URLs, ein technischer Vergleich zwischen alter und neuer Seitenstruktur vor dem Livegang, sowie eine engmaschige Kontrolle der ersten Wochen nach dem Go-Live, um Probleme früh zu erkennen.

Warum sind Relaunches ein derart häufiger Grund für Sichtbarkeitsverlust?

Bei einem Relaunch ändern sich oft mehrere kritische Faktoren gleichzeitig: URL-Struktur, interne Verlinkung, technische Umsetzung, teilweise auch Inhalte selbst. Jede dieser Änderungen einzeln wäre für Google gut zu verarbeiten - in der Kombination und unter Zeitdruck kurz vor einem Launch-Termin passieren aber genau hier die meisten Fehler. Eine einzelne vergessene Weiterleitung mag unbedeutend wirken, aber bei einer Website mit tausenden URLs summieren sich viele kleine Lücken schnell zu einem spürbaren Sichtbarkeits- und Traffic-Verlust, der sich oft erst Wochen später in den Kennzahlen zeigt - zu einem Zeitpunkt, an dem die eigentliche Ursache längst nicht mehr offensichtlich ist.

Was gehört in eine vollständige Redirect-Map?

Eine Redirect-Map muss jede einzelne bestehende, indexierte URL der alten Website erfassen und ihr eine sinnvolle Zieladresse auf der neuen Website zuordnen - im Idealfall eine inhaltlich möglichst passende neue Seite, nicht pauschal die Startseite. Die Datenbasis dafür sind die alte XML-Sitemap, ein vollständiger Crawl der bestehenden Website sowie ein Abgleich mit den in der Google Search Console tatsächlich indexierten URLs - diese drei Quellen weichen in der Praxis fast immer voneinander ab, und nur die Kombination aller drei liefert eine wirklich vollständige Liste. Jede Weiterleitung sollte als dauerhafte 301-Weiterleitung umgesetzt werden, nicht als 302, damit Google die Umleitung als permanent und nicht als temporär interpretiert - mehr zum Unterschied im Glossar-Begriff Redirect 301.

Was passiert, wenn eine URL beim Relaunch schlicht vergessen wird?

Eine URL ohne Weiterleitung liefert nach dem Relaunch einen 404-Fehler. Für einzelne, wenig relevante Seiten ist das verschmerzbar. Bei URLs, die zuvor nennenswerten Traffic oder externe Backlinks gesammelt hatten, bedeutet ein fehlender Redirect dagegen einen direkten, oft dauerhaften Verlust: Der zuvor aufgebaute Vertrauens- und Rankingwert dieser Seite geht verloren, weil er nicht auf eine neue Zieladresse übertragen wird. Externe Backlinks, die weiterhin auf die alte URL zeigen, verpuffen ebenfalls wirkungslos, statt der neuen Seite weiterhin zu nützen.

Wie testet man einen Relaunch technisch, bevor er live geht?

Der wichtigste Test ist ein vollständiger Vergleich zwischen alter und neuer Sitemap, um systematisch zu identifizieren, welche URLs verschwinden, welche neu hinzukommen und welche ihre Struktur ändern. Darauf aufbauend sollte jede geplante Weiterleitung in einer Staging-Umgebung stichprobenartig, bei kritischen Seiten vollständig, getestet werden, bevor sie live geschaltet wird. Ergänzend lohnt sich ein technischer Vergleich der wichtigsten Onpage-Elemente - Title-Tags, Meta-Descriptions, strukturierte Daten, interne Verlinkung - zwischen alter und neuer Version, um sicherzustellen, dass diese Elemente beim Relaunch nicht versehentlich verloren gehen oder sich unbeabsichtigt verschlechtern.

Sollte man Design-Relaunch und URL-Struktur-Änderung gleichzeitig durchführen?

Wo immer organisatorisch möglich, empfiehlt es sich, diese beiden Änderungen zu entkoppeln. Ein reiner Design-Relaunch bei gleichbleibender URL-Struktur ist aus SEO-Sicht risikoarm, weil die wichtigsten Rankingsignale (URLs, interne Verlinkungsstruktur) unverändert bleiben. Wird gleichzeitig auch die URL-Struktur geändert, addieren sich die Risiken beider Änderungen, und im Fall eines Problems lässt sich schwerer isolieren, ob das Design, die neue Struktur oder eine Kombination beider Faktoren die Ursache ist. Wenn eine gleichzeitige Umsetzung unumgänglich ist, sollte die Redirect-Planung entsprechend noch sorgfältiger und mit mehr zeitlichem Puffer vor dem Launch-Termin erfolgen.

Wer sollte innerhalb eines Unternehmens die Verantwortung für die Redirect-Map konkret tragen?

Ein häufiges Organisationsproblem ist, dass die Redirect-Map zwischen mehreren Parteien - Agentur, interne IT, CMS-Anbieter - unklar verteilt bleibt, mit dem Ergebnis, dass am Ende niemand die volle Verantwortung für ihre Vollständigkeit übernimmt. Wirksamer ist es, von Anfang an eine einzelne verantwortliche Person oder Rolle zu benennen, die die Redirect-Map als zusammenhängendes Dokument führt, alle Zulieferungen der beteiligten Parteien konsolidiert und die finale Freigabe vor dem Go-Live erteilt. Diese Person muss nicht selbst jede einzelne Weiterleitung technisch umsetzen, trägt aber die Verantwortung dafür, dass die Gesamtliste vollständig, konsistent und rechtzeitig vor dem Launch-Termin fertiggestellt ist.

Wie lange dauert es, bis Google einen Relaunch vollständig verarbeitet hat?

Das hängt stark von Website-Größe und Crawl-Frequenz ab. Bei kleineren Websites mit wenigen hundert URLs kann Google einen sauber umgesetzten Relaunch innerhalb weniger Tage bis Wochen vollständig nachvollziehen. Bei sehr großen Websites mit hunderttausenden URLs kann derselbe Prozess mehrere Monate dauern, insbesondere wenn Crawl-Budget bereits vor dem Relaunch ein limitierender Faktor war. Mehr zum Zusammenhang im Artikel Crawl-Budget bei Millionen-Seiten-Websites. Während dieser Übergangsphase sind leichte Schwankungen in Rankings und Sichtbarkeit normal und kein grundsätzliches Warnsignal, solange sich der Trend nach einigen Wochen stabilisiert statt weiter zu verschlechtern.

Welche Kennzahlen sollte man in den ersten Wochen nach dem Go-Live besonders eng beobachten?

Die Crawling-Statistiken in der Google Search Console zeigen frühzeitig, ob Googlebot ungewöhnlich viele 404- oder 5xx-Fehler auf der neuen Website findet. Der Abdeckungsbericht zeigt, ob zuvor indexierte Seiten plötzlich als “nicht gefunden” oder “ausgeschlossen” markiert werden. Der Sichtbarkeitsindex einer Rank-Tracking-Software liefert zusätzlich einen aggregierten Trendindikator, der einzelne Keyword-Schwankungen glättet und echte strukturelle Probleme von normalem Rauschen unterscheiden hilft. Wichtig ist tägliche statt wöchentliche Kontrolle in den ersten zwei bis drei Wochen nach dem Launch, damit Probleme früh genug erkannt werden, um noch gegenzusteuern.

Was tun, wenn nach dem Go-Live trotz sorgfältiger Planung ein Sichtbarkeitsverlust auftritt?

Auch bei bester Vorbereitung lässt sich ein gewisser Grad an Schwankung nie vollständig ausschließen - wichtig ist dann die schnelle, systematische Fehlersuche statt Panik. Der erste Schritt ist immer, zu prüfen, ob es sich um eine breite, seitenübergreifende Bewegung handelt oder um Verluste bei bestimmten Seitentypen oder Themenbereichen - Letzteres deutet meist auf ein konkretes technisches oder inhaltliches Problem in genau diesem Bereich hin, nicht auf ein grundsätzliches Relaunch-Problem. Der zweite Schritt ist der Abgleich mit der Redirect-Map: Stichprobenartig prüfen, ob die traffic-stärksten der alten URLs tatsächlich korrekt weiterleiten, denn genau hier verstecken sich in der Praxis die meisten nachträglich entdeckten Fehler. Wichtig dabei: Nicht jede Schwankung erfordert sofortiges Gegensteuern - manche Effekte sind vorübergehende Neubewertungsphasen, die sich innerhalb weniger Wochen von selbst stabilisieren, wenn keine tatsächlichen strukturellen Fehler vorliegen.

Wie unterscheidet sich das Relaunch-Risiko zwischen einem CMS-Wechsel und einem reinen Redesign?

Ein CMS-Wechsel bringt zusätzliche Risiken mit sich, die ein reines Redesign nicht hat: Das neue System generiert URLs, Metadaten, strukturierte Daten und interne Verlinkung möglicherweise nach einer völlig anderen Logik als das alte System, oft ohne dass das Projektteam alle Unterschiede von Anfang an kennt. Ein reines Redesign auf demselben CMS behält dagegen in der Regel die zugrunde liegende technische Struktur bei und verändert primär visuelle Elemente. Bei einem CMS-Wechsel empfiehlt sich deshalb ein deutlich umfangreicherer technischer Testkatalog vor dem Go-Live, der gezielt prüft, ob alle SEO-relevanten Elemente - Title-Tags, Canonical-Tags, strukturierte Daten, interne Verlinkungslogik, Sitemap-Generierung - im neuen System korrekt und vollständig funktionieren, nicht nur oberflächlich ähnlich aussehen wie vorher.

Welche Rolle spielt eine Staging-Umgebung im finalen Test vor dem Go-Live?

Eine Staging-Umgebung, die der späteren Live-Umgebung so nahe wie möglich entspricht, ist die letzte und wichtigste Gelegenheit, Fehler zu finden, bevor sie echten Nutzer:innen und Googlebot begegnen. In der Praxis lohnt sich ein fester Testkatalog, der bei jedem Relaunch identisch durchlaufen wird: Stichprobenartige Prüfung der wichtigsten Redirects, Kontrolle, ob robots.txt die Staging-Umgebung korrekt blockiert (ein überraschend häufiger Fehler ist eine versehentlich indexierbare Staging-Umgebung, die parallel zur echten Website im Index landet), sowie ein technischer Vergleich der strukturierten Daten zwischen alter und neuer Version. Ein oft übersehener Punkt: Die Staging-Umgebung sollte so früh wie möglich vor dem geplanten Go-Live-Termin vollständig funktionsfähig sein, nicht erst wenige Tage davor - je knapper das Zeitfenster für Tests, desto höher die Wahrscheinlichkeit, dass gefundene Probleme unter Zeitdruck nur oberflächlich statt gründlich behoben werden.

Sollte man einen Relaunch schrittweise oder auf einen Schlag durchführen?

Wo technisch möglich, ist ein schrittweiser Rollout - etwa Bereich für Bereich oder Sprachversion für Sprachversion - dem klassischen “Big Bang”-Ansatz vorzuziehen, bei dem die komplette Website an einem einzigen Stichtag komplett ausgetauscht wird. Ein schrittweiser Rollout erlaubt es, aus den ersten migrierten Bereichen zu lernen und Probleme zu beheben, bevor der Rest der Website folgt - ein einzelner grundlegender Fehler betrifft dann nur einen Teilbereich statt der gesamten Website gleichzeitig. In der Praxis ist ein vollständig schrittweiser Rollout nicht immer organisatorisch oder technisch umsetzbar, insbesondere bei einem vollständigen CMS-Wechsel. Wo er möglich ist, reduziert er aber das Gesamtrisiko erheblich gegenüber einem einzigen, unumkehrbaren Umschaltmoment für die komplette Website.

Was ist der wichtigste organisatorische Erfolgsfaktor bei einem Relaunch?

SEO muss von Anfang an Teil des Relaunch-Projekts sein, nicht ein nachgelagerter Prüfschritt kurz vor dem Launch-Termin. In der Praxis bedeutet das: SEO-Anforderungen bereits in der technischen Konzeptions- und Design-Phase mit einbeziehen, eine feste Verantwortlichkeit für die Redirect-Map benennen, und einen Zeitplan einplanen, der ausreichend Puffer für Tests vor dem Go-Live lässt - Relaunches, die unter akutem Zeitdruck kurz vor einem fixen Termin fertiggestellt werden, sind in der Praxis überproportional häufig von vermeidbaren SEO-Problemen betroffen. Mehr zur Gesamtstrategie auf der Kompetenz-Seite SEO-Relaunch.