Website-Relaunch-Checkliste: Planung bis Go-live

Vor dem Projekt

Ziele, KPIs, Scope, Rollen und Freigaben definieren
Analytics, Rankings, Backlinks und alle indexierbaren URLs exportieren
Inhalte, Funktionen, Integrationen und rechtliche Anforderungen inventarisieren
Risiken, Budget, Zeitplan und Rollback-Verantwortung festhalten

Konzept und Umsetzung

Zielgruppen, User Journeys, Sitemap und Keyword-to-URL-Mapping
Inhalte behalten, verbessern, zusammenführen oder entfernen
Wireframes, responsive Design und Komponenten
Staging gegen Indexierung schützen
Tracking-, Consent-, Formular- und CRM-Anforderungen umsetzen
Redirect-Matrix von jeder relevanten alten URL zum passendsten Ziel

Pre-Launch

vollständiger Crawl; Statuscodes; Canonicals; hreflang; Schema
Titles, Descriptions, H1, interne Links, XML-Sitemap und robots.txt
Formulare, Suche, Checkout, E-Mails, Rollen und Browser testen
Core Web Vitals, Accessibility-Basics und Security prüfen
Backup, DNS-/Deployment-Plan und Monitoring vorbereiten

Nach dem Go-live

Crawl wiederholen, Search Console prüfen, Sitemap einreichen, Redirectfehler beheben, Analytics/Conversions validieren und Rankings, Traffic sowie Leads über mehrere Wochen überwachen.

Was bei einem Relaunch tatsächlich verändert wird

Ein Relaunch kann Design, Inhalte, CMS, Domain, URL-Struktur, Hosting oder mehrere Bereiche gleichzeitig verändern. Je mehr Ebenen parallel wechseln, desto schwerer lassen sich Fehler erkennen. Google empfiehlt bei komplexen Umzügen, Änderungen wenn sinnvoll in getrennten Schritten vorzunehmen.

Vor Projektbeginn wird deshalb festgelegt, welche Art Relaunch geplant ist:

Design-Relaunch: Oberfläche und Komponenten ändern sich, URLs und Inhalte weitgehend nicht;
Content-Relaunch: Struktur, Texte und Informationsarchitektur werden neu aufgebaut;
CMS-Migration: technische Plattform oder Rendering ändern sich;
Domain-/URL-Migration: Hostname, Protokoll oder Pfade wechseln;
Shop-Migration: Produkte, Kunden, Bestellungen und Commerce-Prozesse werden übertragen.

Diese Einordnung bestimmt Risiko, Tests und Monitoring.

Rollen und Entscheidungswege

Jeder kritische Bereich benötigt einen benannten Verantwortlichen. Typische Rollen sind Projektleitung, Geschäftsentscheidung, UX/UI, Entwicklung, Content, SEO, Analytics, Datenschutz/Recht, IT/Hosting und Qualitätssicherung. Bei Shops kommen Produktdaten, Payment, Versand und Kundenservice hinzu.

Eine RACI- oder einfache Verantwortungsmatrix klärt, wer umsetzt, freigibt, berät und informiert wird. Besonders wichtig: Wer darf den Go-live freigeben, wer kann ihn stoppen und wer entscheidet über einen Rollback?

Phase 1: Bestand sichern

Ziele und Baseline

[ ] Geschäftsziel und Problem des Relaunches dokumentieren.
[ ] KPIs mit aktuellem Ausgangswert sichern.
[ ] wichtige Conversion-Pfade und Zielgruppen festhalten.
[ ] saisonale Spitzen und kritische Verkaufszeiträume markieren.
[ ] aktuelle Ladezeit, Verfügbarkeit und Fehlerquote erfassen.
[ ] Search-Console-, Analytics- und Werbekonten sichern.
[ ] Zugriffe nicht ausschließlich bei einer alten Agentur belassen.

Vollständiges URL-Inventar

[ ] Website mit einem Crawler erfassen.
[ ] XML-Sitemaps und CMS-Export ergänzen.
[ ] URLs mit organischen Klicks aus Search Console ergänzen.
[ ] Landingpages aus Analytics und Ads ergänzen.
[ ] verlinkte URLs aus Backlinkdaten ergänzen.
[ ] PDFs, Bilder, Downloads und Kampagnen-Landingpages erfassen.
[ ] Statuscode, Canonical, Title, H1, Traffic und Links je URL speichern.

Keine einzelne Datenquelle enthält garantiert alle URLs. Das zusammengeführte Inventar bildet die Basis der Redirect-Matrix.

Content und Funktionen

[ ] Inhalte nach behalten, verbessern, zusammenführen, entfernen klassifizieren.
[ ] Formulare, Rechner, Suche, Login, Checkout und Downloads inventarisieren.
[ ] CRM-, ERP-, PIM-, E-Mail- und Zahlungsintegrationen dokumentieren.
[ ] Tracking-Tags und Consent-Abhängigkeiten erfassen.
[ ] rechtlich relevante Seiten und Pflichtinformationen markieren.
[ ] Content-Eigentümer und Freigabestatus festhalten.

Technische Sicherung

[ ] vollständiges Backup von Dateien und Datenbank erstellen.
[ ] Wiederherstellung testweise verifizieren.
[ ] DNS-, Hosting-, CDN- und Domainzugänge sichern.
[ ] Zertifikate, E-Mail-DNS und Subdomains dokumentieren.
[ ] Abhängigkeiten von Plugins, Lizenzen und externen APIs erfassen.
[ ] aktuellen robots.txt- und Header-Stand sichern.

Phase 2: Strategie und Architektur

Scope und Erfolg

[ ] Muss-, Soll- und Kann-Anforderungen priorisieren.
[ ] Nicht-Ziele ausdrücklich festhalten.
[ ] messbare Abnahmekriterien je Bereich definieren.
[ ] Budget, Zeit, Mitwirkung und Korrekturschleifen vereinbaren.
[ ] Risiko- und Entscheidungsprotokoll führen.

Informationsarchitektur

[ ] Zielgruppen und wichtigste Aufgaben beschreiben.
[ ] neue Sitemap auf Nutzerreise und Geschäftsziele ausrichten.
[ ] Keyword-Cluster eindeutig Ziel-URLs zuordnen.
[ ] Navigation, Footer, Breadcrumbs und interne Links planen.
[ ] ähnliche Inhalte sinnvoll zusammenführen.
[ ] Filter, Facetten, Suche und Paginierung definieren.
[ ] Sprach- und Länderstruktur einschließlich hreflang planen.

URL-Regeln

[ ] bestehende erfolgreiche URLs behalten, wenn kein guter Grund für Änderung besteht.
[ ] neue URLs kurz, stabil und sprechend definieren.
[ ] Klein-/Großschreibung, Slash, Parameter und Protokoll konsistent behandeln.
[ ] keine Datums- oder Technologiebezeichnungen einbauen, die schnell veralten.
[ ] für entfernte Inhalte das fachlich nächste Ziel bestimmen.

Phase 3: Content-Migration

[ ] für jede Zielseite H1, Zweck, Zielgruppe und CTA definieren.
[ ] Titles und Descriptions individuell vorbereiten.
[ ] alte starke Abschnitte nicht versehentlich verlieren.
[ ] Behauptungen, Preise, Team- und Standortdaten aktualisieren.
[ ] Bilder, Alt-Texte, Rechte und Dateigrößen prüfen.
[ ] Autoren, fachliche Prüfung und Aktualisierungsdatum festlegen.
[ ] interne Links auf neue endgültige URLs setzen.
[ ] Downloads und eingebettete Medien testen.
[ ] Inhalte in Deutsch und Englisch nicht nur maschinell spiegeln.
[ ] keine leeren Platzhalter zum Launch veröffentlichen.

Für WebAktive muss insbesondere die aktuelle Standortangabe korrekt bleiben: deutschlandweite Arbeit und Kundenbesuche bei Bedarf, aber derzeit kein deutscher Bürositz.

Phase 4: UX und Design

[ ] zentrale Nutzerreisen als Wireframes prüfen.
[ ] mobile Ansichten zuerst realistisch testen.
[ ] wiederverwendbare Komponenten und Zustände definieren.
[ ] Navigation mit echten Menünamen validieren.
[ ] klare visuelle Hierarchie und lesbare Typografie sicherstellen.
[ ] Formulare mit Fehler-, Erfolgs- und Ladezuständen gestalten.
[ ] Tastaturbedienung, Fokus, Kontrast und Alternativtexte berücksichtigen.
[ ] Cookie- und Consent-Oberflächen in das Design einbeziehen.
[ ] keine wichtigen Informationen nur über Animation vermitteln.
[ ] Design mit realen Textlängen statt Blindtext testen.

Phase 5: Entwicklung und CMS

Umgebungen und Deployment

[ ] getrennte Entwicklungs-, Staging- und Produktionsumgebung verwenden.
[ ] Staging per Authentifizierung und noindex schützen.
[ ] Produktions-Konfiguration nicht ungeprüft kopieren.
[ ] Deployment- und Rollback-Prozess dokumentieren.
[ ] Datenbankänderungen und Migrationsskripte testen.
[ ] Secrets und Schlüssel nicht im öffentlichen Code speichern.

Technische Grundlagen

[ ] semantisches HTML und korrekte Überschriftenstruktur umsetzen.
[ ] eindeutige Canonicals und absolute URLs ausgeben.
[ ] korrekte 200-, 301-, 404- und 410-Zustände verwenden.
[ ] XML-Sitemap nur mit kanonischen indexierbaren URLs erzeugen.
[ ] robots.txt für Produktion separat prüfen.
[ ] strukturierte Daten gegen sichtbare Inhalte validieren.
[ ] Open Graph, Favicons und Social Previews testen.
[ ] Fehlerseiten und interne Suche sinnvoll gestalten.

Performance

[ ] LCP-Bilder identifizieren und priorisieren.
[ ] responsive Bildgrößen und moderne Formate ausliefern.
[ ] unnötiges JavaScript und Drittanbieter-Tags reduzieren.
[ ] Fonts und kritisches CSS optimieren.
[ ] Platz für dynamische Inhalte reservieren.
[ ] Caching und CDN passend konfigurieren.
[ ] reale Kernseiten auf mobilen Geräten testen.

Phase 6: Redirect-Matrix und SEO-Migration

Für jede relevante alte URL wird genau ein passendes neues Ziel definiert. Eine permanente Weiterleitung wird serverseitig eingerichtet. Ketten wie alt → zwischen → neu und Schleifen werden vermieden. Viele alte Seiten dürfen nicht pauschal auf die Startseite zeigen, wenn dort kein entsprechender Inhalt existiert.

[ ] alte und neue URL in separaten Spalten dokumentieren.
[ ] 1:1-Ziele bevorzugen.
[ ] zusammengeführte Inhalte auf die neue Sammelseite leiten.
[ ] wirklich entfernte Inhalte bewusst als 404/410 behandeln.
[ ] externe Hauptlinks und Kampagnen direkt aktualisieren.
[ ] Redirects in Staging oder Testumgebung automatisiert prüfen.
[ ] HTTP/HTTPS, www/non-www und Slash-Varianten abdecken.
[ ] alte Redirect-Regeln erhalten, sofern weiterhin relevant.
[ ] interne Links direkt auf neue Ziele setzen.
[ ] Redirects langfristig aktiv lassen.

Google weist darauf hin, dass ein Umzug URL für URL verarbeitet wird und Schwankungen während erneuten Crawlings und Indexierens normal sein können. Eine sorgfältige Zuordnung und Überwachung reduziert das Risiko, beseitigt es aber nicht vollständig.

Phase 7: Analytics, Consent und Marketing

[ ] Messplan mit primären und sekundären Conversions dokumentieren.
[ ] Tag Manager, Analytics, Ads und Search Console vorbereiten.
[ ] Formular-, Telefon-, E-Mail- und Checkout-Events testen.
[ ] Transaktions-ID, Wert und Währung korrekt übertragen.
[ ] interne Zugriffe und Testbestellungen kennzeichnen.
[ ] Consent-Verhalten vor und nach Einwilligung prüfen.
[ ] UTM-Parameter und kanalübergreifende Zuordnung testen.
[ ] CRM- und Offline-Conversion-Übergabe validieren.
[ ] Datenschutz- und Rechtstexte fachlich freigeben lassen.
[ ] Ads-Ziel-URLs und Merchant-Feeds für den Launch vorbereiten.

Phase 8: Funktionale Qualitätssicherung

Geräte und Browser

[ ] aktuelle mobile und Desktop-Browser testen.
[ ] reale iOS- und Android-Geräte einbeziehen.
[ ] unterschiedliche Viewports und Zoom prüfen.
[ ] langsame Netzwerkbedingungen simulieren.

Formulare und Kommunikation

[ ] Pflichtfelder, Validierung und Fehlermeldungen testen.
[ ] Spam-Schutz und Rate Limits prüfen.
[ ] Erfolgsseite und Conversion Event validieren.
[ ] interne Benachrichtigung und Kundenbestätigung zustellen.
[ ] Reply-to und Absender korrekt konfigurieren.
[ ] personenbezogene Daten nicht unnötig protokollieren.

E-Commerce

[ ] Produktvarianten, Preise, Rabatte und Steuern prüfen.
[ ] Bestand und Lieferzeit synchronisieren.
[ ] Gast- und Kundencheckout testen.
[ ] alle relevanten Zahlungsarten in Test und Produktion prüfen.
[ ] Versandregeln, Gutscheine und Grenzfälle testen.
[ ] Bestell-, Storno-, Erstattungs- und Retourenprozess durchspielen.
[ ] Rechnung, E-Mail und ERP-Übergabe validieren.

Accessibility und Inhalt

[ ] Tastaturreihenfolge und sichtbaren Fokus prüfen.
[ ] Formularlabels und Fehlermeldungen zugänglich machen.
[ ] Kontraste und Vergrößerung testen.
[ ] Bilder mit sinnvollen Alternativen versehen.
[ ] Sprache, Rechtschreibung, Links und Telefonnummern prüfen.

Phase 9: Go-live-Plan

Ein Launchplan benennt genaue Uhrzeit, Reihenfolge, Verantwortliche und Stop-Kriterien.

[ ] verkehrsärmeren, aber betreuten Zeitpunkt wählen.
[ ] Content-Freeze und letzten Datenimport definieren.
[ ] frisches Backup und bestätigten Restore-Punkt erstellen.
[ ] DNS-TTL rechtzeitig prüfen.
[ ] Monitoring und Team-Kommunikationskanal öffnen.
[ ] Produktions-robots.txt und Indexierungsregeln aktivieren.
[ ] Redirect-Regeln veröffentlichen.
[ ] Zertifikat, Hostvarianten und Canonicals prüfen.
[ ] Smoke Tests für Startseite, Kernseiten, Formulare und Checkout ausführen.
[ ] Tracking und reale Test-Conversion kontrollieren.
[ ] bei Stop-Kriterium Rollback statt improvisierter Live-Reparatur auslösen.

Phase 10: Die ersten 24 Stunden

[ ] Verfügbarkeit und Serverfehler überwachen.
[ ] alten und neuen Crawl vergleichen.
[ ] wichtige alte URLs stichprobenartig testen.
[ ] Formulare, Zahlungen und E-Mails real prüfen.
[ ] Analytics-Echtzeitdaten und Conversion-Werte kontrollieren.
[ ] Search Console Properties und Sitemaps prüfen.
[ ] Ads und Profile auf korrekte Zielseiten kontrollieren.
[ ] Support und Vertrieb nach ungewöhnlichen Rückmeldungen fragen.

Die ersten vier Wochen

Täglich beziehungsweise anfangs engmaschig werden 404-Fehler, 5xx-Fehler, Indexierung, Sitemapstatus, Crawling, Rankings, organische Landingpages, Conversions und Umsatz beobachtet. Danach kann das Intervall reduziert werden.

Veränderungen werden nach URL-Gruppen und nicht nur im Gesamttraffic analysiert. Ein Rückgang kann durch Saison, Tracking, entfernte Inhalte oder neue Rankings entstehen. Probleme werden zuerst diagnostiziert, bevor weitere große Änderungen live gehen.

Stop- und Rollback-Kriterien

Vorher definierte Stop-Kriterien können sein:

Produktion nicht erreichbar;
Checkout oder primäres Formular funktioniert nicht;
kritische Datenmigration ist unvollständig;
alle Seiten sind versehentlich blockiert oder noindex;
Redirects erzeugen flächendeckend Fehler;
Zahlungen oder Bestellungen werden falsch verarbeitet;
Sicherheits- oder Datenschutzrisiko wird erkannt.

Rollback bedeutet nicht zwingend Scheitern. Es ist ein geplanter Schutzmechanismus, der eine kontrollierte Korrektur ermöglicht.

Häufige Relaunch-Fehler

alte URL-Daten erst nach dem Launch suchen;
Design, Domain, CMS und Content gleichzeitig ohne Risikoplan ändern;
Staging versehentlich indexieren lassen;
alle entfernten Seiten auf die Startseite umleiten;
interne Links weiter durch Redirects führen;
Analytics nur anhand von Seitenaufrufen testen;
Inhalte aus dem alten System unvollständig migrieren;
Rollback nicht vorbereiten;
Projekt am Go-live-Tag beenden statt mehrere Wochen zu überwachen.

Was WebAktive beim Relaunch übernimmt

WebAktive kann Discovery, Informationsarchitektur, modernes UX/UI, Entwicklung, SEO-Migration, Tracking und Marketing-Grundlage als zusammenhängendes Projekt aufbauen. Zu Beginn wird in einem kurzen Gespräch der Bedarf geklärt; anschließend folgen Fragen und Empfehlungen. Je nach Größe werden zusätzliche Spezialisten eingebunden, während WebAktive zentraler Ansprechpartner bleibt.

Das Ergebnis wird vertraglich definiert. Domain, Konten, Code, Design und Daten bleiben entsprechend der Vereinbarung unter Kontrolle des Kunden. Kosten können im WebAktive-Kalkulator zunächst eingeordnet und nach dem Discovery konkretisiert werden.

Quellen und weiterführende Informationen

Herausgeber: WebAktive
Fachliche Prüfung: WebAktive-Team, IT und Marketing
Stand: August 2026