Website Relaunch: Die SEO-Checkliste aus 15+ Projekten

Jeder zweite Relaunch kostet Rankings. Nicht, weil er technisch unmöglich ist, sondern weil die SEO-Checkliste vergessen wird. Oder nur halb umgesetzt. Oder zum falschen Zeitpunkt. In 15 Jahren haben wir 50+ Relaunches begleitet — von E-Commerce-Plattformen mit 80.000 Seiten bis zu mittelstaendischen B2B-Seiten. Diesmal schreiben wir auf, was wirklich funktioniert.

Was ist ein Website Relaunch aus SEO-Perspektive?

Ein Relaunch ist nicht einfach ein Redesign. Es ist eine Migration. Die Domain bleibt oft gleich, aber die Struktur, die URLs, das CMS, manchmal auch die Inhalte — alles aendert sich. Aus Googles Perspektive ist das eine massive Veränderung. Und massive Veränderungen führen zu Volatilitaet im Ranking.

Wir definieren Relaunches in drei Kategorien:

Soft Relaunch: Design und Inhalte ändern sich, die URL-Struktur bleibt. Hier ist der SEO-Schaden am kleinsten — wenn alles richtig gemacht wird.

Hard Relaunch mit neuer URL-Struktur: Neue Struktur, neues Design, oft neues CMS. Das ist der klassische Fall, den wir hier behandeln. Redirect-Mapping wird zur Pflichtaufgabe.

Domain-Migration: Komplette neue Domain. Das ist der Worst Case. Wir sehen das bei Rebrandings und verlieren regelmäßig 20-40% der Organic-Visibility — selbst mit perfekten Redirects.

Dieser Artikel konzentriert sich auf Hard Relaunches mit bestehender Domain, weil das der Standardfall ist.

Phase 1: Pre-Relaunch (3-6 Monate vorher)

1. Das SEO-Audit, das wirklich zählt

Nicht das Standard-Audit-Tool-Geplauder. Wir sprechen von:

Visibility-Snapshot: Mit Sistrix, SEMrush oder Ahrefs: Welche Keywords ranken? Welche genau? Welche Seiten generieren Traffic?

Das ist nicht optional. Das ist dein Baseline. Ohne diesen Snapshot wirst du nicht wissen, ob der Relaunch ein Erfolg oder ein Desaster war.

Link-Profil dokumentieren: Backlinks zählen und katalogisieren. Welche internen Links führen wohin? Welche externen Links sind kritisch? Tools wie Ahrefs oder Moz geben dir hier den Export.

Content-Audit: Welche Seiten konvertieren? Welche Seiten ranken besser als andere? Das CMS-Team wird später sagen “wir haben alles migriert”, und du wirst wissen, dass das nicht stimmt.

Core Web Vitals und PageSpeed: Baseline dokumentieren. Ein Relaunch ist oft auch eine Chance, die Performance zu verbessern — aber nur wenn du weisst, wo du stehst.

Protokolliere alles in einer Tabelle. Google Sheets ist ausreichend:

• URL (alt)
• Ranking Keywords
• Traffic (letzte 3 Monate)
• Backlinks
• Status (canonical, index, noindex)

Zeitaufwand: 2-3 Wochen für größere Seiten. Ja, das ist lang. Ja, das spart später Wochen Debugging.

2. Content-Freeze vs. Launch-Phase

Das ist der größte Fehler, den wir regelmäßig sehen: Die alte Seite wird bis zum letzten Tag mit neuem Content gefuettert, und dieser Content wird nicht migriert.

Unsere Regel: 6 Wochen vor dem Launch — Content-Freeze. Keine neuen Blogposts, keine neuen Landingpages auf der alten Seite. Alles wird auf die neue Seite geschrieben.

Das ist organisatorisch unangenehm, aber SEO-technisch essentiell. Warum? Google crawlt die alte Seite noch. Wenn neue Inhalte auf der alten Seite entstehen, wird Google verwirrt. Und verwirrt Google = Rankings gehen runter.

3. Die neue URL-Struktur planen

Das ist das Fundament. Hier entscheidet sich, ob der Relaunch ein Erfolg wird.

Alt: /blog/article-name/ Neu: /resources/guides/seo/article-name/

Das sieht schoener aus. Ist strukturierter. Und kostet dich 30-40% der Rankings, weil Google die interne Linkstruktur nicht mehr versteht.

Unsere Regel: Struktur-Migration nur, wenn es weh tut, nicht zu migrieren.

Konkrete Beispiele aus unseren Projekten:

Projekt 1 (E-Commerce, 12.000 Produkte): Alt war /shop/category/subcategory/product/. Neu sollte /kategorie/product/ sein. Wir haben das verhindert. Warum? Weil die alte Struktur stabil war und 5 Jahre Linkpower aufgebaut hatte. Migration haette 20-30% gekostet. Stattdessen: Nur Texte aktualisiert, URLs behalten.

Projekt 2 (Publishing-Seite, 4.000 Artikel): Alt war /2021/06/article-title/. Voellig unlogisch, Google konnte die Relevanz nicht interpretieren. Neu: /blog/article-title/. Das war schmerzhaft, aber sinnvoll. Wir haben die Migration mit parallelem Content-Audit kombiniert und 50% der schwachen Seiten gar nicht migriert — stattdessen 404 oder Sammelpages.

Projekt 3 (Next.js/Vercel Tourismus-Plattform, ca. 5.000 URLs): Hier zeigte sich das typische Framework-Relaunch-Problem: 230 Soft-404-Seiten gaben HTTP 200 zurück, obwohl sie nur eine “Sorry”-Meldung enthielten — ausgelöst durch Catch-All-Routing. 486 Canonical-Tags landeten außerhalb des <head>, 458 hreflang-Tags ebenso. Und Parameter-Varianten wie /en/barcelona/faq?product=2 konkurrierten mit sauberen URLs. Das sind typische Relaunch-Fallen bei JavaScript-Frameworks, die man nur mit einem systematischen Post-Launch-Audit erkennt.

Die URL-Struktur-Regel: Wenn die alte Struktur funktioniert, ist eine Änderung ein Risiko. Wenn die alte Struktur dysfunktional ist, ist eine Änderung eine Notwendigkeit.

4. Redirect-Mapping: Das ist kein Excel-Job

Das ist der kritischste Punkt. Ein Redirect-Fehler ist ein Ranking-Fehler.

Automatische Mapping-Tools sind unzuverlässig. Wir haben das hundertfach gesehen. Tools, die automatisch versuchen, alte URLs zu neuen zu mappen, erzeugen Chaos. 404er, falsche Zielseiten, Redirect-Ketten.

Stattdessen: Manuelles Mapping mit Logik.

Hier ist unser Framework:

1. 1:1 Mappings identifizieren: Diese Seite existiert auf der neuen Seite in identischer oder sehr ähnlicher Form — 301 zu dieser Seite.

2. Kategorische Umschichtung: Diese 50 Artikel gehoeren zusammen — 301 zu einer neuen Kategorie-Seite oder einer Archiv-Seite.

3. Konsolidierung: Diese 10 schwachen Artikel sollten sowieso konsolidiert werden — 301 zu einer stärkeren verwandten Seite.

4. 404 akzeptieren: Diese Seite war schwach, wird nicht migriert — 404 mit internem Link auf relevante neue Seite.

Der Prozess:

Excel-Spalten:
- Alte URL
- Neue URL (wenn 1:1)
- Redirect-Typ (1:1, Kategorie, Konsolidierung, 404)
- Begruendung
- Verantwortliche Person
- Status (geplant, programmiert, getestet)

Für größere Seiten (>1.000 URLs): Dieser Job wird eine Person sein, die die Seite kennt. Nicht jemand, der sie zum ersten Mal sieht.

Zeitaufwand: 1 Woche für 500 URLs. 4 Wochen für 5.000 URLs. Das ist realistisch.

5. Der SEO-Stakeholder-Alignment

Das ist unterschaetzt. Der CTO denkt, Relaunch ist ein technischer Job. Der Product Manager denkt, es ist ein Design-Job. Der CEO denkt, es kostet nichts extra. Die Kommunikation muss klar sein.

Wir haben ein Standard-Meeting-Format:

Woche -8: Kick-off. SEO-Audit vorstellen. URL-Struktur vorstellen. Content-Freeze ankuendigen. Redirect-Mapping-Verantwortung klären.

Woche -4: Status Review. Redirect-Mapping steht. Neue Seite ist im Staging. Crawler-Test laeuft.

Woche -1: Finales Check. Alles sitzt? Monitoring-Setup konfiguriert? Go/No-Go-Entscheidung.

Tag 0 (Launch): Jeder weiss, was sein Job ist.

Phase 2: Der Launch selbst

Soft Launch vs. Hard Launch

Hard Launch: Schalte am Montag 00:00 um. Alle URLs gehen live.

Vorteil: Schnell. Einfach.

Nachteil: Wenn es schief geht, sind alle 10.000 URLs betroffen. Rollback wird zum Albtraum.

Soft Launch: 10-20% Traffic auf neue Seite (via Cookie, User-Agent oder Segment), Rest auf alte Seite. 2-4 Wochen laufen lassen.

Vorteil: du siehst Probleme früh. Rollback ist einfach (Prozentsatz auf 0 zurück).

Nachteil: Crawlers sehen zwei Seiten. Das ist verwirrend für Google. du brauchst Canonical-Tags oder Parameter-Handling.

Unsere Regel: Immer Soft Launch. Minimum 2 Wochen bei 50/50 Split. Das kostet eine Woche Zeit, spart dir aber 80% potentieller Disasters.

Die Umsetzung:

Tag 1-3: 5% neue Seite, 95% alte
Tag 4-7: 25% neue Seite, 75% alte
Tag 8-14: 50/50
Wenn keine kritischen Fehler: 100% neue Seite

DNS-Propagation und Caching

Das ist selten ein SEO-Problem, aber es ist ein Relaunch-Problem. Wenn der Server falsch konfiguriert ist, sehen verschiedene Leute (und Google) verschiedene Seiten.

Zwei Tage vor Launch: Den DNS-TTL auf 300 Sekunden setzen (nicht 3600).

Nach Launch: TTL für 48 Stunden auf 300 halten. Nach 48 Stunden zurück auf 3600.

Das ist kein SEO-Job, aber der SEO sollte es wissen.

Canonical-Tags und X-Robots

Während des Soft Launch sollte die alte Seite sich selbst als Canonical ausweisen. Das ist kontraintuitiv, macht aber Sinn:

<!-- Auf alter Seite waehrend Soft Launch -->
<link rel="canonical" href="https://alt.example.com/article/" />

Das sagt Google: “Verwende diese Version.” Das verhindert Duplicate-Content-Probleme.

Nach dem Hard Launch (100% Traffic auf neue Seite): Canonical-Tag auf neue URL ändern.

Phase 3: Post-Relaunch (erste 4-8 Wochen)

Monitoring Setup: Das ist kein Nice-to-Have

du brauchst drei Tools:

Google Search Console (GSC): Hier siehst du die Realität. Wie viele Seiten sind indexed? Welche Fehler meldet Google? Crawl-Stats — das ist deine Wahrheit.

Im GSC solltest du folgende Punkte monitoren:

• Coverage Report: Gesamtzahl indexierter Seiten sollte ca. 80-90% der alten Seiten sein (wir konsolidieren ja). Wenn es 50% sind, ist was falsch.

• Enhancements (Structured Data): Wenn die alte Seite Rich Snippets hatte, müssen diese auf der neuen Seite auch da sein.

• Core Web Vitals: Die sollten sich nicht verschlechtern. Ein Relaunch mit neuem Design sollte besser werden, nicht schlechter.

• Mobile Usability: Sind neue Fehler aufgetaucht? (Normalerweise ja, wenn das Design komplett neu ist.)

Sistrix (oder SEMrush): Visibility-Index tracken. Das ist dein Ranking-Barometer.

Erwartungen:

• Tag 1-3: Leichter Drop (5-15%). Normal. Google re-crawlt.
• Woche 1-2: Drop kann sich verschärfen (bis 30%). Auch normal, wenn Redirects langsam indexiert werden.
• Woche 3-4: Sollte sich stabilisieren oder leicht erholen.
• Woche 5-8: Sollte zum alten Level zurück sein (oder höher, wenn alles richtig gemacht).

Wenn du nach 8 Wochen immer noch 30% unter dem alten Level bist: Es gibt ein Problem. Entweder im Redirect-Mapping oder in der neuen Seite selbst.

Screaming Frog: Vor/Nachher-Vergleich.

Crawl die alte Seite. Crawl die neue Seite. Vergleiche:

Alt: 8.000 URLs, 45 broken links
Neu: 7.200 URLs, 120 broken links (!)

Das ist ein Fehler. Broken Links müssen auf neue URLs zeigen, nicht 404 sein.

Die 5 häufigsten Fehler und wie man sie vermeidet

Fehler 1: Redirect-Kettenlänge

Eine Seite redirected zu B, B redirected zu C. Google wird ungeduldig. Das ist eine 2-Hop-Chain. Schlecht.

Lösung: Direct redirect. Alt direkt zu neu. Prüfe vor Launch alle Chains mit einem einfachen curl-Befehl.

Fehler 2: Content-Unterschiede

Die neue Seite hat nur 30% des alten Contents. Google sieht das und reduziert das Ranking.

Lösung: Content-Audit vor dem Relaunch. Welcher Content ist wichtig? Dieser Content muss auf die neue Seite. Punkt. Alte Seite 2.000 Wörter, neue Seite sollte >1.800 Wörter sein.

Fehler 3: Schlechte interne Verlinkung

Die neue Seite hat keine internen Links. Oder nur 2 statt 20.

Lösung: Internal Links mappen. Alt hatte Links von 15 anderen Seiten. Neu sollte auch Links von 15 anderen Seiten haben (oder mehr). Tool: Ahrefs Batch Analysis oder manuelles Durchzählen.

Fehler 4: Robots.txt und Meta-Robots-Fehler

Die neue Seite ist aus Versehen in Robots.txt blocked oder hat <meta name="robots" content="noindex" />.

Lösung: Vor Launch robots.txt und alle Meta-Robots-Tags checken. Automatisiert.

Fehler 5: Monitoring-Fehler und Silent 404er

Eine ganze Kategorie von Seiten macht 404 statt 301. Keiner merkt es, weil das Monitoring schlecht ist.

Lösung: Proaktives Monitoring. Nicht auf GSC-Errors warten. Selbst crawlen, selbst vergleichen. Unser Prozess: Tag 1, Tag 7, Tag 30 nach Launch jeweils Screaming Frog Crawl durchführen.

Monitoring-Dashboard: Was wir aufbauen

Für unsere Clients bauen wir immer ein einfaches Tracking-Sheet auf. Nicht fancy, aber effektiv:

Datum | GSC Indexierte Seiten | Sistrix Visibility | Avg. CWV Score | Broken Links | Status
---
2026-04-12 | 7.100 | 68% | 78 | 145 | Soft Launch gestartet
2026-04-13 | 7.050 | 67% | 77 | 142 | OK
2026-04-14 | 6.950 | 64% | 76 | 138 | Leichter Drop, normal
2026-04-19 | 7.200 | 72% | 79 | 95 | Recovering
2026-04-26 | 7.400 | 88% | 81 | 12 | Hard Launch, Soft Launch beendet

Das wird taeglich updated (GSC/Sistrix automatisiert via API oder manuell). Der Status wird woechentlich per Meeting reviewed.

Wenn Visibility weiter fällt nach Tag 14: Escalation. Dann ist was falsch.

Die 67-Punkte-Checkliste (Kurzversion)

Das ist der Standard, den wir für jeden Relaunch nutzen. Nicht jeder Punkt ist für alle Seiten relevant, aber diese Liste war schon bei 50+ Relaunches dabei.

Pre-Relaunch (30 Punkte)

• SEO-Audit durchgeführt (Visibility, Links, Keywords)
• Alle Rankings dokumentiert (Tool-Export)
• Content-Audit durchgeführt
• Core Web Vitals Baseline dokumentiert
• Backlink-Profil katalogisiert
• Content-Freeze 6 Wochen vorher
• URL-Struktur geplant und reviewed (mit CTO und SEO)
• Redirect-Mapping 100% fertig
• Redirect-Mapping getestet (alle URLs getestet, nicht nur Stichproben)
• Neue Seite auf Staging gecrawlt mit Screaming Frog
• Canonicals auf neuer Seite gesetzt
• Robots.txt korrekt (keine Disallows für Hauptseite)
• Meta-Robots-Tags korrekt (kein noindex auf Staging)
• Server-Response-Codes kontrolliert (200 für neue URLs)
• Redirect-Response-Codes kontrolliert (301, nicht 302)
• Hreflang-Tags gesetzt (wenn mehrsprachig)
• Structured Data (Schema) auf neuer Seite
• Open Graph und Twitter Cards konfiguriert
• Google Search Console Property für neue Domain erstellt
• GSC Ownership verifiziert
• Sitemap.xml generiert
• Sitemap in GSC eingereicht
• Internal Links-Mapping (welche Seite linkt zu welcher)
• Backlink Monitoring Setup (Ahrefs/Moz/Sistrix)
• 404-Handling Plan (Custom 404 mit Links)
• Brand-Search Monitoring Setup
• Keyword-Ranking Monitoring Setup (Top 50-100)
• Team-Training durchgeführt
• Go/No-Go Meeting
• Rollback-Plan dokumentiert

Launch-Phase (12 Punkte)

• Soft Launch mit 5% Traffic gestartet
• Monitoring Dashboards live und taeglich updated
• Alerts konfiguriert (GSC, Sistrix, Monitoring-Tool)
• Team verfügbar (nicht im Urlaub)
• Soft Launch 2 Wochen bei 50/50 Split
• Keine kritischen Fehler in Woche 1-2
• Hard Launch durchgeführt
• Alle Mitarbeiter benachrichtigt
• Neue URL in Marketing-Tools updated (GA4, Facebook Pixel, etc.)
• Email-Benachrichtigungen an alle Stakeholder
• Monitoring verdoppelt in Woche 1
• Taegliche Status-Calls für erste 10 Tage

Post-Launch (25 Punkte)

• GSC Coverage Report taeglich geprüft
• Broken Links taeglich geprüft
• Crawl-Errors taeglich bearbeitet
• Sitemap taeglich re-submitted
• Rankings taeglich in Sistrix/SEMrush geprüft
• Core Web Vitals geprüft
• Mobile Usability Errors bearbeitet
• Indexed Pages sollten bei 90-95% der alten Seiten sein
• Internal Links-Profil überprüft
• External Backlinks überprüft
• Keyword-Rankings nach 7 Tagen analysiert
• Keyword-Rankings nach 30 Tagen analysiert
• Visibility-Chart analysiert (sollte sich erholen)
• Brand-Search Traffic analysiert
• Content-Quality überprüft
• User Behavior überprüft (Bounce Rate? Session Duration?)
• Conversion-Rate überprüft
• Traffic-Quellen überprüft (Organic sollte stabil sein oder steigen)
• Ranking-Volatilitaet überwacht
• Wettbewerber-Rankings überwacht
• Performance optimiert (Core Web Vitals)
• Redirects überprüft nach 60 Tagen (sollten alle 301 sein)
• GSC Removal Request aktiviert (für alte URLs, die nicht mehr ranken sollen)
• Final Go/No-Go nach 30 Tagen
• Lessons-Learned Dokumentation

Die Punkte auf “Abgehakt” zu setzen ist weniger wichtig als zu verstehen, welche Punkte für deine Seite kritisch sind.

Spezialfälle und Besonderheiten

E-Commerce mit 10.000+ Produkten

Hier versagt das Manual-Redirect-Mapping. Wir nutzen einen anderen Ansatz:

1. Alte URLs mit IDs versehen: Jede Produkt-URL bekommt eine eindeutige Kategorie-ID und Produkt-ID als Query-Parameter.
2. Mapping-Logik programmieren: Produkt existiert noch? 301 zu neuer Produkt-Seite. Produkt existiert nicht? 301 zu Kategorie-Seite. Kategorie wurde konsolidiert? 301 zu neuer Kategorie.
3. Bulk-Testing: Nicht 10.000 URLs testen, sondern 500 pro Kategorie als Sample.

Das reduziert den manuellen Aufwand um 80%.

Publishing mit älteren Inhalten

Hier ist eine kategorische Entscheidung nötig: Behalte alle alten Inhalte oder nicht?

Wir empfehlen: Seiten älter als 2 Jahre und mit unter 50 organischen Impressionen pro Monat — nicht migrieren.

Das klingt brutal, ist aber rational. Diese Seiten ranken nicht, generieren nicht viel Traffic. Sie zu migrieren kostet Ressourcen und bringt nichts. Statt 301 dann 404 mit interner Linkstruktur.

Mehrsprachige Seiten

Komplexer. Hier brauchst du Hreflang-Tags für alle Sprach-Varianten.

Und hier passiert der größte Fehler: Hreflang-Tags werden vergessen.

<!-- Deutsche Seite -->
<link rel="alternate" hreflang="de" href="https://example.com/de/artikel/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/article/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/article/" />

Wenn die Hreflang-Tags falsch sind oder fehlen: Google indexiert die falschen Versionen und Rankings crashen.

Lösung: Screaming Frog Hreflang-Audit vor und nach Launch. Das dauert 2-3 Stunden, spart aber 40% potentielle Fehler.

CMS-Migration (WordPress zu Headless, Shopify zu Custom, etc.)

Ein häufiger Sonderfall, den wir zunehmend sehen: CMS-Wechsel als Teil des Relaunches. Dabei ändern sich oft nicht nur URLs, sondern auch die Art, wie Inhalte gerendert werden. Von serverseitigem PHP-Rendering zu clientseitigem JavaScript (React, Next.js, Nuxt) ist ein fundamentaler Wechsel.

Unser Workflow für CMS-Migrationen:

1. Rendering-Check vor dem Wechsel: Prüfe mit Screaming Frog im JavaScript-Rendering-Modus, ob der Googlebot alle Inhalte sieht. Headless-CMS-Setups mit Client-Side-Rendering können dazu führen, dass Google leere Seiten indexiert.

2. Structured Data migrieren: Viele CMS haben eigene Schema-Plugins. Beim Wechsel gehen Structured Data häufig verloren. Exportiere alle JSON-LD-Implementierungen vorher und stelle sicher, dass sie im neuen System vorhanden sind.

3. Internal Links überprüfen: CMS-Wechsel brechen oft interne Verlinkungen, besonders wenn absolute URLs im Content stehen, die auf die alte Struktur verweisen. Screaming Frog findet diese Broken Links in Minuten.

4. Meta-Daten migrieren: Title Tags, Meta Descriptions und Canonical Tags müssen 1:1 übertragen werden. Bei WordPress-zu-Headless-Migrationen geht das Yoast-SEO-Plugin verloren — die Daten müssen manuell oder per Script in das neue System überführt werden.

5. Sitemap-Generierung testen: Nicht jedes Headless-Setup generiert automatisch eine XML-Sitemap. Prüfe das früh, nicht am Launch-Tag.

Der häufigste Fehler bei CMS-Migrationen: Teams konzentrieren sich auf Design und Funktionalitaet, aber vergessen die SEO-Infrastruktur. Das kostet im Schnitt 3-6 Monate Recovery-Zeit.

Fazit: Warum 50% der Relaunches Rankings kosten

Es sind nicht die technisch unmöglichen Fehler, die Rankings zerstören. Es ist die fehlende Checkliste.

Ein Relaunch ohne SEO-Planung ist wie ein Umzug ohne Adressänderungen. du kannst in das neue Haus ziehen, aber die Post kommt nicht an.

Die 67-Punkte-Checkliste ist nicht perfekt. Aber sie ist aus 50+ Relaunches entstanden. Und jede Seite, die diese Checkliste 100% umgesetzt hat, hat Rankings behalten oder gewonnen.

Jede Seite, die 30% der Punkte ignoriert hat, hat 20-40% der Rankings verloren.

Das ist nicht Zufall. Das ist Mathematik.

Praktische nächste Schritte

1. dein Relaunch kommt? Drucke die 67-Punkte-Checkliste aus. Klebe sie an die Wand. Arbeite sie ab.

2. Schneller als 3 Monate? Dann mindestens die Pre-Launch Punkte 1-15 machen. Das ist das Non-Negotiable.

3. Budget für Monitoring da? Sistrix + GSC + Screaming Frog = max 500 Euro/Monat. Das ist ein Bruchteil der Relaunch-Kosten und spart dir 50k+ in Rankings.

4. Team-Alignment unklar? Das erste Meeting, das zählt, ist nicht mit dem CTO. Es ist mit allen Stakeholdern zusammen. Sag ihnen, was Ranking-Verlust kostet (in Euro).

Dann werden sie es ernst nehmen.