Website-Relaunch: Projektmanagement für Enterprise-Unternehmen
Stakeholder-Mapping, Dual-Track-Agile, SEO-Migration und Risk-Register — wie Enterprise-Unternehmen Website-Relaunches strukturiert planen und ohne Traffic-Verluste durchführen. Ein Leitfaden für Projektleiter und Entscheider.
Warum Enterprise-Relaunches überdurchschnittlich häufig scheitern
In keiner anderen Projektklasse im Digitalbereich ist die Diskrepanz zwischen Erwartung und Ergebnis so groß wie beim Website-Relaunch. Projekte, die mit einer Timeline von 6 Monaten gestartet werden, dauern 18. Budgets werden um 40–80 Prozent überschritten. Und nach dem Launch sinkt der organische Traffic häufig um 20–50 Prozent — weil die SEO-Migration falsch oder gar nicht durchgeführt wurde.
Die Ursachen liegen fast nie in der technischen Umsetzung. Sie liegen in mangelhaftem Projektmanagement:
- Unklare Entscheidungsstrukturen führen zu ständig nachgereichten Anforderungen
- Fehlende SEO-Strategie für die Migration vernichtet aufgebaute Rankings
- Kein formales Risk-Register bedeutet, dass bekannte Risiken nicht eskaliert werden
- Interne Stakeholder werden zu spät eingebunden und blockieren dann den Launch
Dieser Leitfaden zeigt den strukturierten Ansatz für Enterprise-Website-Relaunches.
Phase 0: Stakeholder-Mapping und Governance-Definition
Bevor das erste Briefing geschrieben wird, müssen Entscheidungsstrukturen definiert sein. Wer kann Was entscheiden? Wer muss bei Was konsultiert werden?
Das RACI-Modell für Website-Projekte
RACI steht für Responsible, Accountable, Consulted, Informed. Für ein typisches Enterprise-Website-Projekt sieht die Besetzung so aus:
| Entscheidung | Verantwortlich (R) | Letztverantwortlich (A) | Konsultiert (C) | Informiert (I) |
|---|---|---|---|---|
| Strategie & Ziele | CMO | Geschäftsführung | IT-Leitung, Vertrieb | Alle Stakeholder |
| Technische Architektur | IT-Leitung | CTO | Agentur | CMO |
| Inhalt & Design | Marketing-Projektleitung | CMO | Fachabteilungen | IT |
| Datenschutz | DSB | Rechtsabteilung | IT, Marketing | Alle |
| Launch-Entscheidung | Projektleitung | Auftraggeber (CMO) | IT, Rechtsabteilung | Gesamtvorstand |
Ohne ein klares RACI-Modell werden Entscheidungen endlos eskaliert, weil niemand sicher ist, ob er entscheiden darf.
Steering Committee
Bei Projekten über 150.000 Euro empfiehlt sich ein Steering Committee, das monatlich tagt. Besetzung: Auftraggeber-seitig CMO + CTO + ggf. CFO; Agentur-seitig Account Director + Projektleitung + technische Leitung. Das Steering Committee entscheidet über Scope-Änderungen und eskalierte Risiken.
Phase 1: Discovery und Anforderungskonsolidierung
Technisches Bestandsaudit
Vor dem ersten Wireframe muss der technische Bestand dokumentiert sein:
- Vollständige URL-Liste aller indexierten Seiten (aus GSC exportieren)
- Traffic-Profile der Top-100-Seiten (als SEO-Migration-Prioritätsliste)
- Analyse aller integrierten Systeme (CRM, ERP, Marketing-Automation, PIM)
- Performance-Baseline (Core Web Vitals des alten Systems)
- Dependency-Map aller eingebundenen Drittanbieter-Skripte
Dieser Bestand ist die Referenz für die gesamte Migration. Nichts wird gelöscht, bevor es im Audit dokumentiert und eine Entscheidung getroffen wurde.
Content-Audit
Ein Content-Audit bewertet alle bestehenden Seiten nach:
- Traffic (GSC-Daten der letzten 12 Monate)
- Backlink-Profil (Anzahl und Qualität externer Links auf diese URL)
- Conversion-Beitrag (generiert diese Seite Leads oder trägt sie zur Funnel-Begleitung bei?)
- Content-Qualität (aktuell? inhaltlich korrekt? mit Duplikaten?)
Ergebnis: Jede Seite erhält eine von vier Empfehlungen: Behalten, Überarbeiten, Zusammenführen, Löschen (mit Redirect). Dieser Entscheidungsrahmen verhindert, dass im Relaunch wertvoller SEO-Ballast mitgenommen wird — oder umgekehrt, dass traffics-starke Seiten ohne Redirect gelöscht werden.
Phase 2: Projektplanung mit Dual-Track-Agile
Klassische Wasserfall-Planung (erst alles spezifizieren, dann alles umsetzen) funktioniert bei komplexen Enterprise-Websites nicht, weil Anforderungen sich während des Projekts entwickeln. Rein agil ohne einen Discovery-Track führt zu unkontrollierter Scope-Creep.
Dual-Track-Agile trennt Discovery (Anforderungsklärung und Konzeption) von Delivery (Umsetzung) in parallelen Tracks:
- Discovery Track: Konzeption, UX-Design, Content-Strategie, technische Architektur laufen 2–4 Sprints voraus
- Delivery Track: Umsetzung beginnt, sobald Discovery-Ergebnisse für den ersten Modul stabil sind
Typische Sprint-Struktur (2-Wochen-Sprints):
| Sprint | Discovery Track | Delivery Track |
|---|---|---|
| 1–2 | Bestandsaudit, Anforderungskonsolidierung, Information Architecture | — |
| 3–4 | Wireframes Homepage + Schlüsselseiten, Tech-Stack-Entscheidung | Dev-Environment-Setup, CMS-Konfiguration |
| 5–6 | Design-System, Visual Design Schlüsselseiten | Komponenten-Entwicklung (Atoms/Molecules) |
| 7–10 | Content-Produktion, Restliche Wireframes | Seitenentwicklung, CMS-Integration |
| 11–12 | QA-Planung, Redirect-Map | QA, Performance-Optimierung |
| 13 | Launch-Checkliste | Staging-Deploy, pre-launch-Audit |
| 14 | — | Go-live, Post-launch-Monitoring |
Phase 3: SEO-Migration als eigenes Sub-Projekt
Die SEO-Migration ist das am häufigsten unterschätzte Element eines Website-Relaunches. Falsch durchgeführt vernichtet sie jahrelang aufgebaute organische Sichtbarkeit innerhalb von Wochen.
Die Redirect-Map
Die Redirect-Map dokumentiert jede URL, die sich im Relaunch ändert oder entfällt, und definiert das Redirect-Ziel:
- Alte URL:
/leistungen/suchmaschinenoptimierung/→ Neue URL:/seo/(301) - Gelöschte URL:
/blog/artikel-von-2018-der-entfernt-wird/→ Thematisch ähnlichste aktive URL (301) - Zusammengeführte URLs:
/produkte/kategorie-a/+/produkte/kategorie-b/→/produkte/(301)
Keine URL darf im Relaunch auf ein 404 laufen, wenn sie relevante Backlinks oder organischen Traffic hat. Das ist eine nicht verhandelbare Regel.
Metadata-Migration
Alle SEO-relevanten Metadaten der alten Website müssen dokumentiert werden:
- Title-Tags und Meta-Descriptions
- Strukturierte Daten (JSON-LD-Typen und Inhalte)
- Canonical-Tags
- hreflang-Tags (bei mehrsprachigen Sites)
Diese werden auf die neuen Seiten übertragen und optimiert — nicht automatisch übernommen, sondern manuell geprüft.
Pre-Launch-Crawl-Audit
Vor dem Go-live wird das Staging-System vollständig gecrawlt (Screaming Frog oder Sitebulb) und gegen den Bestandscrawl verglichen:
- Alle Redirects korrekt gesetzt?
- Keine Seite mit Noindex-Tag, die im Live-System indexiert sein soll?
- Alle strukturierten Daten korrekt übertragen?
- Alle internen Links aktualisiert (keine Verlinkung auf alte URLs)?
Erst wenn dieser Crawl-Vergleich ohne kritische Findings ist, wird der Launch freigegeben.
Phase 4: Das Risk-Register
Ein Risk-Register dokumentiert alle identifizierten Projektrisiken, ihre Eintrittswahrscheinlichkeit, Auswirkung und Gegenmaßnahmen.
Typische Risiken in Enterprise-Website-Projekten:
| Risiko | Wahrsch. | Auswirkung | Gegenmaßnahme |
|---|---|---|---|
| Inhalte werden intern nicht rechtzeitig geliefert | Hoch | Hoch | Content-Freeze-Datum 4 Wochen vor Launch mit Eskalationspfad |
| CRM-Integration schlägt fehl | Mittel | Hoch | Technisches Proof-of-Concept in Sprint 3 |
| Datenschutz-Review verzögert Launch | Mittel | Mittel | DSB ab Sprint 1 einbeziehen, nicht erst vor Launch |
| SEO-Traffic-Einbruch post-launch | Mittel | Hoch | Pre-launch-Crawl-Audit + 30-Tage-Monitoring-Plan |
| Stakeholder-Blocka- de kurz vor Launch | Niedrig | Sehr hoch | RACI-Eskalationspfad in Governance-Dokument definiert |
Das Risk-Register wird wöchentlich aktualisiert und im Steering Committee besprochen.
Phase 5: Launch und Post-Launch-Monitoring
Launch-Checkliste (Auszug)
- DNS-TTL 24 Stunden vor Launch auf 300 Sekunden reduziert
- Alle Redirects im Produktions-System implementiert und getestet
- robots.txt korrekt (kein
Disallow: /aus der Staging-Konfiguration übernommen) - Sitemap.xml aktuell und bei Google Search Console eingereicht
- Google Analytics 4 / Tracking korrekt konfiguriert und getestet
- Consent-Management aktiviert und korrekt kategorisiert
- Core Web Vitals im Produktionssystem gemessen (nicht nur Staging)
- Rollback-Plan dokumentiert und mit Hosting-Anbieter kommuniziert
30-Tage-Post-Launch-Monitoring
In den ersten 30 Tagen nach Launch werden täglich überwacht:
- Google Search Console: Coverage-Fehler, Indexierungsstatus, Traffic-Anomalien
- Core Web Vitals (CrUX-Daten aktualisieren sich nach ca. 28 Tagen)
- Crawl-Monitoring (sitemap.xml-Änderungen, neue 404-Fehler)
- Conversion-Rate auf Kontaktseiten und Lead-Magneten
Lesen Sie mehr zur SEO-Strategie im Enterprise-Kontext: Enterprise-SEO vs. Local SEO: Strategie für skalierbare Sichtbarkeit.
Verbindung zu Ausschreibung und ROI
Ein Relaunch-Projekt, das im Chaos endet, folgt fast immer einer schlechten Ausschreibung. Die Grundlage für ein erfolgreiches Relaunch-Projekt wird im RFP-Prozess gelegt — wie Website-RFP: Professionelle Ausschreibung für Enterprise-Projekte erklärt.
Den Erfolg des Relaunches messen und kommunizieren: Corporate Digital Transformation: ROI sauber messen.
Fazit: Projektmanagement-Disziplin als Erfolgsfaktor
Ein Website-Relaunch ist kein Kreativ-Projekt, das sich selbst organisiert. Es ist ein Programm mit klarer Governance, mehreren Sub-Projekten (SEO, Content, Tech, Compliance) und hohem Koordinationsbedarf. Die Investition in professionelles Projektmanagement ist die günstigste Versicherung gegen die teuren Fehler, die ohne sie fast immer passieren.
Relaunch mit Wender Media
Wender Media begleitet Enterprise-Relaunches als technischer Lead und Projektmanagement-Partner — von der Ausschreibung über die SEO-Migration bis zur Post-Launch-Stabilisierung.