SEO-Relaunch: was du in den ersten 90 Tagen erwarten darfst

Vorab: Zur Frage, wie lange ein Relaunch die organische Sichtbarkeit kostet, kursieren zwei Zahlen, und beide stammen aus belastbaren Quellen. Google schreibt in der Dokumentation zum Umzug mit URL-Wechsel: „As a general rule, a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer." Die Agentur SALT hat am 26. Juni 2026 die Auswertung von 1.052 Domain-Migrationen veröffentlicht. Median bis zur Erholung: 304 Tage. Mittelwert: 489 Tage. Ein paar Wochen gegen rund zehn Monate.

Der Widerspruch löst sich auf, sobald du fragst, was jeweils gemessen wird. Google spricht von „most pages to move in our index". Das ist Reindexierung: der Zeitpunkt, zu dem die neuen URLs die alten im Index abgelöst haben. SALT definiert Erholung anders, wörtlich: „the point at which the new domain's monthly organic search traffic equalled or exceeded the pre-migration baseline of the old domain". Das ist Traffic-Erholung: der Zeitpunkt, zu dem der monatliche organische Traffic wieder auf dem Niveau von vorher liegt.

Zwei Messgrößen, zwei Zeitskalen, kein Widerspruch. Zwischen beiden liegt genau das, was ein Relaunch auslöst: Google hat deine Seiten wieder im Index, bewertet sie aber neu, und diese Neubewertung braucht Rankings, Klicks und Zeit.

Genau genommen sind es drei Ebenen, und wer sie auseinanderhält, diskutiert anders. Erstens die Indexierung: Kennt Google die neuen Adressen? Zweitens die Rankings: Auf welchen Positionen stehen sie? Drittens der Traffic: Wie viele Menschen klicken tatsächlich? Die erste Ebene ist eine Frage von Tagen bis Wochen und in der Search Console direkt ablesbar. Die zweite folgt mit Verzug und schwankt. Die dritte hängt zusätzlich an Saison, Wettbewerb und daran, ob die neuen Seiten die alten Suchanfragen überhaupt noch bedienen. Wenn im Statusbericht nur ein Wort steht, nämlich „Sichtbarkeit", ist der Bericht wertlos.

Die Verwechslung ist teuer. Im Kickoff fällt der Satz „nach ein paar Wochen ist das durch", und die Geschäftsführung hört ihn als Traffic-Zusage. Im dritten Monat steht dann der Krisentermin an, obwohl das Projekt planmäßig läuft. Die häufigste Ursache für als gescheitert geltende Relaunches ist nach meiner Erfahrung kein technischer Fehler, sondern eine Erwartung, die niemand je präzisiert hat. Deshalb beginnt dieser Artikel nicht mit einer Checkliste, sondern mit dem Erwartungskorridor: Was darfst du wann sehen, und ab wann ist es ein Schadensfall?

Die SALT-Reihe ist der größte mir bekannte öffentlich zugängliche Datensatz zum Thema. Die Verteilung: 22,8 Prozent der Migrationen hatten ihr Vorher-Niveau nach 90 Tagen wieder erreicht, 27,8 Prozent nach 120 Tagen. 42 Prozent brauchten länger als zwölf Monate. 13,9 Prozent erreichten das alte Niveau auch nach drei Jahren nicht mehr.

Diese Zahlen sind nützlich, aber sie tragen weniger, als es aussieht. Drei Einschränkungen, die du kennen musst, bevor du sie in eine Vorstandsvorlage schreibst.

Andere Grundgesamtheit. SALT hat ausschließlich Migrationen von einer Domain auf eine andere untersucht, umgesetzt per 301-Weiterleitung. Wenn du deine Domain behältst und nur die URL-Struktur änderst, spielst du nicht in dieser Stichprobe. Der Relaunch unter gleicher Domain ist der deutlich häufigere Fall im Mittelstand, und er ist der mildere.

Andere Herkunft der Daten. Die Basis sind eigene Projekte plus „hundreds crowdsourced from the SEO community". Wer Fälle beisteuert, wählt aus. Ob die Auswahl systematisch zu den schmerzhaften Fällen tendiert, lässt sich nicht prüfen.

Enorme Streuung. Die Standardabweichung liegt bei über zwei Jahren. Damit ist der Median eine Orientierung, keine Prognose für deinen Fall: Ein einzelnes Projekt kann in unter drei Monaten erholt sein oder mehrere Jahre brauchen. Und die Auswertung ist beschreibend, nicht ursächlich. SALT schreibt selbst: „this study does not run regression analysis against migration quality factors". Der Datensatz sagt dir, wie lange es gedauert hat, nicht warum.

Was du daraus mitnimmst: Der Median von 304 Tagen ist kein Versprechen und keine Drohung. Er ist das Gegengift gegen die im deutschen Markt verbreitete Zusage, nach acht bis zwölf Wochen sei alles wieder da. Diese Zeitangabe steht in vielen Ratgebern, meist ohne Datenbasis. Damit beschreibt sie bestenfalls den günstigen Rand der Verteilung.

Daraus folgt eine Frage, die du im Agenturgespräch stellen kannst und die viel offenlegt: Woher stammt deine Zahl? Die im deutschen Markt sichtbaren Ratgeber nennen überwiegend Erholungszeiten zwischen wenigen Wochen und einigen Monaten, und sie stützen sich dabei fast durchgängig auf die eigene Projekterfahrung, ohne Fallzahl und ohne Definition. Das ist nicht wertlos, aber es ist eine Stichprobe unbekannter Zusammensetzung. Wer dir eine Erholungsdauer nennt, sollte drei Angaben machen können: was er zählt, wie viele Fälle dahinterstehen und woran er das Ende der Erholung festmacht. Kann er das nicht, ist die Zahl eine Hausnummer. Das gilt für den Median von 304 Tagen genauso wie für die acht Wochen.

Für die Planung heißt das zweierlei. Setze im Businessplan keine Traffic-Parität für das erste Quartal nach dem Umzug an, sondern beschreibe einen Korridor mit einem günstigen und einem ungünstigen Ast. Und lege den Go-Live-Termin nicht in die umsatzstärkste Phase des Jahres. Wenn dein Geschäft im November lebt, ziehst du im Februar um. Diese eine Entscheidung ist wirksamer als die meisten technischen Feinheiten, über die im Projekt gestritten wird.

Jetzt konkret, aus der Sicht dessen, der das Reporting bekommt. Google rechnet selbst mit Unruhe und schreibt es hin: „Expect temporary fluctuation in site ranking during the move. With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site."

Woche 1. Die Search Console zeigt sinkende Impressionen für die alten URLs und steigende Zahlen für die neuen. Beides gleichzeitig ist das erwartete Bild, kein Alarm. Die Daten laufen dort verzögert ein und nicht in Echtzeit. Wer am zweiten Tag nach Go-Live eine Zwischenbilanz zieht, bewertet unvollständige Daten.

Woche 2 bis 4. Der Index sortiert sich. Rankings springen, teilweise deutlich, auch nach unten. In dieser Phase kommt fast immer der Reflex, „schnell noch etwas zu optimieren". Widerstehe ihm: Jede weitere Änderung verlängert die Neubewertung, weil sie erneut Crawling und Indexierung auslöst.

Tag 30 bis 60. Die Kurve der neuen URLs sollte tragen. Der Vergleich, der zählt, ist nicht „gestern gegen heute", sondern der organische Gesamt-Traffic gegen denselben Zeitraum des Vorjahres.

Tag 90. Gut ein Fünftel der von SALT untersuchten Domain-Migrationen hatte hier das alte Niveau wieder erreicht, gut drei Viertel nicht. Wenn du an Tag 90 spürbar unter dem Vorher-Traffic liegst und die Tendenz steigt, ist das nach dieser Datenlage der Normalverlauf und kein Krisenfall. Der Krisentermin im dritten Monat ist meistens ein Artefakt der falschen Erwartung.

Was in dieses Reporting gehört, ist knapp: die Zahl der indexierten neuen URLs gegen die Zahl der geplanten, die Zahl der alten URLs mit Abrufen aus der Suche, der organische Traffic im Vorjahresvergleich und die Liste der Seiten mit dem größten Verlust. Vier Kennzahlen, ein Blatt. Alles darüber hinaus erzeugt im Lenkungskreis Diskussionen über Messmethoden statt über Maßnahmen.

Damit dieser Korridor überhaupt messbar ist, muss die Messung vor dem Go-Live stehen und nicht danach. Welche Ereignisse, Ziele und Segmente dazugehören, habe ich in Warum ein gutes Tracking-Setup Teil der Website-Planung ist beschrieben. Die Aufnahme des Ist-Zustands vor dem Umzug ist ein Thema für sich und gehört auf den Tisch, bevor du eine Agentur beauftragst.

Fluktuation ist normal. Drei Beobachtungen sind es nicht, und bei jeder davon gehörst du als Auftraggeber informiert, nicht erst im Monatsreport.

Erstens: 404 statt Weiterleitung auf Seiten mit Bestand. Wenn Adressen, die vorher Traffic oder Verweise hatten, ins Leere laufen, ist das kein Ranking-Thema, sondern ein Fehler im Mapping.

Zweitens: der falsche Statuscode. Google unterscheidet klar. Für 301 und 308 gilt: „Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." Für 302, 303 und 307 gilt: „Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical." Eine temporäre Weiterleitung überträgt das Kanonisierungssignal nicht.

Drittens: ein noindex, das keiner bestellt hat. Wenn die Sperre aus der Testumgebung mitwandert, verschwindet die Seite vollständig, nicht anteilig.

Wie das im Ernstfall aussieht, zeigt der bekannteste deutsche Fall: frankfurt.de. Sistrix hat ihn am 9. März 2020 dokumentiert, der Beitrag wurde am 12. April 2021 aktualisiert. Projektkosten laut Sistrix rund 1,4 Millionen Euro. Im Fließtext steht: „Seit der Woche zum 02.03.2020 hat die Domain gut 46% ihrer Sichtbarkeit bei Google verloren", und diese Angabe steht unter der Grafik zum mobilen Sichtbarkeitsverlauf. Die Ursache war keine exotische, und es war auch nicht nur eine: eine 302- statt einer 301-Weiterleitung, dazu alte Adressen aus dem Vorgängersystem im Verzeichnis /sixcms/, die mit 404 antworteten. Über diese Adressen liefen laut Sistrix noch mehrere hundert Top-10-Rankings.

Zwei Hinweise dazu, weil der Fall gerne falsch zitiert wird. Er stammt aus dem Jahr 2020 und nicht aus jüngerer Zeit. Und die vielzitierten „knapp 50 Prozent" stehen in der Überschrift der Quelle, im Text steht die mobile Zahl von gut 46 Prozent. Wer mit diesem Fall argumentiert, sollte ihn korrekt datieren und korrekt zitieren.

Aus Entscheidersicht ist daran ohnehin weniger die Technik interessant als der Meldeweg. Alle drei Fehlertypen sind innerhalb von Stunden erkennbar, wenn jemand danach sucht. Vereinbare deshalb vor dem Go-Live drei Dinge: wer in den ersten sieben Tagen täglich prüft, welche Signale gemeldet werden und an wen sie gehen. Ohne benannte Person passiert das, was in dokumentierten Schadensfällen regelmäßig passiert: Der Fehler existiert seit Tag eins, entdeckt wird er im Monatsreport.

Vorab: Nichts in diesem Abschnitt ist eine Entdeckung. Es steht in Googles Dokumentation, teils seit Jahren. Der Unterschied zu den meisten Checklisten liegt darin, dass hier auch steht, wo es steht. Wenn deine Agentur einen dieser Punkte streicht, kann sie das begründen, aber sie streicht gegen die Herstellerdokumentation.

Vollständiges URL-Mapping. Jede alte Adresse mit Bestand bekommt genau ein Ziel. Google zieht die Umzugs-Dokumentation ausdrücklich auch für Änderungen der URL-Struktur unter gleicher Domain heran, das Beispiel dort lautet example.com/page.php?id=1 nach example.com/widget.

301 oder 308, nicht 302. Siehe oben: Nur die permanenten Codes wirken als Kanonisierungssignal.

Keine Weiterleitungsketten. „Googlebot can follow up to 10 hops in a 'chain' of multiple redirects." Zehn Sprünge sind die technische Obergrenze, kein Zielwert. Ketten kosten Crawl-Budget und brechen bei jeder späteren Änderung.

Self-referencing Canonical. Wörtlich: „Each new URL should have a self-referencing rel='canonical' link tag." Jede neue Adresse zeigt kanonisch auf sich selbst.

hreflang aktualisieren. Bei mehrsprachigen Auftritten gilt: „be sure to update the annotations to use the new URLs". Veraltete Sprachverweise zeigen auf Adressen, die es nicht mehr gibt.

Sitemap-Cutover. Erst die neue Sitemap einreichen, dann die alte entfernen: „At this point you can remove your old sitemap, since Google will use the new sitemap going forward".

Adressänderung in der Search Console, aber nur beim Domainwechsel. Das Werkzeug gehört ausschließlich in den Fall, dass Inhalte von einer Domain auf eine andere umziehen. Alles andere schließt Google ausdrücklich aus: nicht beim Wechsel von HTTP auf HTTPS, nicht zwischen www und ohne www innerhalb derselben Domain, nicht beim reinen Umbau der URL-Struktur unter gleicher Domain und nicht beim Wechsel des Hosters. Dort sind Weiterleitungen und Canonicals das Mittel. Wenn dein Relaunch die Domain behält, ist dieser Punkt für dich schlicht nicht einschlägig, und ein Angebot, das ihn trotzdem als eigene Leistung führt, hat die Vorlage nicht gelesen.

Zur Frist, die regelmäßig für Verwirrung sorgt: Die Search-Console-Hilfe schreibt „Maintain the redirects for at least 180 days — longer if you still see any traffic to them from Google Search", die Umzugs-Dokumentation dagegen „Keep the redirects for as long as possible, generally at least 1 year". Das ist kein Widerspruch, sondern die Differenz zweier Untergrenzen: 180 Tage ist die Frist, an die das Werkzeug zur Adressänderung sein Signal knüpft, ein Jahr die allgemein empfohlene Lebensdauer der Weiterleitung selbst. Was nach Ablauf passiert, schreibt die Hilfe deutlich: „After the 180 day period, Google does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site, if still present and crawlable." Praktisch heißt das: Weiterleitungen bleiben bestehen, solange sie noch Aufrufe aus der Suche bekommen, und im Zweifel darüber hinaus.

Ein Wort zur Reichweite dieser Liste: Sie ist das Minimum, nicht das Programm. Interne Verlinkung, Navigationstiefe, strukturierte Daten und die Frage, welche Seiten überhaupt mitziehen sollen, kommen dazu. Das sind aber Gestaltungsfragen mit Ermessensspielraum. Die Punkte oben sind es nicht. Manchmal verschwinden Redirect-Konzept, Canonical-Logik und Sitemap-Umstellung in einer Sammelposition „SEO-Betreuung". Dann frage nach: Diese drei Punkte gehören einzeln ins Angebot, jeder mit eigenem Termin. Wie wir eine B2B-Website technisch aufsetzen und was davon zum Standard gehört, steht auf der Leistungsseite.

Was von dieser Strecke in ein Angebot gehört und in welcher Reihenfolge sie abgearbeitet wird, steht auf unserer Seite zum Website-Relaunch, inklusive Preisrahmen.

Hier ist eine Klarstellung fällig, weil in Relaunch-Angeboten Zahlen auftauchen, die es nicht gibt. Die gültigen Schwellen der Core Web Vitals lauten: LCP höchstens 2,5 Sekunden, INP höchstens 200 Millisekunden, CLS höchstens 0,1. Gemessen wird am 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop.

Nicht gültig sind die Werte, die als verschärfte Schwellen für 2025 und 2026 kursieren: LCP unter 2,0 Sekunden, CLS unter 0,08, FID unter 80 Millisekunden. Diese Zahlen stehen in keiner Google-Quelle. Der dritte Wert entlarvt sich selbst: FID ist seit dem 12. März 2024 kein Core Web Vital mehr, INP hat die Metrik an diesem Tag ersetzt. Wer dir heute eine FID-Zielmarke ins Angebot schreibt, arbeitet mit einer Kennzahl, die es in dieser Rolle seit über zwei Jahren nicht mehr gibt.

Zur Einordnung des Gewichts zitiere ich zwei Sätze aus derselben Google-Dokumentation zur Page Experience. Der eine: „Core Web Vitals are used by our ranking systems." Der andere: „There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience." Beide stimmen. Gute Werte sind notwendige Hygiene und kein Hebel, der verlorene Sichtbarkeit zurückholt. Wenn ein Relaunch-Angebot die Erholung nach dem Umzug vor allem über Performance-Optimierung begründet, fehlt die Redirect-Seite der Rechnung.

Trotzdem gehören die drei Werte in die Abnahme, und zwar aus einem anderen Grund als dem Ranking: Sie sind der einzige objektive Qualitätsmaßstab für die Umsetzung, den du ohne Fachwissen prüfen kannst. Miss sie an echten Nutzerdaten und nicht im Labortest auf dem Entwicklerrechner, und miss sie auf Mobilgeräten. Welche Technik dahintersteht, entscheidet mit: Ein serverseitig gerendertes Frontend auf Next.js, das seine Inhalte aus einem headless CMS wie Sanity bezieht, erreicht diese Werte nach unserer Erfahrung im Normalfall ohne Nachoptimierung, ein schwer beladenes Baukastensystem selten. Das ist kein Argument gegen Baukästen, sondern eines für ehrliche Zielwerte im Lastenheft.

Bleibt die Frage, was die Erholung in die Länge zieht. SALT beschreibt die Fälle, die über ein Jahr brauchen, und benennt drei Muster, wörtlich: „a combination of domain authority gaps between old and new, significant content restructuring at migration time, or technical issues that were not identified and resolved promptly." Übersetzt in Entscheidungen, die auf deinem Tisch liegen:

Der Domainwechsel selbst. Wenn die neue Domain wenig eigene Geschichte hat, überträgt der Umzug Signale auf ein Ziel ohne Bestand. Prüfe deshalb ernsthaft, ob der Wechsel der Domain wirklich sein muss. Ein Relaunch unter gleicher Domain fällt gar nicht erst in diese Kategorie.

Umbau und Umzug gleichzeitig. „Significant content restructuring at migration time" ist der Punkt, an dem sich die meisten Projekte selbst im Weg stehen: neue Domain, neue Struktur, neue Texte, neues System, alles in einer Nacht. Danach ist nicht mehr feststellbar, welche Änderung welchen Effekt hatte. Trenne die Schritte: erst aussortieren und zusammenführen, dann umziehen, dann inhaltlich ausbauen.

Späte Fehlererkennung. „Technical issues that were not identified and resolved promptly": Nicht der Fehler kostet, sondern die Zeit bis zu seiner Entdeckung. Deshalb gehören Statuscode-Prüfung, Index-Abdeckung und Server-Logs in die erste Woche nach Go-Live, mit benannter Zuständigkeit.

Der Scope, der zu groß ist. Wenn im selben Projekt eine Website, ein Kundenportal und eine Anwendung entstehen sollen, wird der Umzug zum Nebenschauplatz. Wo die Grenze verläuft, habe ich in Website, Webapp oder Portal sortiert. Für die zeitliche Seite ist Wie du dein Website-Projekt realistisch timst die passende Ergänzung, für die Umsetzung in klar geschnittenen Etappen Vom Pitch zum Go-live in 90 Tagen.

Ein Hinweis zur Ehrlichkeit: Diese vier Punkte sind aus SALTs Beschreibung abgeleitet, nicht statistisch nachgewiesen. Die Auswertung selbst erhebt keinen Kausalanspruch. Die Punkte decken sich mit dem, was ich in Projekten sehe, mehr behaupte ich nicht.

Du musst kein SEO werden, um ein Relaunch-Angebot zu bewerten. Vier Forderungen reichen, und jede hat einen Beleg hinter sich.

Erstens: eine Zeitachse mit zwei Kurven. Reindexierung und Traffic-Erholung getrennt, mit Zielwerten je Monat. Wer beides in eine Kurve legt, verkauft dir Googles „a few weeks" als Traffic-Zusage.

Zweitens: benannte Verantwortung für URL-Mapping, Statuscodes und Sitemap-Umstellung. Mit Termin vor dem Go-Live, nicht danach. Was dazugehört, steht oben, und es steht in Googles Dokumentation.

Drittens: ein Kontrollfenster in den ersten sieben Tagen. Statuscodes, Index-Abdeckung, Logs, feste Zuständigkeit. Der Kostentreiber ist die späte Entdeckung, nicht der Fehler.

Viertens: Skepsis gegenüber Garantien. Ein Angebot, das vertraglich zusichert, es gebe keinerlei Rankingverlust, widerspricht der Herstellerdokumentation. Google schreibt „Expect temporary fluctuation in site ranking during the move". Wer das Gegenteil garantiert, hat die Dokumentation entweder nicht gelesen oder plant, das Versprechen später wegzuerklären.

Und danach: Ein Relaunch ist kein Abschlussdatum, sondern der Anfang einer Betriebsphase. Warum das so ist und was das kostet, steht in Warum eine Website nie fertig ist. Für die Frage nach dem Budget eines Neubaus ist Was kostet eine Unternehmenswebsite 2026 der richtige Einstieg, für die Systemfrage die CMS-Beratung.

Wenn du vor einem Relaunch stehst und wissen willst, wie der Umzug in deinem Fall aussieht: Wir gehen dein URL-Inventar, die Redirect-Logik und den Zeitplan in einem Gespräch durch, und du bekommst danach eine Einschätzung, wo dein Projekt im Erwartungskorridor liegt. Termin direkt buchen oder die Leistung vorher auf der Seite zum Website-Relaunch nachlesen.