Website-Relaunch ohne Ranking-Verlust: die technische Checkliste
Eine neue Website ist kein automatischer SEO-Gewinn. Wer die technischen Grundregeln vor dem Launch nicht beachtet, riskiert, hart erarbeitete Rankings über Monate zu verlieren – oft ohne es sofort zu bemerken.
Point: Der häufigste Grund für Ranking-Einbrüche nach einem Relaunch sind fehlende 301-Weiterleitungen – nicht das neue Design oder der neue Hoster.
Evidence: Ändern sich URLs ohne Weiterleitungen, verliert Google alle bisher aufgebauten Verlinkungssignale. Die neue URL wird wie eine komplett neue Seite behandelt und muss von Grund auf neu bewertet werden.
Impact: Monate bis Jahre an SEO-Arbeit können in wenigen Wochen verloren gehen. Mit einem systematischen Redirect-Plan und den richtigen Vorbereitungsschritten lässt sich das in den meisten Fällen vermeiden.
Kurz zusammengefasst
- URL-Änderungen ohne 301-Weiterleitungen sind die häufigste Ursache für Ranking-Einbrüche nach einem Relaunch.
- Eine vollständige URL-Mapping-Tabelle muss vor dem Launch fertig sein – nicht danach.
- Das Staging-System muss mit noindex-Tag und robots.txt für Google gesperrt sein.
- Core Web Vitals und Ladezeiten sollten vor dem Launch geprüft werden, nicht erst im Nachhinein.
- Google Search Console mindestens 6–8 Wochen nach dem Launch täglich beobachten.
Warum Rankings nach einem Relaunch einbrechen
Ein Relaunch hat für viele Unternehmen eine offensichtliche Priorität: Die neue Website soll besser aussehen, mobil funktionieren und den eigenen Anspruch widerspiegeln. SEO ist dabei oft kein eigenständiger Punkt im Briefing – und das rächt sich.
Typischerweise sieht das so aus: Ein Handwerksbetrieb mit zwölf Mitarbeitenden beauftragt eine neue Website. Der bisherige Anbieter arbeitete mit einer anderen URL-Struktur – aus /leistungen/badezimmer-renovierung wird plötzlich /bad. Drei Monate nach dem Launch sind die meisten Positionen in Google verschwunden. Die Webdesign-Agentur wusste nicht, dass diese Seiten ranken – im Briefing stand nur „neue Website".
Google behandelt eine URL wie eine eindeutige Adresse. Wenn sich diese Adresse ändert, betrachtet die Suchmaschine die neue URL wie eine komplett neue Seite, die zunächst keine Vertrauenssignale hat. Backlinks, die auf die alte URL zeigen, sind wirkungslos. Klickdaten, die Google über Jahre gesammelt hat, werden nicht auf die neue URL übertragen.
Das Problem betrifft nicht nur kleine Handwerksbetriebe. In solchen Situationen tauchen häufig auch Unternehmensseiten mit dutzenden Leistungsseiten auf, bei denen jede Seite einzeln hätte weitergeleitet werden müssen. Ohne Redirect-Plan wurde aus einer gut positionierten Seite eine Sammlung von 404-Fehlern.
Klassischer Fehler im Projektablauf
SEO-Anforderungen stehen selten im Webdesign-Briefing. Wer nur „neue Website mit besserem Design" beauftragt, erhält genau das – und trägt die SEO-Verantwortung selbst. Diesen Punkt ausdrücklich mit dem Dienstleister klären und schriftlich festhalten.
Phase 1 (4–8 Wochen vor Launch): URL-Mapping und Redirect-Plan
Der Grundstein wird lange vor dem Launch gelegt. Bevor auch nur eine Zeile des neuen Designs steht, sollte ein vollständiges Bild der bestehenden URL-Struktur vorliegen.
Schritt 1: URL-Liste erstellen. Exportieren Sie aus der Google Search Console (Bericht „Leistung → Seiten") alle URLs, die organischen Traffic erhalten. Ergänzen Sie das mit einem Crawl der aktuellen Website. Tools wie Screaming Frog (kostenlose Version bis 500 URLs) oder das Chrome-Plugin Ahrefs SEO Toolbar liefern die vollständige URL-Liste inklusive aller indexierten Seiten.
Schritt 2: Mapping alt → neu. Für jede bestehende URL legen Sie fest, wohin sie nach dem Relaunch führen soll. Bleibt die URL gleich, brauchen Sie nichts zu tun. Ändert sie sich, richten Sie eine 301-Weiterleitung ein. Gibt es keine sinnvolle Entsprechung, leiten Sie auf die thematisch nächste Seite oder die Startseite weiter – eine 301-Weiterleitung auf die Startseite ist immer noch deutlich besser als eine 404-Fehlermeldung.
| Situation | Maßnahme | Priorität |
|---|---|---|
| URL bleibt identisch | Kein Redirect nötig | – |
| URL ändert sich, Seite bleibt | 301-Redirect alt → neu | Kritisch |
| Seite entfällt, ähnliche Seite existiert | 301-Redirect auf thematisch nächste Seite | Hoch |
| Seite entfällt komplett | 301-Redirect auf Startseite | Mittel |
Wichtig: Redirect-Chains vermeiden. Eine Weiterleitungskette A → B → C kostet Crawl-Budget und schwächt die weitergegebenen Signale. Richten Sie immer direkte Weiterleitungen von der alten URL zur finalen Ziel-URL ein – ohne Zwischenstationen.
Phase 2 (2–4 Wochen vor Launch): Staging richtig absichern
Die neue Website wird in aller Regel auf einer Staging-Umgebung entwickelt und getestet – einer separaten Domain oder Subdomain, auf der der Auftraggeber die neue Seite abnimmt, bevor sie live geht.
Das Problem: Google crawlt das gesamte Web, auch Staging-Systeme – sofern diese öffentlich erreichbar sind. Ist das Staging nicht gesperrt, kann Google beide Versionen gleichzeitig indexieren und als Duplicate Content behandeln, noch bevor die neue Seite überhaupt live ist.
Staging nicht gesperrt
- ❌ Google indexiert beide Versionen
- ❌ Duplicate-Content-Probleme vor Launch
- ❌ Ranking-Signale verteilen sich auf zwei URLs
- ❌ Interne Inhalte ggf. öffentlich sichtbar
Staging korrekt gesperrt
- ✅ noindex-Meta-Tag in allen Staging-Seiten
- ✅ robots.txt mit
Disallow: / - ✅ Optional: HTTP-Passwortschutz (Basic Auth)
- ✅ Google crawlt nur die Produktionsversion
Prüfen Sie außerdem, ob Canonical-Tags korrekt gesetzt sind. Auf dem Staging-System sollten Canonicals entweder auf die Staging-URL selbst zeigen oder gar nicht gesetzt sein – niemals auf die Produktions-URL, bevor die neue Seite tatsächlich live ist.
Erstellen Sie außerdem bereits auf dem Staging-System die finale XML-Sitemap und prüfen Sie die robots.txt der Produktionsumgebung. Diese Dateien werden beim Launch oft übersehen, weil sie „technisch" sind und nicht im Design-Review auftauchen.
Phase 3: Core Web Vitals und On-Page-SEO vor dem Launch prüfen
Google nutzt die Core Web Vitals – Ladegeschwindigkeit, Interaktivität und visuelle Stabilität – als Rankingfaktor. Ein neues Design, das langsamer lädt als das alte, kann trotz besserer Inhalte schlechter ranken.
Typische Probleme bei Relaunches: unkomprimierte Bilder, zu viele eingebundene Schriften, JavaScript, das den Seitenaufbau blockiert, oder ein neues CMS, das mehr Ressourcen lädt als nötig. All das lässt sich auf dem Staging-System mit Google PageSpeed Insights oder Lighthouse messen, bevor es live geht. Wer erst nach dem Launch optimiert, verliert unnötig Zeit.
| Messwert | Zielwert (gut) | Häufige Ursache für schlechten Wert |
|---|---|---|
| LCP (Largest Contentful Paint) | unter 2,5 s | Großes Hero-Bild ohne Preload, langsamer Hoster |
| CLS (Cumulative Layout Shift) | unter 0,1 | Bilder ohne feste Dimensionen, nachladeende Schriften |
| INP (Interaction to Next Paint) | unter 200 ms | Schweres JavaScript im Main Thread, Chat-Widgets, Analytics |
Migrieren Sie außerdem alle bestehenden Title-Tags und Meta-Descriptions in das neue System. Häufig passiert es, dass ein neues CMS leere oder automatisch generierte Titles ausliefert – ein einfach vermeidbarer Rückschritt.
Mehr zur Rolle von Struktur in nachhaltiger SEO-Arbeit erklärt der Artikel SEO: Warum Struktur wichtiger ist als Keywords.
Phase 4 (Launch-Tag und die ersten zwei Wochen)
Am Launch-Tag ist Tempo gefragt – und Ordnung. Eine feste Checkliste verhindert, dass in der Hektik wichtige Punkte vergessen werden:
robots.txt auf Produktion prüfen
Sicherstellen, dass die Produktionsdomain nicht mehr geblockt ist – das passiert, wenn die robots.txt des Staging-Systems versehentlich in die Produktion übernommen wird.
XML-Sitemap in Google Search Console einreichen
Unter „Sitemaps" die neue sitemap.xml-URL eintragen. Das beschleunigt die erste Crawlung der neuen URLs erheblich.
Die wichtigsten Seiten mit dem URL-Inspektionstool prüfen
Jede wichtige URL in der Search Console inspizieren: Ist sie indexierbar? Stimmt der Canonical? Sind keine noindex-Tags übrig geblieben?
301-Weiterleitungen testen
Jede gemappte alte URL aufrufen und prüfen, ob sie korrekt auf die neue URL weiterleitet – und nicht auf eine Zwischenseite oder eine 404-Fehlerseite.
404-Monitoring einrichten
Google Search Console (Bericht „Seiten → Nicht gefunden (404)") täglich im Auge behalten. Neue 404-Fehler nach dem Launch sind ein klares Zeichen auf vergessene Redirects.
Wie lange dauert die Erholung – und was ist normal?
Selbst bei korrekter Umsetzung aller Maßnahmen sind kurzfristige Schwankungen nach einem Relaunch normal. Google muss die neue Seitenstruktur erst crawlen, neu bewerten und einordnen – das braucht Zeit.
Bei kleinen Websites mit unter 100 Seiten sind die wichtigsten Seiten typischerweise innerhalb von 2–4 Wochen neu indexiert. Rankings stabilisieren sich meist innerhalb von 6–12 Wochen auf oder nahe ihrem früheren Niveau – vorausgesetzt, Redirects, On-Page-Faktoren und Inhalte stimmen.
Was nicht normal ist: anhaltende Einbrüche über drei Monate hinaus. Das deutet in der Regel auf ein strukturelles Problem hin – fehlende Weiterleitungen, Canonical-Fehler oder Content, der auf der neuen Seite fehlt oder stark verändert wurde.
Hinweis zum Monitoring: Richten Sie in der Google Search Console regelmäßige Exports ein oder nutzen Sie ein SEO-Monitoring-Tool (Sistrix, Semrush, Ahrefs). So erkennen Sie Rückgänge frühzeitig und können reagieren, bevor Monate ungenutzt vergehen. Wer wie von KI-Suchsystemen gefunden wird, erklärt ergänzend der Artikel LLM SEO – wie Unternehmen von KI-Systemen gefunden werden.
Wie sich das in der Praxis lösen lässt
Die beschriebenen Probleme sind technisch lösbar – und mit der richtigen Vorbereitung weitgehend vermeidbar. Der Aufwand liegt im Vorfeld, nicht im Nachgang.
In der Praxis bedeutet das konkret drei Bausteine:
- SEO-Bestandsaufnahme vor Projektbeginn: Vollständige Analyse der bestehenden Rankings, URL-Struktur und Backlink-Situation. Dieser Schritt liefert die Grundlage für das URL-Mapping und zeigt, welche Seiten auf keinen Fall ohne Weiterleitung verschwinden dürfen.
- Technische SEO als Teil des Webdesign-Projekts: Redirect-Plan, Sitemap-Strategie, Canonical-Struktur, Core-Web-Vitals-Optimierung – idealerweise nicht als nachträglicher Check, sondern als integrierter Bestandteil des Projekts von Anfang an.
- Monitoring nach Launch: Systematische Beobachtung der Search-Console-Daten in den ersten acht Wochen, mit klaren Schwellenwerten, ab denen eingegriffen wird.
Ein häufig übersehener Aspekt beim Relaunch: Wenn im Zuge des Neustarts auch Analytics neu eingerichtet wird, sollte dieser Schritt DSGVO-konform erfolgen. Ein Relaunch ist die ideale Gelegenheit, ein sauberes Tracking-Setup aufzusetzen – statt eine fehlerhafte GA4-Konfiguration aus dem Vorgängerprojekt zu übernehmen. Wie das geht, erklärt der Artikel zum DSGVO-konformen Website-Tracking.
Wo die Grenzen liegen: Wenn eine Website seit Jahren kaum gepflegt wurde und inhaltlich schwach ist, liefert auch ein technisch perfekter Relaunch keine Ranking-Garantien. SEO-Defizite, die vor dem Relaunch bestanden, können 301-Weiterleitungen allein nicht ausgleichen.
Bei Förster Digital ist technische SEO fester Bestandteil jedes Webdesign-Projekts – URL-Mapping, Redirect-Plan und Search-Console-Einrichtung sind im Prozess enthalten, nicht optional. Die übergeordnete SEO-Strategie ist auf der Leistungsseite SEO beschrieben.
Häufige Fragen (FAQ)
Wie viele Rankings verliert man typischerweise nach einem Relaunch?
Das hängt vor allem davon ab, ob 301-Weiterleitungen korrekt eingerichtet sind. Ohne Weiterleitungen behandelt Google neue URLs wie komplett neue Seiten – alle bisher aufgebauten Signale müssen von null aufgebaut werden. Mit korrekt gesetzten 301-Redirects und unverändertem Content bleiben Rankings in der Regel weitgehend stabil, auch wenn es in den ersten 4–8 Wochen zu kleineren Schwankungen kommen kann.
Muss ich alle alten URLs weiterleiten, auch wenn es mehrere Hundert sind?
Ja, zumindest alle Seiten, die bei Google indexiert sind und organischen Traffic erhalten. Die vollständige URL-Liste können Sie aus Google Search Console (Bericht „Leistung") und aus einem Crawl-Tool wie Screaming Frog exportieren. URLs ohne nennenswerten Traffic können auf die thematisch nächste Seite weitergeleitet werden.
Wie lange dauert es, bis Google die neue Seite vollständig indexiert hat?
Das variiert stark nach Seitengröße und Crawl-Budget. Bei kleinen bis mittelgroßen Websites sind wichtige Seiten typischerweise innerhalb von 2–4 Wochen neu indexiert. Eine vollständige Stabilisierung der Rankings dauert oft 6–12 Wochen. Das Einreichen der XML-Sitemap in der Google Search Console beschleunigt den Prozess.
Kann ich den Relaunch auf einer Subdomain testen?
Ja, aber die Staging-Umgebung muss zwingend mit einem noindex-Meta-Tag und einer robots.txt-Disallow-Regel gesperrt sein. Andernfalls indexiert Google die Staging-Version und behandelt sie als Duplicate Content – was zu Ranking-Problemen noch vor dem eigentlichen Launch führen kann.
Was ist der häufigste Fehler, den KMU beim Website-Relaunch machen?
Das Vergessen von 301-Weiterleitungen auf die wichtigsten alten URLs – oft weil der neue Webdesigner die bestehende SEO-Struktur nicht kennt oder die Aufgabe schlicht nicht im Auftrag stand. Ebenso häufig: die Staging-Umgebung wird nicht gesperrt, sodass Google zwei Versionen der Website gleichzeitig crawlt.
Relaunch ohne SEO-Risiko geplant?
Bei Förster Digital ist technische SEO fester Bestandteil des Webdesign-Prozesses – kein Add-on, kein Nachklapp. Transparentes Festpreis-Angebot nach kostenlosem Erstgespräch.
Weiterlesen
SEO: Warum Struktur wichtiger ist als Keywords
Informationsarchitektur als SEO-Grundlage. Semantische HTML-Struktur, interne Verlinkung und Content-Hierarchie für nachhaltige Rankings ohne…
Zum ArtikelLLM SEO – wie Unternehmen von KI-Systemen gefunden werden
Strukturierte Daten-Optimierung für ChatGPT-, Gemini- und Perplexity-Citation. Schema.org + Semantic HTML für LLM-Retrieval und…
Zum Artikel
Über den Autor
Christian Förster
Ich entwickle Websites und automatisiere Geschäftsprozesse für kleine und mittelständische Unternehmen — mit Next.js, TypeScript und n8n. Was ich hier schreibe, stammt aus Projekten, die ich selbst umgesetzt habe, und aus eigenen Produkten wie den iOS-Apps Jobrechnung und Jobzeiten.
Veröffentlicht am