PRAXISLEITFADEN · WEBSITE-RELAUNCH
Website-Relaunch-Checkliste.
Ein Relaunch ist erst abgeschlossen, wenn wichtige Alt-URLs, Suchsignale, Kontaktwege und technische Funktionen nach der Veröffentlichung überprüfbar weiterarbeiten. Diese Checkliste führt von der Bestandsaufnahme bis zur Nachkontrolle.
Das wichtigste Relaunch-Prinzip
Jede relevante Alt-URL braucht eine bewusste Entscheidung: behalten, aktualisieren, zusammenführen, gezielt weiterleiten oder begründet entfernen. Eine pauschale Weiterleitung aller alten Seiten auf die Startseite bewahrt weder Suchintention noch Nutzerweg.
Die Checkliste unterstützt Planung und Abnahme. Für Konzeption und Umsetzung bleibt Webentwicklung und Website-Relaunch in Lübeck der kommerzielle Owner.
Was beeinflusst die Kosten eines Website-Relaunchs?
Ein Relaunch lässt sich nicht seriös aus der sichtbaren Seitenzahl allein ableiten. Aufwand entsteht vor allem dort, wo Inhalte, URLs, Funktionen, Integrationen und technische Signale kontrolliert übernommen oder verändert werden müssen.
Seiten- und Template-Typen
Entscheidend ist, wie viele unterschiedliche Layouts und Inhaltsmodelle geprüft und umgesetzt werden müssen, nicht wie oft ein Template vorkommt.
Content-Migration
Texte, strukturierte Inhalte, Metadaten, Medien und Downloads müssen inventarisiert, bereinigt, zugeordnet und nach der Übernahme kontrolliert werden.
Redirect-Komplexität
Geänderte, zusammengeführte oder entfernte URLs brauchen ein vollständiges Mapping. Sonderfälle, alte Ketten und externe Verweise erhöhen den Prüfaufwand.
Formulare & Integrationen
Kontaktwege, APIs, CRM-, Newsletter- oder andere Systemanbindungen brauchen funktionale Tests einschließlich Fehler- und Berechtigungsfällen.
Tracking & Conversions
Bestehende erlaubte Ereignisse, Ziele und Einwilligungslogik müssen dokumentiert, bewusst übernommen oder neu definiert und anschließend getestet werden.
Strukturierte Daten
Schema darf nur sichtbare und tatsächliche Inhalte beziehungsweise Entitäten beschreiben. Änderungen an Seitentypen brauchen deshalb eine erneute Prüfung.
Barrierefreiheit & Qualität
Tastaturbedienung, Fokus, Kontraste, semantische Struktur, mobile Darstellung und Fehlerzustände gehören in die Abnahme und dürfen nicht erst nach dem Launch auffallen.
Mehrsprachigkeit, Medien & Assets
Sprachvarianten, hreflang, Bilder, Videos, Downloads und Cache-Versionierung erweitern Inventar, Migration und Testumfang.
Technische Migration
Hosting, Build, DNS, Header, Canonicals, Sitemap, robots-Regeln und Release-Prozess müssen am Zielsystem zusammenpassen.
Testtiefe
Je mehr kritische Seitentypen, Gerätebreiten, Integrationen und Weiterleitungen bestehen, desto größer wird die notwendige automatisierte und manuelle Abnahme.
Keine Preisautomatik: Diese Faktoren erklären, warum zwei Relaunches mit ähnlicher sichtbarer Größe technisch sehr unterschiedlich sein können. DatenpflegeNord veröffentlicht hier bewusst keine erfundenen Pauschalpreise oder aus fremden Angeboten übernommene Preisbereiche.
Website-Relaunch in acht prüfbaren Phasen.
Der Projektplan macht die bestehende Checkliste zeitlich nutzbar. Jede Phase hat ein Ziel, konkrete Kontrollen, eine typische Verantwortung und einen klaren Fehler, den sie verhindern soll.
| Phase | Ziel | Schlüsselchecks | Typische Verantwortung | Fehlerrisiko |
|---|---|---|---|---|
| 1. Baseline | Ausgangslage messbar festhalten. | Indexierbare URLs, Rankings/Traffic soweit verfügbar, Conversions, Canonicals, Statuscodes, Performance. | SEO/Analyse + Projektleitung | Nach dem Launch fehlt ein belastbarer Vorher-Vergleich. |
| 2. Inventory | Alle relevanten Inhalte und Funktionen erfassen. | URLs, Templates, Medien, Formulare, Integrationen, Tracking, strukturierte Daten. | Content + Technik | Versteckte Funktionen oder wichtige Alt-Inhalte verschwinden. |
| 3. Architektur & Mapping | Für jede Alt-URL und Funktion ein Ziel festlegen. | KEEP/UPDATE/MERGE/REDIRECT/REMOVE, Navigation, interne Links, Redirect-Ziel, neue Informationsarchitektur. | SEO + UX/Content + Technik | Suchintentionen werden auf falsche oder zu allgemeine Ziele umgeleitet. |
| 4. Implementierung | Neue Struktur und Funktionen reproduzierbar bauen. | Templates, Inhalte, Metadaten, Formulare, Schnittstellen, Schema, Accessibility. | Entwicklung + Content | Design ist fertig, aber technische Anforderungen fehlen oder driften auseinander. |
| 5. Staging | Den geplanten Release vor Veröffentlichung abnehmen. | Indexschutz, Canonicals, interne Links, mobile Breiten, Tastatur, Formulare, Assets, Schema, Sitemap. | QA + Entwicklung + Fachabnahme | Fehler werden erst unter öffentlichem Traffic sichtbar. |
| 6. Migration | Inhalte, Daten und URL-Regeln vollständig vorbereiten. | Content-Import, Redirect-Datei, Medien, Tracking-Konfiguration, Release-Paket, Rollback-/Fallback-Plan. | Entwicklung + Content + Betrieb | Staging und tatsächlicher Release enthalten unterschiedliche Daten oder Regeln. |
| 7. Launch | Geprüften Stand kontrolliert veröffentlichen. | Statuscodes, Redirects, Canonicals, robots, Sitemap, Formulare, Integrationen, Assets, Caches. | Entwicklung/Betrieb + QA | Ein funktionierendes Staging scheitert an DNS, Cache, Headern oder Release-Dateien. |
| 8. Post-Launch-Verifikation | Reale Auslieferung und Suchsignale überwachen. | 404/5xx, Redirectketten, Indexierung, gewählte Canonicals, Conversions, CWV und relevante Sichtbarkeit. | SEO/Analyse + Technik | Schleichende Verluste oder Fehler bleiben nach dem Launch unentdeckt. |
Die interaktive Checkliste weiter unten bildet diese Phasen praktisch ab. Sie wird deshalb erweitert genutzt statt durch ein zweites, konkurrierendes Tool ersetzt.
Alt-URLs vollständig entscheiden, nicht stichprobenartig.
Die Matrix verbindet jede bestehende URL mit Inhalt, Ziel, Statuscode und späterem Prüfergebnis. Dadurch werden Lücken vor dem Go-live sichtbar.
| Entscheidung | Wann sie passt | Was dokumentiert wird |
|---|---|---|
| KEEP | URL und Inhalt erfüllen weiterhin dieselbe Aufgabe. | Unveränderte Ziel-URL und Abnahme des ausgelieferten Inhalts. |
| UPDATE | Die URL bleibt, Inhalt oder Technik werden überarbeitet. | Neue Inhalte, Metadaten, interne Links und fachliche Freigabe. |
| MERGE | Mehrere überlappende Seiten werden zu einem besseren Ziel zusammengeführt. | Primäres Ziel, übernommene Inhalte und Weiterleitungen aller Quellen. |
| REDIRECT | Ein gleichwertiges neues Ziel übernimmt die Aufgabe dauerhaft. | Exakte Quelle, exaktes Ziel, 301-Status und keine Redirectkette. |
| REMOVE | Der Inhalt hat keinen Ersatz und soll bewusst entfallen. | Begründung, erwarteter Status und entfernte interne Verweise. |
Welche Signale müssen beim Relaunch kontrolliert mitwandern?
Ein Relaunch verändert häufig URL-Struktur, Inhalte und Technik gleichzeitig. Deshalb werden Suchsignale und technische Auslieferung als zusammenhängende Migration geprüft.
URL- und Redirect-Plan
Jede relevante Alt-URL bekommt eine bewusste Entscheidung. 301-Weiterleitungen zeigen direkt auf das finale gleichwertige Ziel; Ketten und pauschale Homepage-Redirects werden vermieden.
Canonical & Indexierbarkeit
Canonical, robots-Regeln, Meta-Robots, Statuscode und Sitemap müssen dieselbe beabsichtigte indexierbare URL beschreiben. Staging-Schutz darf nicht in Produktion verbleiben.
Interne Links & Navigation
Interne Verweise sollten direkt auf neue finale Ziele zeigen. Veraltete Alt-URLs nur über Redirects weiterzuschleifen verschenkt Klarheit und erschwert spätere Wartung.
Inhalt & Suchaufgabe
Wichtige Themen und Nutzeraufgaben werden nicht allein wegen eines neuen Designs entfernt. Zusammenführungen brauchen ein Ziel, das die bisherige Aufgabe tatsächlich übernimmt.
Release-Parität
Der abgenommene Commit, die erzeugten Assets und die tatsächlich ausgelieferte Version müssen zusammenpassen. Sonst wird nicht das veröffentlicht, was geprüft wurde.
Nach dem Launch
404/5xx, Redirects, Formulare, Canonicals, Sitemap, Indexierung und Suchdaten werden gegen die dokumentierte Baseline geprüft. GSC-Daten sind dabei besonders wertvoll, falls verfügbar.
Relaunch von Vorbereitung bis Nachkontrolle prüfen.
Alle Punkte stehen im HTML und bleiben ohne JavaScript lesbar. Mit JavaScript werden Häkchen und Fortschritt ausschließlich im lokalen Browserspeicher gesichert.
Der Bearbeitungsstand bleibt als lokale Browser-Einstellung auf diesem Gerät. Es erfolgt keine Übertragung an ein Backend und kein Marketing-Tracking.
Warum ein grünes Staging allein nicht genügt.
DNS, Cache, Header und tatsächliche Release-Dateien können sich erst am öffentlichen Ziel zeigen. Deshalb braucht der Relaunch eine reproduzierbare Prüfung vor und nach der Aktivierung.
Release-Parität
Der freigegebene Commit, das gebaute Paket und das ausgelieferte Verzeichnis müssen denselben geprüften Inhalt repräsentieren. Nachträgliche Änderungen entwerten die Abnahme.
Asset-Freshness
Wenn CSS, JavaScript oder Bilder geändert werden, müssen neue Referenzen auf die neuen Bytes zeigen. Unveränderte Assets dürfen im Browsercache bleiben.
Canonical- und Slash-Prüfung
Jede indexierbare Seite braucht eine eindeutige bevorzugte URL. Varianten mit anderem Host, Protokoll oder Slash dürfen keine konkurrierenden Inhalte erzeugen.
Post-Launch-Verifikation
Statuscodes, Weiterleitungen, Formulare, Schema, Sitemap und mobile Darstellung werden gegen die vorher dokumentierten Erwartungen geprüft.
Relaunch mit klarer Abnahme planen.
Beschreiben Sie Ausgangsseite, Ziele und notwendige Funktionen. Zugangsdaten oder sensible Nutzerdaten gehören nicht in die erste Anfrage.
Relaunch besprechen ↗