Wichtige Erkenntnisse:
Eine SEO-Checkliste für Website-Relaunches existiert, um die Link-Equity zu schützen, die Sie bereits aufgebaut haben. Eine brandneue Website umgeht dieses Problem vollständig, weil es noch nichts zu verlieren gibt.
Fehlerhafte Redirect-Maps, On-Page-Elemente, die bei der Migration zu neuen Templates nicht überdauert haben, und ein Staging-noindex-Tag, den jemand vergessen hat – diese drei Faktoren verursachen die meisten Relaunch-Katastrophen.
Core Web Vitals (LCP unter 2,5s, INP unter 200ms, CLS unter 0,1) funktionieren als Hard Pass/Fail-Linie in Googles Page Experience Signals.
Die ersten 72 Stunden nach dem Go-Live entscheiden über die meisten Folgen. Redirect-Lücken und Index-Coverage-Fehler benötigen Same-Day-Fixes, nicht einen Platz auf dem Sprint-Board der nächsten Woche.
Basieren Sie alles, bevor Sie Code ändern. URLs, Titel, H1s, Schema, Backlinks, CWV-Felddaten – Sie können eine Zahl nicht verteidigen, die Sie nie aufgeschrieben haben.
Kein Relaunch ist wirklich ein Neuanfang. Es ist eine Übergabe, bei der jahrelange Ranking-Signale von einer Codebasis zu einer anderen verschoben werden, mit praktisch null Raum für Fehler. Die meisten SEO-Manager kennen die Theorie beim Eintritt in einen Redesign bereits in- und auswendig. Was diese Projekte wirklich zum Scheitern bringt, ist eine kleine Sache, die niemand rechtzeitig gekennzeichnet hat: ein Kategorie-URL-Muster, das es nie in die Map geschafft hat, eine robots.txt-Zeile direkt aus dem Staging oder eine INP-Regression in einer neuen Hero-Komponente, die das Dev-Team schwört, ist „schnell genug". Dies ist für diejenigen, die am dritten Tag für den Verkehrsrückgang haftbar sind. Betrachten Sie es auch als Double für eine Website-Redesign-SEO-Checkliste, da die Preflight-Arbeit identisch ist.
Warum töten Relaunches Rankings?
Ein Relaunch schlägt fehl, wenn die neue Website nicht sauber dort weitermachen kann, wo die alte aufgehört hat. Google muss Tausende von Seiten neu crawlen, jedem Redirect folgen, Templates neu rendern und die Relevanz von Grund auf neu bewerten. Verpassen Sie einen Link in dieser Kette und Rankings fallen, manchmal innerhalb von Stunden.
Drei Symptome treten in der ersten Woche fast immer auf. URLs, die verschwinden und 404-Fehler werfen. Redirect-Ketten, die PageRank über drei oder vier unnötige Hops verlieren. Index-Coverage-Fehler stapeln sich in der Search Console, während versucht wird, eine Website neu zu crawlen, die nicht mehr so aussieht wie sie sich erinnert. Ein Erststart trifft keinen davon; es gibt einfach nichts Aufgebautes zu verlieren. Ein Relaunch zieht diese Geschichte für die Fahrt mit, und es schneidet auf beiden Seiten: Ihr größter Vorteil und Ihre größte Exposition gleichzeitig.
Core Web Vitals: ein Schwellwert, kein Tiebreaker
Google faltet Core Web Vitals in seine Page Experience Signals ein, und laut Google Search Central bedeutet „gut" derzeit LCP unter 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1, alle beim 75. Perzentil. Die web.dev CWV-Richtlinien sind, wo diese Pass-Linie tatsächlich gezogen wird. Fallen Sie bei einem Template unter „gut", das früher einwandfrei abgeschnitten hat, und der Visibility-Hit landet in der Regel, bevor Sie überhaupt herausgefunden haben, was kaputt ist.
Das 72-Stunden-Fenster
Sites, die Redirect-Lücken und Coverage-Fehler innerhalb von drei Tagen nach dem Launch schließen, erholen sich deutlich schneller als Sites, die dieselben Fehler als zweiwöchiges Backlog-Element behandeln. Crawler treffen am härtesten direkt nach einer Änderung. Erfassen Sie das Problem in diesem Fenster und es macht es nie in den Index hinein.
Phase 1: Pre-Relaunch-Basis-Audit
Sie können eine Zahl nicht schützen, die Sie nie gemessen haben. Zwei oder drei Wochen voraus crawlen Sie die Live-Site vollständig, Screaming Frog, Sitebulb, was Ihr Team bereits vertraut, und ziehen jede indexierbare URL, jeden Statuscode und Canonical heraus. Exportieren Sie es irgendwo Dauerhaftes. Versionieren Sie es.
Von dort aus extrahieren Sie Ihre Top 20% der Seiten nach organischem Traffic und Backlinks aus der Search Console und Analytics. Diese URLs dürfen nicht kaputt gehen, vollständig. Notieren Sie die ranking-relevanten Elemente für jede: Titel, H1, Meta-Beschreibung, Body-Copy, Schema, Alt-Text, interne Links, und lassen Sie Raum, um jedes Element gegen die neue URL nach dem Launch abzuhaken. Machen Sie dasselbe für Core Web Vitals mit aktuellen Felddaten als Ihrer Zahl zum Schlagen. Eine Produktseite, die heute mit 2,1 Sekunden LCP lädt, muss auf der neuen Website diesen Schwellenwert oder besser erfüllen, nicht nur in die Nähe kommen.
Phase 2: URL-Architektur und die 301-Redirect-Map
Jede URL, die sich bewegt, benötigt einen 301 auf ihren Ersatz, bevor der Dev-Build sperrt, nicht zusammengeflickt die Nacht vor dem Launch. Googles eigene Dokumentation zu Website-Umzügen lässt hier nicht viel Spielraum: permanente Redirects, ein Hop, mindestens ein Jahr lang aktiv.
Teams machen die offensichtlichen Top-Level-Seiten normalerweise fein und verlieren den Long Tail vollständig. Abdeckung:
Kategorie- und Unterkategorie-URLs
Blog-Paginierung in beiden Varianten, ?page=2-Abfragezeichenfolgen und /page/2/-Pfadsegmente
Facettierte Filter und Parameter-URLs, die leise echten Such-Traffic zogen
Alte Campaign-Landingpages, auch solche ohne interne Links mehr
Legacy-Bild- und PDF-URLs, die im Laufe der Jahre Backlinks aufsammelten
Führen Sie die fertige Map durch einen Crawler auf Staging. Ketten, Schleifen, jede alte URL landing auf einem Soft 404 oder dumped auf die Homepage – fangen Sie das jetzt. Alles auf die Homepage zu senden mag wie ein schneller Fix aussehen, aber es ist genau die Art von Abkürzung, vor der Google warnt, weil sie Equity torches statt zu übertragen.
Sichern Sie die alte Codebasis und Datenbank, bevor Sie Production anfassen. Wenn etwas in den ersten 72 Stunden zusammenbricht und noch niemand genau sagen kann, warum, verwandelt ein Rollback-Plan eine schlechte Woche in etwas Überlebbares statt eines verlorenen Quartals.
Phase 3: On-Page-SEO-Erhaltung auf Staging
„Sauberer, moderner, weniger Unordnung" ist im Grunde jeder Redesign-Brief, der je geschrieben wurde. Was das in der Praxis stillschweigend bedeutet: 800 Wörter Ranking-Content schrumpfen auf 300, weil das neue Template nur einen Hero und drei Feature-Blöcke passt. Fangen Sie das ab, bevor es ausgerollt wird.
Jedes ranking-relevante Element muss intakt umziehen, Titel, H1s, Meta-Beschreibungen, Body-Copy, Schema, Alt-Text. Wenn das Design wirklich nicht halten kann, was da ist, das ist ein Gespräch, das vor Beginn des Builds stattfinden muss, nicht eine Überraschung nach dem Launch. Bestätigen Sie, dass Staging ordnungsgemäß mit noindex und robots.txt blockiert ist, dann stellen Sie einen Erinnerung für den Go-Live-Tag speziell, um zu überprüfen, dass dieser Block abging. Ein Staging-noindex, der versehentlich in Production hinterlassen wurde, könnte der einzige häufigste Weg sein, auf dem ein Relaunch zu einer Katastrophe wird, und es ist unsichtbar, bis der Traffic-Graph eine Klippe hinunterfällt.
Überprüfen Sie kanonische Tags, hreflang wo mehrsprachig anwendbar, und interne Link-Struktur in den neuen Templates gegen Ihre Baseline. Führen Sie alles durch Googles Rich Results Test und klären Sie auch die Warnungen, nicht nur was es als Hard Errors kennzeichnet.
Phase 4: Technische SEO und Core Web Vitals auf Staging
Testen Sie Lighthouse und PageSpeed Insights gegen jedes Schlüssel-Template, nicht nur die Homepage, und vergleichen Sie jedes gegen Ihre Pre-Launch-Nummern.
Metrik | „Gut"-Schwellenwert | Wo man misst |
LCP | Unter 2,5s | Felddaten (GSC) + Lab (Lighthouse) |
INP | Unter 200ms | Felddaten (GSC) |
CLS | Unter 0,1 | Felddaten + Lab |
TTFB* | Unter 800ms | Lab-Tools, Server-Logs |
*Ein kurzer Vorbehalt: TTFB ist eine solide Diagnosezahl, aber Google zählt sie nicht zu seinen drei offiziellen Core Web Vitals. Sie verdient einen Platz hier als frühes Warnzeichen, nicht als offizieller Ranking-Schwellenwert.
Überprüfen Sie das Crawl-Budget-Risiko auf dem neuen Stack speziell. Facettierte Filter fehlende noindex, doppelte Parameter-Seiten aus einer neuen Tracking-Schicht, Content-Hubs über-getaggt während der Migration, sortieren Sie diese vor dem Launch statt nachher. Stellen Sie sicher, dass die XML-Sitemap nur die neue URL-Menge enthält. Keine alten URLs. Keine noindexed-Seiten, die durchgerutscht sind. Keine Staging-Domains.
WCAG 2.2 AA ist die Barrierefreiheitsleiste, wenn das Teil des Redesign-Umfangs ist. Es wird Rankings nicht direkt verschieben, aber sauberes semantisches HTML kommt normalerweise damit, und Crawler bemerken das so oder so.
Go-Live-Tag-Checkliste
Go-Live ist nicht ein zweistündiges Meeting, egal was der Kalender sagt. Blockieren Sie den ganzen Tag mit SEO und Dev auf Standby, und einigen Sie sich auf Rollback-Trigger, eine Homepage 404, ein Site-Wide-noindex oder eine kaputte Sitemap bedeutet sofort zurückrollen und später debuggen.
Bereitstellen, das Staging-noindex oder „Suchmaschinen nicht empfohlen"-Setting ausschalten, dann mit einer URL-Inspektion-Abruf bestätigen, dass es wirklich weg ist.
Schalten Sie die vollständige Redirect-Map um und spot-checken Sie 10% davon live mit einem Bulk-Redirect-Checker.
Reichen Sie die neue Sitemap in GSC ein und fordern Sie Indexierung auf den Top 20 URLs direkt an.
Überprüfen Sie, dass robots.txt wirklich die Production-Datei ist, nicht eine verirrte Staging-Kopie.
Schreiben Sie den exakten Go-Live-Zeitstempel irgendwo auf. Sie werden es in einer Woche brauchen, um Crawl, Coverage und Performance-Shifts auszurichten.
Veröffentlichen Sie die On-Call-Rota, damit klar ist, wer was besitzt, wenn etwas falsch zu laufen beginnt.
Post-Launch-Überwachung: Tage 1 bis 30
Go-Live ist der Start, nicht die Ziellinie.
Tage 1 bis 7. Überprüfen Sie die Search Console täglich. Beobachten Sie Coverage auf 404-Spitzen oder „Entdeckt, nicht indexiert"-Surges, und Crawl Stats auf alles Seltsame. Reparieren Sie Redirect-Lücken in Stunden hier, nicht Tagen. Jede Top-20%-URL, die anfängt zu 404en, ist P0, keine Ausnahmen. Behalten Sie auch AI-Answer-Engines im Blick – ChatGPT, Googles AI Overviews – da sie viel von denselben gecrawlten Inhalten pullen, die Search Console meldet, und ein Relaunch kann Sie leise AI-Zitations-Sichtbarkeit kosten, in dem gleichen Moment es kostet Sie klassische Rankings.
Tage 7 bis 14. Vergleichen Sie CWV-Felddaten gegen Baseline. Es läuft auf einem 28-Tage-Rolling-Fenster, daher sind frühe Lesungen verrauscht, aber eine klare Regression auf einem Key-Template sollte nicht warten; senden Sie es jetzt an Engineering. Unterbrechen Sie den Performance-Report nach Seitengruppe statt nur die Site-Summe zu betrachten. Eine Kategorieseite tankt, während die Homepage flach bleibt, bedeutet das Problem lebt in diesem Template speziell, und benötigt einen Fix mit derselben Scope.
Tage 14 bis 30. Verfolgen Sie Ihre Top 50 Keywords mit was immer Rank-Tracker Ihr Team bereits lädt. Etwas Dip ist normal, während Google die neue URLs neu crawlt und neu bewertet. Ein steiler oder anhaltender ist anders; das ist Ihr Signal, um die Redirect-Map, die On-Page-Baseline und Template-Level-CWV zusammen als eine Untersuchung zu graben. Wenn es danach noch steckt, ist manchmal der schnellste Weg, externe Augen hereinzubringen, statt einen anderen Sprint darauf zu verbrennen, unser IT-Beratung vs. In-House-IT-Leitfaden behandelt, wie man diesen Anruf denkt.
Führen Sie um Tag 21 einen vollständigen Crawl aus. Suchen Sie nach Waisenseiten, die das neue CMS auf eigene Faust erstellt hat, interne Links zeigen noch auf die alte URL-Struktur in Body-Copy begraben, und jedes Duplicate-Content-Muster, das aus Tag-Seiten oder gefilterten Auflistungen niemand einführen wollte.
Planen Sie einen Relaunch und möchten eine zweite Meinung zur Redirect-Map, bevor Sie den Schalter umschalten? Buchen Sie einen Discovery-Call, und wir gehen die Baseline-Audit mit Ihnen durch und kennzeichnen, was am ehesten Rankings in dieser ersten Woche kostet.
Verwandter Service: Technical SEO Consulting
Häufig gestellte Fragen
Wie lange dauert es, um Rankings nach einem Website-Relaunch wiederherzustellen?
Mid-Competition-Sites, die Redirect-Lücken und Coverage-Fehler innerhalb von 72 Stunden handhaben, stabilisieren sich normalerweise innerhalb von vier bis acht Wochen, abhängig davon, wie sehr sich die URL-Struktur geändert hat und wie viel Autorität die Website zu Beginn hatte. Eine große Domain mit Millionen von URLs kann ein volles Quartal brauchen, um sich vollständig zu beruhigen. Verpassen Sie das 72-Stunden-Fenster und die Wiederherstellung dauert normalerweise länger, einfach weil Crawler den Schaden bereits gemeldet haben.
Sollte ich eine neue Sitemap starten oder die vorhandene aktualisieren?
Behalten Sie die vorhandene Sitemap-URL, wo möglich, so dass Google seinen Crawl-Bezugspunkt nicht verliert. Tauschen Sie nur den neuen URL-Satz um, keine alten URLs, keine noindexed-Seiten, keine Staging-Pfade, und reichen Sie erneut durch GSC ein. Die Sitemap-URL selbst zu ändern, signalisiert risiken einen vollständigen Website-Umzug, wenn wirklich nur die interne Struktur sich geändert hat.
Wie viele Redirect-Hops sind zu viele?
Eine. Ein 301 geht direkt von alter URL zu endgültiges Ziel, nichts dazwischen.
Muss ich die alten Redirects für immer behalten?
Google sagt mindestens ein Jahr, länger, wenn die alten URLs noch Traffic oder Backlinks ziehen. Ziehen Sie sie zu früh heraus und jeder externe Link, der noch auf dort zeigt, bricht, was leise die Equity-Übertragung undoes, die Sie zu schützen bemüht waren.
Ist ein Staging-noindex wirklich so gefährlich?
Ja. Ein noindex-Tag oder X-Robots-Tag-Header, der in Production läuft, kann die gesamte Domain innerhalb von Tagen deindexieren. Es ist möglicherweise der single schlechteste Relaunch-Fehler, und auch einer der einfachsten zu fangen, führen Sie einen Curl-Request gegen die Live-URL direkt nach der Bereitstellung aus, dann 24 Stunden später nur um sicherzustellen.
Wo sollte ich externe Hilfe bei einem Relaunch bekommen?
Ein zweites Augenpaar auf der Redirect-Map und Baseline-Audit macht normalerweise die Kosten vorbei 10.000 URLs zahlen. Wenn ein Team bereits gestreckt ist, neigt ein Scoped-technischer Review vor dem Go-Live dazu, Dinge zu fangen, die interne Teams einfach vermissen, weil sie für sechs Wochen geradeaus auf derselben Tabelle staren.