Wir sehen es zu oft: Der neue Auftritt geht live, das Team feiert, die Agentur schickt die Rechnung – und drei Wochen später fragt der Geschäftsführer, warum der Traffic um 60 Prozent eingebrochen ist. Rankings weg. Organische Anfragen weg. Monate an SEO-Arbeit vernichtet, weil die technische Migration nicht durchdacht war. Das ist kein Einzelfall, das ist ein Muster. Und es muss nicht sein – wenn ihr die richtige Reihenfolge kennt.
Warum Relaunches SEO-Risiken sind
Ein Website-Relaunch ist aus SEO-Sicht eine der risikoreichsten Maßnahmen überhaupt. Der Grund: Google bewertet nicht die neue Website – Google bewertet das, was es über Zeit über eure Domain gelernt hat. Signale akkumulieren sich: Backlinks zeigen auf spezifische URLs, interne Verlinkungsstrukturen kommunizieren thematische Relevanz, gecrawlte Inhalte bauen ein Verständnis eurer Seiten auf.
Wenn sich URLs ändern, Inhalte verschwinden oder technische Konfigurationen falsch gesetzt sind, verliert Google den Anschluss. Das zeigt sich typischerweise in:
- URL-Änderungen ohne Weiterleitungen: Backlinks auf die alten URLs laufen ins Leere, Link Equity verpufft
- Content-Verlust: Seiten die früher rankten existieren auf der neuen Site nicht mehr
- Technische Fehler beim Launch: noindex-Flags aus der Staging-Umgebung nicht entfernt, sitemap.xml nicht aktualisiert, robots.txt blockiert wichtige Verzeichnisse
- Strukturveränderungen: Was vorher hierarchisch sauber verlinkt war, ist jetzt nicht mehr erreichbar
Der gute Aspekt: All diese Fehler sind vermeidbar. Die Voraussetzung ist eine strukturierte Vorbereitung, die lange vor dem Launch beginnt.
Phase 1 – Vor dem Relaunch: Vorbereitung ist alles
Crawl der alten Site
Bevor eine einzige Zeile neuer Code in Produktion geht, crawlt ihr die bestehende Website vollständig. Tools wie Screaming Frog (kostenlose Version bis 500 URLs, Lizenz für größere Sites), Ahrefs Site Audit oder Sitebulb exportieren euch alle URLs mit Status-Codes, Metadaten, internen Links und weiteren Signalen.
Was ihr aus dem Crawl braucht:
- Vollständige Liste aller aktiven URLs (Status 200)
- Title Tags und Meta Descriptions aller Seiten
- Interne Verlinkungsstruktur
- Seitengewicht nach internen eingehenden Links (Indicator für Wichtigkeit)
Ergänzt das mit Daten aus der Google Search Console: welche URLs organischen Traffic generieren, für welche Keywords sie ranken, welche Seiten Impressionen haben. Diese Kombination zeigt euch, was schützenswert ist.
Top-Rankings dokumentieren
Exportiert aus der Search Console alle URLs mit signifikantem Traffic oder Rankings. Das sind eure wertvollsten Seiten – sie müssen auf der neuen Site erhalten bleiben oder mit sauberen 301-Weiterleitungen auf thematisch äquivalente Seiten zeigen.
Dokumentiert zu jeder Seite: die aktuelle URL, die wichtigsten Keywords, den durchschnittlichen Traffic pro Monat, und ob es eingehende Backlinks gibt (prüft in Ahrefs oder Google Search Console unter „Links").
URL-Mapping erstellen
Das URL-Mapping ist das Herzstück der Migration. Es ist eine tabellarische Übersicht, die jede alte URL der entsprechenden neuen URL zuordnet – oder dokumentiert, dass eine Seite gelöscht wird.
Drei mögliche Fälle:
- 1:1-Mapping: Alte URL → neue URL (inhaltlich identisch oder äquivalent)
- Thematisches Mapping: Alte URL → ähnlichste neue URL (wenn Inhalte zusammengelegt oder umstrukturiert wurden)
- Löschung: Alte URL → keine neue URL (Seite wird nicht migriert; Weiterleitungen auf Kategorieseite oder Startseite als Fallback)
Jede URL aus dem Crawl muss im Mapping landen. Es gibt keine Ausnahmen.
301 Redirects: Richtig einrichten, Chains vermeiden
301 Weiterleitungen (Permanent Redirect) übertragen bis zu 99 Prozent des Link Equity von der alten auf die neue URL. Sie sind die wichtigste technische Maßnahme bei jeder URL-Änderung.
Wie ihr sie korrekt einrichtet
Bei Apache-Servern über die .htaccess, bei Nginx über die Server-Konfiguration, bei WordPress über Plugins wie Redirection oder direkt im Code, bei modernen Headless-Setups über Next.js-Rewrites oder Vercel-Konfiguration.
Die Weiterleitung muss auf der HTTP-Ebene erfolgen – clientseitige JavaScript-Redirects (Meta-Refresh, JS-basiert) übertragen kein Link Equity und werden von Google schlechter verarbeitet.
Redirect-Chains vermeiden
Eine Redirect-Chain entsteht, wenn URL A auf URL B weiterleitet, die wiederum auf URL C zeigt. Jeder Hop kostet Crawl-Budget und verdünnt das übertragene Link Equity. Löst Chains auf, indem ihr direkt von A auf C zeigt.
Prüft nach dem Launch alle Weiterleitungen mit Screaming Frog oder einem ähnlichen Tool: Gibt es Chains? Gibt es Loops (A → B → A)? Landen die Weiterleitungen wirklich auf Status 200?
Was tun mit gelöschten Seiten?
Wenn eine Seite nicht mehr existiert und kein thematisches Äquivalent vorhanden ist, gibt es zwei Optionen: 410 (Gone, kommuniziert Google dass die Seite bewusst entfernt wurde) oder 404. Weiterleitungen auf die Startseite als universeller Fallback für irrelevante Seiten sind weniger empfehlenswert – Google erkennt sie als „Soft 404" und ignoriert die Weiterleitung.
Content-Migration: Was übernehmen, was neu schreiben, was löschen
Nicht jeder Inhalt der alten Site verdient einen Platz auf der neuen. Nutzt die Gelegenheit des Relaunchs, um euren Content-Bestand zu bereinigen.
Übernehmen und optimieren: Seiten mit nachgewiesenem Traffic, Rankings oder Backlinks. Diese migriert ihr inhaltlich treu und verbessert sie bei der Gelegenheit – aktualisierte Informationen, bessere Struktur, stärkere Keywords.
Neu schreiben: Seiten die thematisch wichtig sind, aber inhaltlich veraltet oder schwach. Nutzt die vorhandene URL-Geschichte und den potenziellen Link Equity, schreibt aber deutlich besseren Content.
Zusammenlegen: Wenn ihr auf der alten Site zehn dünne Seiten zum gleichen Thema hattet, fasst sie zu einer starken Seite zusammen. Alle alten URLs leiten auf die neue konsolidierte Seite weiter.
Löschen: Seiten ohne Traffic, ohne Backlinks, ohne thematische Relevanz, mit veraltetem oder qualitativ schlechtem Inhalt. Weniger Seiten, die indexiert werden, können die Qualitätswahrnehmung eurer Domain verbessern.
Phase 2 – Während des Launches: Der kritische Moment
Staging-Umgebung absichern
Die Staging-Umgebung – auf der ihr die neue Site entwickelt und testet – muss für Suchmaschinen unzugänglich sein. Optionen: HTTP-Basic-Auth, IP-Beschränkung, oder robots.txt mit Disallow: / auf dem Staging-Server.
Prüft unmittelbar vor dem Launch, dass die Staging-Umgebung gesperrt ist. Ein öffentlich erreichbares Staging mit identischem Content zur neuen Produktions-Site erzeugt massiven Duplicate Content.
robots.txt check
Einer der häufigsten und folgenschwersten Fehler: Die robots.txt der Staging-Umgebung enthält Disallow: / und wird beim Launch auf die Produktions-Site kopiert. Ergebnis: vollständige Deindexierung.
Prüft unmittelbar nach dem Launch, dass die robots.txt korrekt ist. Öffnet domain.de/robots.txt im Browser und überprüft, dass keine kritischen Bereiche blockiert sind.
noindex-Flags entfernen
Ähnliches Problem: Während der Entwicklung wurden auf allen Seiten noindex-Tags gesetzt, um versehentliche Indexierung zu verhindern. Beim Launch werden sie vergessen zu entfernen.
Crawlt die Live-Site sofort nach dem Launch und sucht nach Seiten mit noindex-Direktiven. Alle die indexiert werden sollen, müssen davon befreit sein.
sitemap.xml einreichen
Aktualisiert eure sitemap.xml auf die neuen URLs und reicht sie in der Google Search Console unter eurem neuen Property ein. Wenn ihr die Domain behalten habt, reicht die aktualisierte Sitemap ein und fordert eine erneute Indizierung an.
Phase 3 – Nach dem Relaunch: Überwachen und korrigieren
Google Search Console überwachen
In den ersten vier Wochen nach dem Launch checkt ihr die GSC täglich. Ihr sucht nach:
Crawl-Fehlern: 404-Fehler auf URLs die Google noch kennt, 5xx-Server-Fehler, Redirect-Fehler. Jeder neue Fehlertyp nach dem Launch ist ein Signal, dass etwas bei der Migration schiefgelaufen ist.
Indexierungsstatus: Wie viele Seiten sind indexiert? Gibt es Seiten die Google als „Duplicate ohne kanonisches Tag", „Not Found" oder „Blocked by robots.txt" markiert?
Traffic und Rankings: Erwartbar gibt es in den ersten Wochen Schwankungen. Ein kurzfristiger Rückgang von 10–20 Prozent ist normal. Ein Einbruch von 50+ Prozent ist ein Signal für ein ernstes Problem.
Backlinks prüfen
Wichtige eingehende Backlinks sollten nach dem Launch auf eure neuen URLs zeigen oder korrekt weitergeleitet werden. Prüft in Ahrefs oder der GSC unter „Links", ob eure Top-Backlinks noch auf erreichbare URLs verweisen.
Crawl-Fehler prüfen
Führt einen vollständigen Crawl der neuen Site mit Screaming Frog durch – am besten am Tag des Launches und noch einmal nach zwei Wochen. Prüft auf: Redirect-Chains, 404-Fehler, Seiten mit falschem noindex, fehlerhafte Canonical Tags, fehlende Meta-Daten.
Timeline: Wie lange dauert Ranking-Erholung realistisch?
Kein ehrlicher SEO gibt euch eine Garantie – aber es gibt realistische Erwartungswerte.
Kleine Sites (bis ~100 Seiten), saubere Migration, URLs weitgehend gleich: Erholung in 2–6 Wochen.
Mittelgroße Sites (100–1.000 Seiten), viele URL-Änderungen, aber korrektes Mapping: Erholung in 2–4 Monaten.
Große Sites (1.000+ Seiten), starke Strukturveränderung, Content-Konsolidierung: Erholung in 4–12 Monaten. Manche Rankings kommen nicht zurück – wenn die neue Struktur thematisch anders ausgerichtet ist, ist das manchmal auch gewollt.
Der wichtigste Faktor: Wie schnell crawlt Google eure Site? Bei großen Sites mit viel Crawl-Budget geht es schneller. Bei kleinen Sites, die selten gecrawlt werden, kann es länger dauern, bis Weiterleitungen vollständig verarbeitet sind.
Häufige Fehler und wie sie sich äußern
Keine Weiterleitungen, weil „die URLs haben sich kaum geändert": Auch kleine Unterschiede zählen. /blog/artikel-name vs. /news/artikel-name sind zwei verschiedene URLs für Google.
Weiterleitungen nur für die „wichtigsten" Seiten: Es gibt keine unwichtigen Seiten wenn sie Backlinks haben. Jede URL die extern verlinkt ist, braucht eine Weiterleitung.
Content vereinfacht oder gekürzt ohne Qualitätscheck: Was vorher rankete, tat das nicht zufällig. Wenn ihr Inhalte deutlich kürzt oder vereinfacht, riskiert ihr die Rankings dieser Seiten.
Interne Links nicht auf neue URLs aktualisiert: Weiterleitungen übernehmen die Arbeit, aber direkte interne Links auf die neue URL sind besser. Jede interne Weiterleitung kostet etwas.
Analytics und Tracking nicht konfiguriert: Wenn ihr nach dem Launch keinen Traffic seht, kann das ein Tracking-Problem sein – nicht unbedingt ein Ranking-Problem. Prüft zuerst, ob Google Analytics und Search Console korrekt eingebunden sind.
Ein Relaunch ist eine der besten Gelegenheiten, SEO-Potenziale zu realisieren – wenn er richtig geplant ist. Wenn ihr kurz vor einem Relaunch steht oder gerade mit den Folgen einer nicht optimalen Migration kämpft, ist jetzt der richtige Moment für eine Relaunch-Beratung. Wir prüfen euren Migrationsplan vor dem Launch oder analysieren, was nach dem Launch schiefgelaufen ist – und wie wir Rankings schnellstmöglich zurückgewinnen.