Ein Relaunch ist fast immer eine gute Entscheidung, ein neues Design, ein schnelleres System, eine Struktur, die zum heutigen Geschäft passt. Und fast immer ist es auch der Moment, in dem ein Unternehmen am meisten organischen Traffic riskiert, den es sich über Jahre erarbeitet hat. Google selbst hält dazu offen fest, worum es bei einer Adressänderung technisch geht: „In diesem Artikel erfährst du, wie du die URLs bestehender Seiten deiner Website änderst und dabei die negativen Auswirkungen auf deine Google-Suchergebnisse so gering wie möglich hältst." Genau diese Aufgabe, URLs, Inhalte und Signale unbeschadet in ein neues System zu überführen, ist der Kern jeder SEO-Relaunch-Checkliste. Dieser Beitrag ordnet sie anhand von Googles eigener Dokumentation ein und zeigt an einem eigenen Projekt, wie sich das in der Praxis auswirkt.
Warum Website-Relaunches Rankings kosten
Die Ursache ist selten das neue Design an sich. Sie liegt fast immer in der Lücke zwischen dem, was für Redakteure und Kunden sichtbar ist, und dem, was der Googlebot tatsächlich vorfindet. Eine neue Kategorie-Struktur, ein neues Content-Management-System oder ein neuer Shop-Unterbau verschieben URLs, ohne dass jemand konsequent von der alten zur neuen Adresse weiterleitet. Backlinks, die jahrelang auf eine bestimmte Seite verwiesen haben, laufen ins Leere, Meta-Angaben gehen bei der Migration verloren, und eine noindex-Markierung, die eigentlich nur für die Testphase gedacht war, bleibt nach dem Go-Live einfach stehen. Jeder dieser Punkte für sich ist ein kleiner technischer Fehler. In der Summe ergeben sie den Traffic-Einbruch, den Unternehmen nach einem Relaunch verzeichnen.
Google selbst rahmt die Erwartungshaltung dabei realistisch, nicht beschönigend: „Rechne mit vorübergehenden Schwankungen beim Website-Ranking. Immer wenn du wesentliche Änderungen an deiner Website vornimmst, können Schwankungen im Ranking auftreten, während Google deine Website neu crawlt und indexiert." Eine gewisse Bewegung in den Rankings ist also normal und kein Alarmsignal für sich allein. Das strukturelle Risiko beginnt erst dort, wo aus einer kurzen Schwankung ein dauerhafter Verlust wird, weil Signale schlicht nicht mehr ankommen. Wie groß dieser Unterschied in der Praxis ausfallen kann, zeigt ein eigenes Projekt aus dem E-Commerce-Bereich: Vor dem Relaunch von Baustoffshop.de stand genau diese Sorge im Raum, ein Verlust von 30 bis 70 Prozent der organischen Sichtbarkeit, wie er bei einem Shop-Relaunch dieser Größenordnung erfahrungsgemäß droht. Wie sich dieses Risiko technisch vermeiden lässt, zeigen die folgenden Abschnitte im Detail, mit dem tatsächlichen Ergebnis dieses konkreten Projekts weiter unten.
Vor dem Relaunch: Baseline und Redirect-Mapping
Wer erst nach dem Go-Live über Redirects nachdenkt, hat den kritischsten Schritt bereits verpasst. Die Vorbereitung beginnt mit einer vollständigen Bestandsaufnahme der aktuellen Website: ein Crawl aller indexierten URLs, ein Export der Seiten mit nennenswertem organischem Traffic und ein Blick auf das Backlink-Profil, um zu wissen, welche URLs von außen verlinkt sind und deshalb besonders schützenswert sind. Diese Bestandsaufnahme ist die Baseline, gegen die sich später jeder Erfolg oder Rückschritt überhaupt erst messen lässt.
Auf dieser Grundlage entsteht das Redirect-Mapping, eine Tabelle, die jeder alten URL genau eine neue Ziel-URL zuordnet. Entscheidend ist das Wort genau: Eine Sammelweiterleitung, die dutzende unterschiedliche alte Unterseiten pauschal auf die neue Startseite schickt, mag technisch einfacher sein, wird von Google aber häufig wie eine Soft-404 behandelt und überträgt praktisch keinen Rankingwert. Jede URL mit nennenswertem Traffic oder Backlinks braucht ein eigenes, thematisch passendes Ziel. Bei kleinen Websites lässt sich diese Zuordnung von Hand in einer Tabelle pflegen, bei Shops mit mehreren Tausend Produkt- oder Kategorie-URLs braucht es dafür ein automatisiertes Mapping, das alte und neue Struktur programmatisch abgleicht.
Redirects richtig setzen: 301, Laufzeit und Ketten
Für die eigentliche Weiterleitung empfiehlt Google eine klare Methode: „Falls du die in den Ergebnissen einer Suchmaschine angezeigte URL einer Seite ändern musst, empfehlen wir, nach Möglichkeit eine dauerhafte serverseitige Weiterleitung zu verwenden." Konkret gilt dabei: „Die Statuscodes 301 und 308 bedeuten, dass eine Seite dauerhaft an einen neuen Speicherort verschoben wurde." Der Unterschied zu einer temporären 302-Weiterleitung ist dabei mehr als eine technische Feinheit. Bei einem 301 gilt: „Der Googlebot folgt der Weiterleitung und die Indexierungspipeline versteht die Weiterleitung als Signal dafür, dass das Weiterleitungsziel kanonisch sein muss." Bei einem 302 dagegen „folgt der Googlebot der Weiterleitung, aber die Indexierungspipeline verwendet die Weiterleitung nicht als Signal dafür, dass das Weiterleitungsziel kanonisch sein sollte". Wer nach einem Relaunch aus Vorsicht auf 302 setzt, weil sich ja noch etwas ändern könnte, verzichtet damit genau auf das Signal, das Rankings überhaupt erst überträgt.
Ebenso wichtig wie der richtige Statuscode ist die Frage, wie lange eine Weiterleitung stehen bleiben muss. Hier ist die Empfehlung von Google konkreter, als die meisten Checklisten annehmen: „Behalte die Weiterleitungen möglichst lange bei, generell mindestens für ein Jahr. In diesem Zeitraum kann Google alle Signale an die neuen URLs übertragen, einschließlich des Crawlens und Zuweisens von Links auf anderen Websites, die auf deine alten URLs verweisen." Wer Redirects schon nach wenigen Wochen wieder abschaltet, weil das Projekt formal abgeschlossen ist, kappt den Übertragungsweg, bevor er seine Wirkung entfaltet hat. Zusätzlich gilt es, Redirect-Ketten zu vermeiden, bei denen eine alte URL erst auf eine zweite Zwischen-URL und von dort erst auf das eigentliche Ziel verweist. Jede zusätzliche Weiterleitung in einer Kette verlangsamt den Ladevorgang und ist eine zusätzliche Fehlerquelle, technisch sauber ist ausschließlich der direkte Sprung von der alten zur endgültigen neuen URL.
Die Staging-Falle: Wenn robots.txt den eigenen noindex-Tag blockiert
Ein Fehler, der in kaum einer Checkliste die nötige Tiefe bekommt, betrifft die Absicherung der Testumgebung. Üblich ist die Empfehlung, eine Staging-Website entweder per robots.txt zu sperren oder mit einem noindex-Tag zu versehen, häufig werden beide Optionen wie austauschbare Varianten derselben Maßnahme behandelt. Genau das ist der Denkfehler, und Googles eigene Dokumentation zum Robots-Meta-Tag benennt ihn unmissverständlich: „Falls eine Seite aufgrund der robots.txt-Datei nicht gecrawlt werden darf, werden mögliche Informationen zur Indexierung oder Bereitstellung nicht gefunden und daher ignoriert." Und weiter: „Falls Indexierungs- oder Bereitstellungsregeln befolgt werden müssen, darf kein Crawler daran gehindert werden, die URLs zu crawlen, die diese Regeln enthalten."
Übersetzt in die Relaunch-Praxis heißt das: Eine Staging-Seite, die per robots.txt komplett gesperrt ist, verhindert damit gleichzeitig, dass Google den dort hinterlegten noindex-Tag überhaupt zu Gesicht bekommt. Wird die Staging-URL trotzdem irgendwo verlinkt, etwa aus einem alten Tab, einem Social-Media-Post oder einer Weiterleitung, die versehentlich zu früh live geschaltet wurde, kann Google sie ohne Inhalt und ohne Snippet trotzdem in den Index aufnehmen, weil die einzige Anweisung, die das verhindern würde, für den Crawler unsichtbar bleibt. Der sichere Weg ist deshalb die genau umgekehrte Kombination: die Staging-Seite crawlbar lassen, aber mit einem funktionierenden noindex-Meta-Tag versehen, ergänzt um einen Passwortschutz, der Testbesucher ohnehin fernhält. Vor dem Go-Live gehört dieser Tag dann zuverlässig entfernt, denn dieselbe Regel gilt spiegelverkehrt für die neue Live-Website: Bleibt dort ein Test-noindex versehentlich stehen, verschwindet die frisch gelaunchte Seite zuverlässig aus dem Index, ganz ohne dass ein Redirect-Fehler daran schuld wäre.
Content, Meta-Daten und Crawl-Budget beim Go-Live
Neben Redirects und Indexierungssteuerung entscheidet die inhaltliche Migration darüber, ob eine Seite ihre Position behält. Title-Tags, Meta-Descriptions, Überschriften-Struktur und Alt-Texte sollten für jede migrierte URL einzeln kontrolliert werden, nicht nur stichprobenartig. Gerade bei einem Wechsel des Content-Management-Systems verschwinden solche Angaben leicht, weil das neue Template ein anderes Feld erwartet als das alte System befüllt hat. Ebenso wichtig ist die Frage, ob Inhalte bei der Migration tatsächlich vollständig übernommen wurden oder ob im neuen System gekürzte Platzhaltertexte stehen, die zwar hübscher aussehen, aber weniger Substanz haben als das Original.
Beim Crawl-Budget lohnt sich ein nüchterner Blick auf Googles eigene Kriterien, denn hier wird in vielen Ratgebern mehr Sorge verbreitet, als die Dokumentation selbst hergibt. Relevant wird das Thema laut Google vor allem für „große Websites (über 1 Million einzelne Seiten), deren Inhalt sich häufig (einmal pro Woche) ändert" sowie für „mittelgroße Websites (mehr als 10.000 einzelne Seiten) mit Inhalten, die sich sehr schnell (täglich) ändern". Für alle anderen gilt eine deutlich entspanntere Einschätzung: „Wenn deine Website nicht viele Seiten hat, die sich schnell ändern, oder falls die Seiten anscheinend noch an dem Tag gecrawlt werden, an dem sie veröffentlicht wurden, brauchst du dieses Handbuch nicht zu lesen." Für die meisten Unternehmenswebsites und kleineren bis mittleren Shops ist Crawl-Budget im Alltag schlicht kein Nadelöhr.
Während eines Relaunchs ändert sich das vorübergehend, weil Google für kurze Zeit sowohl die alten als auch die neuen URLs verarbeiten muss. Google benennt diesen Effekt selbst: Ereignisse, „die die gesamte Website betreffen, wie etwa der Umzug einer Website", führen „zu einer Zunahme des Crawling-Bedarfs, da der Inhalt unter den neuen URLs neu verarbeitet werden muss". Diese Spitze ist normal, zeitlich begrenzt und für die allermeisten Websites kein Grund zur Sorge, solange die Redirects sauber gesetzt sind und Google seine Arbeit ungestört erledigen kann. Nur bei sehr großen Katalogen mit zehntausenden Produkt-URLs lohnt es sich, das Crawling in den ersten Tagen aktiv über die Search Console zu beobachten.
Die ersten Wochen nach Go-Live: Monitoring, das wirklich zählt
Ein technisch sauberer Launch ist die Voraussetzung, nicht der Abschluss des Projekts. In den ersten Tagen nach dem Go-Live lohnt sich ein täglicher Blick auf drei Signale: die Abdeckung in der Search Console, um neu auftretende Crawling-Fehler sofort zu erkennen, die Zahl der 404-Fehler, die auf vergessene Redirects hinweist, und die Rankings der wichtigsten Seiten, um Ausreißer von der normalen Schwankung zu unterscheiden, die Google selbst als Begleiterscheinung jeder größeren Änderung einordnet. Nach dem Go-Live gehört außerdem die aktualisierte XML-Sitemap eingereicht, denn Google hält dazu fest: „Reiche die neue Sitemap in der Search Console ein. So kann Google die neuen URLs besser kennenlernen."
Ein Sonderfall betrifft den Wechsel der Domain, nicht nur der URL-Struktur auf derselben Domain. Nur dafür ist das Change-of-Address-Tool in der Search Console gedacht. Als Vorarbeit verlangt Google konkret: „Implementieren Sie eine 301-Weiterleitung von Ihrer alten zu Ihrer neuen Startseite." Bei der Weiterleitungsdauer nennt die Dokumentation zu diesem Tool einen eigenen, niedrigeren Wert als die allgemeine Umzugs-Anleitung aus dem vorigen Abschnitt: „Speichern Sie die Weiterleitungen für mindestens 180 Tage – oder länger, wenn von der Google Suche aus weiterhin Traffic über die Weiterleitungen läuft." Wer sie vorher entfernt, riskiert genau das, wovor Google selbst warnt: „Nach Ablauf der 180 Tage erkennt Google zwischen der alten und der neuen Website keine Beziehung mehr und behandelt die alte Website als unabhängige Website, sofern sie noch vorhanden ist und gecrawlt werden kann." Ein Widerspruch zur einjährigen Empfehlung ist das nicht, die 180 Tage sind das Minimum für dieses eine Tool, keine Obergrenze für die Weiterleitungen selbst. Bleibt die Domain gleich und ändert sich nur die interne URL-Struktur, kommt das Change-of-Address-Tool ohnehin nicht zum Einsatz, hier tragen allein die 301-Redirects und die neue Sitemap die gesamte Last der Übertragung.
Die SEO-Relaunch-Checkliste: Vorher, während und nach dem Go-Live
Alle bisherigen Punkte lassen sich zu einer Checkliste verdichten, die sich an den drei Phasen jedes Relaunchs orientiert.
Vor dem Go-Live
Vollständigen Crawl der aktuellen Website erstellen und URLs mit Traffic und Backlinks dokumentieren
Redirect-Mapping anlegen, jede relevante Alt-URL erhält genau eine neue Ziel-URL
Meta-Daten, Überschriften und Alt-Texte für jede migrierte Seite einzeln prüfen, nicht nur stichprobenartig
Staging-Umgebung mit noindex und Passwortschutz absichern, robots.txt dabei crawlbar lassen
Während des Go-Live
301-Weiterleitungen aktivieren und stichprobenartig direkt testen, keine Weiterleitungsketten
Alle noindex-Tags von den neuen Live-Seiten entfernen
Neue XML-Sitemap generieren und in der Search Console einreichen
Bei einem Domainwechsel zusätzlich das Change-of-Address-Tool in der Search Console starten
Nach dem Go-Live
Search-Console-Abdeckung und 404-Fehler in den ersten zwei bis vier Wochen täglich prüfen
Rankings der wichtigsten Seiten beobachten und normale Schwankungen von echten Verlusten unterscheiden
Redirects mindestens ein Jahr aktiv lassen, nicht vorzeitig aus Aufräumgründen entfernen
Nach den ersten Wochen einen Abgleich gegen die vor dem Relaunch erstellte Baseline ziehen
Praxisbeispiel: Wie Baustoffshop.de 15.247 URLs ohne Rankingverlust migrierte
Wie sich diese Punkte in einem konkreten Projekt niederschlagen, zeigt der Relaunch von Baustoffshop.de, einem Online-Händler für Baumaterialien, den Beyond Media SEO-seitig begleitet hat. Der Shop lief auf dem End-of-Life-System Magento 1 und wechselte auf Magento 2, verbunden mit einer vollständig neuen technischen Basis für über 15.000 Produktseiten. Statt die Weiterleitungen manuell zu pflegen, wurden alle 15.247 URLs in einer Datenbank erfasst und per Script 1:1 den neuen Magento-2-Adressen zugeordnet, inklusive der 347 Redirect-Ketten, die im Altsystem historisch entstanden waren und vor dem Launch aufgelöst wurden, sodass am Ende jede URL über höchstens einen einzigen 301-Sprung erreichbar war.
Das Ergebnis: 0 Prozent Ranking-Verlust und 0 neue 404-Fehler nach dem Launch, bei einem Sichtbarkeitsindex, der in der eigentlichen Relaunch-Woche nur minimal von 42,3 auf 41,8 schwankte, innerhalb der auch von Google beschriebenen normalen Bandbreite. Drei Monate später lag er bei 55,8, ein Anstieg von 32 Prozent gegenüber dem Ausgangswert, den Beyond Media auf die spürbar bessere technische Basis von Magento 2 zurückführt, unter anderem eine Ladezeit-Verbesserung des Largest Contentful Paint von 6,2 auf 2,1 Sekunden. Begleitet wurde der Launch von zwölf Wochen täglichem Monitoring aus Crawl-Kontrolle, Search-Console-Meldungen und wöchentlichen Ranking-Reports, damit auch bei einem technisch sauberen Go-Live auftretende Einzelfälle sofort auffielen. Dieses Ergebnis gilt für dieses eine Projekt und ist keine pauschale Garantie für jeden Relaunch, es zeigt aber, in welcher Größenordnung sich der oben beschriebene Prozess auszahlt, wenn er konsequent durchgezogen wird.
Häufig gestellte Fragen
Wie lange sollte ich Redirects nach einem Relaunch aktiv halten?
Laut Google generell mindestens ein Jahr. In diesem Zeitraum kann Google alle Rankingsignale von der alten auf die neue URL übertragen, ein vorzeitiges Abschalten der Weiterleitungen unterbricht diesen Prozess.
Reicht robots.txt, um eine Staging-Umgebung vor Google zu verstecken?
Nein. Eine robots.txt-Sperre verhindert, dass Google die Seite überhaupt crawlt, und damit auch, dass ein dort hinterlegter noindex-Tag gesehen wird. Wird die Staging-URL trotzdem irgendwo verlinkt, kann sie ohne Inhalt im Index landen. Sicherer ist noindex kombiniert mit Passwortschutz, bei crawlbarer robots.txt.
Muss ich mir bei einem normalen Relaunch Sorgen um mein Crawl-Budget machen?
In den meisten Fällen nicht. Google stuft Crawl-Budget vor allem für Websites mit über einer Million Seiten oder mit mehr als 10.000 täglich aktualisierten Seiten als relevant ein. Während der eigentlichen Migration steigt der Crawling-Bedarf vorübergehend, weil alte und neue URLs parallel verarbeitet werden, das ist normal und meist kein Grund zur Sorge.
Was ist der Unterschied zwischen einem 301- und einem 302-Redirect beim Relaunch?
Ein 301 signalisiert Google, dass die neue URL dauerhaft kanonisch ist, und überträgt entsprechend Rankingsignale. Ein 302 wird zwar befolgt, aber nicht als Signal für eine dauerhafte Verlagerung gewertet. Für einen Relaunch ist deshalb grundsätzlich 301 die richtige Wahl.
Brauche ich das Change-of-Address-Tool in der Search Console?
Nur bei einem Wechsel der Domain oder Subdomain. Ändert sich lediglich die interne URL-Struktur auf derselben Domain, kommt das Tool nicht zum Einsatz, hier tragen die 301-Redirects und die neue Sitemap die gesamte Last der Signalübertragung.
Wie schnell merkt man, ob ein Relaunch Rankings gekostet hat?
Erste Anzeichen, etwa neue Crawling-Fehler oder 404-Seiten, zeigen sich meist innerhalb weniger Tage in der Search Console. Belastbare Aussagen zu Rankings und Traffic brauchen dagegen die vollen zwei bis vier Wochen intensiven Monitorings, um normale Schwankungen von echten Verlusten zu unterscheiden.
Was hat der Relaunch von Baustoffshop.de konkret gezeigt?
Bei der Migration von über 15.000 Produkt-URLs von Magento 1 auf Magento 2 blieb der Ranking-Verlust bei 0 Prozent, unter anderem durch lückenloses 1:1-URL-Mapping und die Auflösung von 347 historischen Redirect-Ketten. Drei Monate nach dem Launch lag der organische Traffic um 32 Prozent über dem Ausgangswert.
Fazit
Ein Relaunch kostet Rankings nicht, weil Suchmaschinen Veränderung grundsätzlich bestrafen, sondern weil an einzelnen technischen Stellen Signale verloren gehen, die vorher zuverlässig ankamen. Sauberes Redirect-Mapping mit 301 statt 302, mindestens ein Jahr aktiv gehaltene Weiterleitungen, eine Staging-Sperre, die noindex nicht versehentlich per robots.txt aushebelt, und ein konsequentes Monitoring in den ersten Wochen sind dabei keine Kür, sondern die Punkte, an denen sich in der Praxis entscheidet, ob eine Website ihre Sichtbarkeit behält oder verliert. Wer dabei Unterstützung sucht: Beyond Media, seit 2004 am Markt und Google Premier Partner, begleitet Website- und Shop-Relaunches in genau dieser Systematik, von der Baseline-Analyse bis zum Monitoring nach dem Go-Live, je nach Projektgröße üblicherweise über einen Zeitraum von vier bis zwölf Wochen. Der naheliegende erste Schritt dafür ist ein unverbindliches Gespräch über Umfang und Risiko des eigenen Projekts, noch bevor die erste URL migriert wird.
Quellen
Google Search Central: Websites mit URL-Änderungen verschieben
Google Search Central: Weiterleitungen und die Google-Suche
Google Search Central: Robots-Meta-Tag, meint noindex-HTTP-Header
Google Search Central: Crawling-Budget für große Websites verwalten
Google Search Console-Hilfe: Tool zum Ändern der Adresse
Beyond Media Case Study: Baustoffshop.de, 0% Ranking-Verlust beim Shop-Relaunch (interne Referenz)
