Website-Relaunch: Planung, Fehler, Kosten und Checkliste

Ein Website-Relaunch startet nie auf einer leeren Fläche.

Auf der alten Website liegen Inhalte, URLs, Links, Suchsignale, Formulare, Zugänge, Bilder und Erwartungen. Manche davon sind wertvoll. Manche bremsen. Manche wirken unwichtig, bis sie nach dem Launch fehlen.

Genau deshalb ist ein Relaunch kein reines Designprojekt. Er ist ein kontrollierter Umbau an einem System, das bereits benutzt wird.

Dieser Leitfaden hilft dir, zuerst die richtige Eingriffstiefe zu wählen, dann Wertvolles zu schützen und schliesslich den Launch so zu planen, dass nicht erst nach Veröffentlichung auffällt, wer was hätte prüfen sollen.

1. Welchen Relaunch brauchst du wirklich?

Nicht jede veraltete Website braucht einen vollständigen Neubau. Fünf Projektarten werden im Alltag oft unter demselben Wort verkauft:

Das Risiko steigt nicht nur mit der Grösse der Website. Es steigt mit der Anzahl grundlegender Dinge, die gleichzeitig verändert werden: Inhalt, Navigation, CMS, URL-Struktur, Domain, Design und Tracking.

Die erste Relaunch-Frage lautet deshalb: Was muss sich verändern, damit das Geschäftsziel erreicht wird, und was darf dafür bewusst gleich bleiben?

Wenn nur drei Leistungsseiten unklar sind, ist ein kompletter Systemwechsel möglicherweise teure Ablenkung. Wenn Angebot, Marke, Struktur und Technik seit Jahren nicht mehr passen, ist ein neues Hero-Bild nur Kosmetik.

2. Der Relaunch-Brief auf einer Seite

Bevor Sitemap, Design oder System gewählt werden, sollte dieses Dokument stehen:

Ziel

Was soll der neue Auftritt konkret verbessern? Zum Beispiel verständlichere Leistungen, passendere Anfragen, eine neue Positionierung, bessere Bewerbungen, einfachere Pflege oder stabilere Technik.

Ausgangswert

Welche Daten zeigen den heutigen Stand? Organische Klicks und Impressionen, wichtigste Einstiegsseiten, Anfragen, Buchungen, Formulare, Ladezeiten, häufige Supportfragen. Ohne Ausgangswert bleibt nach dem Launch nur ein Gefühl.

Auslöser

Welche beobachtbaren Probleme rechtfertigen den Relaunch? Trenne Symptome («sieht alt aus») von Ursachen («unser heutiges Angebot ist nicht verständlich und wichtige Seiten sind technisch nicht erweiterbar»).

Nicht verhandelbare Werte

Welche URLs, Inhalte, Funktionen, Integrationen, Markenbestandteile, Zugänge oder Abläufe müssen erhalten bleiben?

Eingriffstiefe

Welche der fünf Projektarten passt? Welche grossen Veränderungen werden bewusst nicht gleichzeitig gemacht?

Verantwortung

Wer besitzt intern Ziel, Inhalt, Technik, Freigabe und Launch-Entscheidung? Wer hat am Launch-Tag die Befugnis, zu stoppen oder zurückzurollen?

Zeitfenster

Gibt es Saison, Kampagnen, Messen, Recruiting-Phasen oder andere Termine, die den Launch beeinflussen? Ein fixes Datum ohne Zeit für Inhalte, Migration und Tests ist kein Plan.

3. Inventar: Schützen, verbessern, entfernen, neu erstellen

Der wichtigste Relaunch-Schritt passiert, bevor etwas gelöscht wird.

Erfasse mindestens:

• alle erreichbaren URLs aus Sitemap, CMS, Analytics und Search Console;
• Seiten mit Klicks, Impressionen, Links oder direktem Traffic;
• Texte, Downloads, Bilder und Videos;
• Formulare, Buchungen, Shops und Schnittstellen;
• Navigation und interne Links;
• Meta-Daten, strukturierte Daten und Sprachversionen;
• Analytics, Consent, Search Console und Verifikationen;
• Domain, DNS, Hosting, E-Mail-Abhängigkeiten und Zertifikate;
• rechtliche Seiten und tatsächlich eingesetzte Dienste;
• wiederkehrende Pflege- und Veröffentlichungswege.

Ordne jedes Element in eine von vier Entscheidungen:

«Alt» ist dabei kein Löschgrund. Eine unscheinbare Seite kann Suchtraffic, externe Links oder einen wichtigen Kundenweg tragen. Umgekehrt muss ein alter Inhalt nicht bleiben, nur weil er existiert.

Für jede entfernte URL braucht es eine bewusste technische Entscheidung: Gibt es einen wirklich passenden neuen Inhalt, wird dauerhaft dorthin weitergeleitet. Gibt es keinen Ersatz, ist ein korrekter 404- oder 410-Status ehrlicher als eine irrelevante Weiterleitung auf die Startseite.

4. Die Risikokarte

Bewerte jede grosse Veränderung nach Auswirkung und Umkehrbarkeit:

Wenn du gleichzeitig Domain, CMS, Navigation, Inhalte und Marke wechselst, kannst du einen späteren Einbruch schwer einer Ursache zuordnen. Wo möglich, sollten grosse Änderungen sequenziert oder zumindest separat messbar und testbar sein.

Das bedeutet nicht, dass ein umfassender Relaunch falsch ist. Es bedeutet, dass er eine klare Risikoverantwortung, mehr Testtiefe und eine bessere Ausgangsdokumentation braucht.

5. Was ein Website-Relaunch kostet

Seriöse Relaunch-Kosten folgen aus Arbeitssträngen, nicht aus einer pauschalen Anzahl Seiten:

Besonders teuer werden Entscheidungen, die zu spät fallen: Eine neue Seitenstruktur nach finalem Design. Texte, die erst in der Entwicklung entstehen. Ein CMS-Wechsel, der ohne Inhaltsmodell kalkuliert wurde. Oder eine URL-Migration, die erst kurz vor dem Launch auffällt.

Die allgemeinen fünf Faktoren für Website-Kosten und den fairen Angebotsvergleich findest du in Was kostet eine Website?. Bei einem Relaunch kommt vor allem der Schutz des Bestehenden dazu.

Frage in jedem Angebot ausdrücklich:

• Ist die Bestandsaufnahme enthalten?
• Wer erstellt und prüft das URL-Mapping?
• Welche Inhalte werden übernommen, verbessert oder neu geschrieben?
• Gehören Staging, Migration, Redirect-Tests und Nachkontrolle zum Scope?
• Wer ist nach dem Launch wie lange erreichbar?
• Was passiert, wenn beim Inventar mehr Umfang sichtbar wird?

6. Der vollständige Relaunch-Ablauf

Wir strukturieren den Prozess mit unserem Website-Strategy-Framework ACP42: Aim, Create, Promote. Für einen Relaunch bedeutet das:

Aim: Klarheit und Schutz

1. Ziel und Ausgangswerte festhalten.
2. Website, Inhalte, Marke, Technik und Suchdaten inventarisieren.
3. Schützen, verbessern, entfernen und neu erstellen entscheiden.
4. Zielstruktur, Seitenumfang und Verantwortungen definieren.
5. Risiko, System und Migrationsweg klären.
6. Scope, Meilensteine und Abnahmebedingungen vereinbaren.

Create: Inhalt, Gestaltung und System

1. Seitenlogik und Nutzerwege ausarbeiten.
2. Positionierung und Texte entwickeln.
3. Designrichtung und wiederverwendbare Komponenten gestalten.
4. Website auf einer geschützten Testumgebung umsetzen.
5. Inhalte, Daten und Medien migrieren.
6. URL-Mapping, Meta-Daten, interne Links und technische Regeln einbauen.
7. Inhaltliche, visuelle, technische und barrierebezogene Abnahme durchführen.

Promote: Migration, Kontrolle und Wachstum

1. Launch-Runbook und Verantwortungen bestätigen.
2. Backup, Redirects, DNS, Verifikationen und Tracking vorbereiten.
3. Kontrolliert live schalten.
4. Website und wichtigste Wege sofort testen.
5. Sitemap einreichen, Crawling und Indexierung beobachten.
6. Fehler, Traffic und Anfragen in den ersten Wochen prüfen.
7. Verbesserungen aus echten Daten priorisieren.

Wie lange das dauert, hängt besonders von Inhaltsmenge, Feedback, Migration und Funktionen ab. Die realistischen Zeitfaktoren stehen in Wie lange dauert eine Website?.

7. SEO-Migration ohne falsche Versprechen

Niemand kann garantieren, dass Rankings während eines Relaunches völlig unverändert bleiben. Google weist selbst darauf hin, dass bei grösseren Änderungen vorübergehende Schwankungen möglich sind.

Was sich sauber planen lässt:

Alte und neue URLs zuordnen

Erstelle eine Tabelle mit alter URL, neuem Ziel, Entscheidung, bisheriger Relevanz und Teststatus. Google empfiehlt bei Website-Umzügen ein Mapping alter und neuer URLs, bevor die Weiterleitungen aktiviert werden.

Relevante permanente Weiterleitungen verwenden

Wenn ein Inhalt dauerhaft auf eine neue URL zieht, sind serverseitige permanente Weiterleitungen der klare Weg. Google empfiehlt nach Möglichkeit 301- oder 308-Weiterleitungen.

Leite nicht pauschal alles auf die Startseite. Ein altes Leistungsdetail gehört zu seinem inhaltlich passenden neuen Ziel. Wenn es keines gibt, ist 404/410 oft korrekt.

Ketten vermeiden

Wenn A früher auf B zeigte und B nun auf C zieht, sollte A möglichst direkt auf C zeigen. Weiterleitungsketten machen Crawling und Nutzung langsamer und erschweren die Kontrolle.

Canonical, Robots und Noindex prüfen

Testumgebungen sind häufig absichtlich blockiert. Beim Launch müssen Canonicals auf die finalen URLs zeigen und versehentliche noindex-Regeln entfernt sein. Das ist ein kleiner Eintrag mit potenziell sehr grosser Wirkung.

Interne Links aktualisieren

Neue Seiten sollten direkt auf neue Ziele verlinken, nicht über alte URLs und Redirects. Das gilt für Navigation, Textlinks, Bilder, Canonicals, hreflang und strukturierte Daten.

Sitemap und Search Console

Die neue Sitemap muss nur indexierbare finale URLs enthalten. Reiche sie nach dem Launch ein und beobachte Indexierung, Fehler, Klicks und Impressionen. Bei einem echten Domainwechsel gehören zusätzlich Verifikationen und das passende Change-of-Address-Verfahren in den Plan.

Die kurze KSWD-Antwort auf die Frage «Kann ein Relaunch meinem SEO schaden?» steht auch in den häufigen Fragen.

8. Abnahme vor dem Launch

Die Website ist nicht bereit, wenn sie auf einem Laptop gut aussieht. Sie ist bereit, wenn die vereinbarten Wege unter realistischen Bedingungen funktionieren.

Inhalt und Marke

• Angebot, Zielgruppen und nächster Schritt sind klar
• alte Platzhalter und Testinhalte sind entfernt
• Namen, Zahlen, Adressen, Öffnungszeiten und Kontaktdaten stimmen
• echte Belege und Referenzen sind korrekt dargestellt
• Bild- und Nutzungsrechte sind geklärt
• alte Markenbegriffe sind dort entfernt, wo sie nicht bleiben sollen

Nutzerführung und Barrierefreiheit

• Navigation und wichtige Wege funktionieren mit Tastatur und auf Touch-Geräten
• Fokuszustände, Kontraste, Alternativtexte und Überschriftenstruktur sind geprüft
• Formulare haben verständliche Labels, Fehler und Bestätigungen
• mobile Inhalte entsprechen der Desktop-Version in Bedeutung und Vollständigkeit
• Zoom, Schriftgrössen und responsive Umbrüche funktionieren

Barrierefreiheit sollte laut W3C über Planung, Umsetzung und laufenden Betrieb integriert werden. Ein automatischer Test allein kann diese Abnahme nicht ersetzen.

Technik und Performance

• HTTPS, Canonical, Robots, Sitemap und Statuscodes stimmen
• Bilder sind dimensioniert, komprimiert und stabil eingebunden
• CSS, JavaScript, Fonts und externe Dienste laden wie geplant
• 404-Seite und Fehlerfälle funktionieren
• Browser- und Gerätetest ist dokumentiert
• Backup und Wiederherstellungsweg sind vorhanden

Funktionen und Daten

• jedes Formular wurde mit einer echten Testübermittlung geprüft
• Bestätigungen, Empfänger, Spam-Schutz und Datenschutz funktionieren
• Buchung, Shop, Login und Schnittstellen sind mit realistischen Fällen getestet
• Analytics, Search Console und Verifikationen sind vorhanden
• Consent-Verhalten entspricht den tatsächlich geladenen Diensten

SEO und Migration

• jede geänderte wertvolle URL hat eine dokumentierte Entscheidung
• Redirects führen direkt zum relevanten finalen Ziel
• interne Links zeigen auf finale URLs
• Titles, Descriptions und strukturierte Daten sind vollständig
• Staging-Blockaden werden beim Launch sicher entfernt
• alte und neue Crawl-Ergebnisse können verglichen werden

Unser allgemeiner Launch-Check fasst die letzte Qualitätsrunde kompakt zusammen. Beim Relaunch kommt die Bestands- und Migrationskontrolle oben drauf.

9. Der Launch-Tag als Runbook

Ein Runbook ist eine Reihenfolge mit Namen, nicht nur eine Checkliste. Ersetze «Name eintragen» vor dem Launch überall durch die tatsächlich verantwortliche Person.

Definiere vorher:

• Wer entscheidet über Go oder No-Go?
• Wer behebt Inhalt, Design, Entwicklung, DNS und Tracking?
• Wie erreicht das Team einander während der Umschaltung?
• Welche Fehler rechtfertigen einen Rollback?
• Wie wird dokumentiert, was geändert wurde?

«Wir schauen dann» ist am Launch-Tag keine Zuständigkeit.

10. Die ersten 30 Tage

Sofort bis 48 Stunden

• Erreichbarkeit, Zertifikat, Formulare und wichtigste Funktionen mehrfach prüfen.
• Fehlerprotokolle, 404s, Redirects und Indexierbarkeit kontrollieren.
• Analytics-Eingang und Search-Console-Verifikation bestätigen.
• interne und externe Links mit hohem Wert aktualisieren, wo möglich.

Erste Woche

• neuen vollständigen Crawl mit der Ausgangsversion vergleichen;
• fehlende Titles, Canonicals, strukturierte Daten und Inhalte beheben;
• Search Console auf Crawling- und Indexierungsprobleme prüfen;
• echte Anfragen und Rückmeldungen aus dem Team sammeln;
• mobile und langsame Verbindungen nochmals real testen.

Woche zwei bis vier

• Klicks, Impressionen und wichtigste Seiten beobachten, ohne tägliche Schwankungen zu dramatisieren;
• alte URLs weiter auf 404s, Ketten und falsche Ziele prüfen;
• Anfragequalität, Formularabbrüche und häufige Fragen auswerten;
• nur klar diagnostizierte Probleme ändern, statt nervös die ganze Struktur erneut anzufassen;
• eine priorisierte Liste für die Weiterentwicklung erstellen.

Ein Relaunch ist technisch live, bevor er organisatorisch abgeschlossen ist. Verantwortlichkeiten müssen deshalb über den Veröffentlichungstag hinausreichen.

11. Zwölf häufige Relaunch-Fehler

1. Die Lösung wird vor der Diagnose beschlossen. Ein neues CMS wird gekauft, obwohl das Problem Inhalt und Positionierung ist.
2. Alles wird gleichzeitig verändert. Danach ist nicht erkennbar, welche Änderung wirkt oder schadet.
3. Die alte Website wird nicht inventarisiert. Wertvolle URLs, Inhalte und Funktionen verschwinden unbemerkt.
4. Seiten werden nach Bauchgefühl gelöscht. Suchdaten, Links und echte Nutzung werden zu spät geprüft.
5. Alle alten URLs zeigen auf die Startseite. Nutzer und Suchmaschinen landen an einem unpassenden Ziel.
6. Inhalte kommen zu spät. Design und Entwicklung werden mit Platzhaltern abgenommen, die reale Seite passt später nicht mehr.
7. Mobile wird als verkleinerter Desktop behandelt. Prioritäten, Interaktion und Formulare brechen auf kleinen Geräten.
8. Barrierefreiheit wird auf einen Score reduziert. Tastatur, Fokus, Verständnis und echte Nutzung bleiben ungeprüft.
9. Staging-Noindex bleibt aktiv. Die neue Website blockiert ihre eigene Indexierung.
10. Formulare werden nur optisch geprüft. Bestätigung erscheint, aber keine Nachricht kommt an.
11. Tracking startet neu ohne Vergleich. Der Erfolg kann nicht gegen einen Ausgangswert bewertet werden.
12. Nach dem Launch gehört das Problem niemandem. Kleine Fehler bleiben liegen, bis sie Sichtbarkeit oder Vertrauen kosten.

12. Fragen an den Relaunch-Partner

• Wie entscheidet ihr, was bleiben, verbessert oder entfernt werden soll?
• Welche Daten und Zugänge braucht ihr vor dem ersten Entwurf?
• Wer verantwortet Inhalt, Design, Entwicklung, SEO und Migration konkret?
• Wie wird die alte URL-Liste erstellt und priorisiert?
• Wie dokumentiert und testet ihr Weiterleitungen?
• Welche grossen Veränderungen würdet ihr nicht gleichzeitig durchführen?
• Wie werden CMS, Daten und wiederkehrende Inhaltstypen migriert?
• Welche Barrierefreiheits- und Performance-Prüfungen gehören zur Abnahme?
• Wer erstellt das Launch-Runbook und hat Go/No-Go-Verantwortung?
• Wie lange und in welchem Umfang überwacht ihr die Website danach?
• Was gehört nicht zum Angebot?
• Welche Zugänge, Daten und Dateien erhalten wir vollständig?

Wie wir selbst Relaunches angehen

Wir behandeln einen Relaunch wie einen kontrollierten Umbau: erst prüfen, dann schützen und priorisieren, dann neu aufbauen. Marke, Texte, Design, Technik, Suchsignale und Anfragewege werden nicht in getrennten Silos betrachtet, weil Besucher am Ende nur eine Website erleben.

Wenn dein Vorhaben diese Tiefe braucht, findest du unseren konkreten Ansatz unter Website-Relaunch. Wenn ein gezieltes Update reicht, ist ein kleinerer Eingriff die bessere Entscheidung.

Die Master-Checkliste

Vor der Beauftragung

• Ziel, Ausgangswert und Relaunch-Auslöser dokumentiert
• Projektart und Eingriffstiefe gewählt
• nicht verhandelbare Werte und grosse Risiken benannt
• interne Verantwortungen und Go/No-Go-Rolle geklärt
• Scope für Inhalt, Design, Technik, Migration und danach verglichen

Vor dem Design

• vollständige URL-, Inhalts-, Funktions- und Zugangs-Inventur erstellt
• Schützen / Verbessern / Entfernen / Neu entschieden
• Zielstruktur und wichtigste Nutzerwege freigegeben
• Inhaltsverantwortung und reale Liefertermine geklärt
• CMS, Datenmodell und Migrationsweg entschieden
• Ausgangscrawl und Suchdaten gesichert

Vor dem Launch

• Inhalte, Design, responsive Zustände und Funktionen abgenommen
• Barrierefreiheit und Performance geprüft
• URL-Mapping und Redirects vollständig getestet
• Canonical, Robots, Noindex, Sitemap und strukturierte Daten geprüft
• Formulare und Integrationen mit echten Fällen getestet
• Analytics, Search Console und Consent kontrolliert
• Backup, Rollback, Runbook und Verantwortungen bestätigt

Nach dem Launch

• wichtigste Seiten, Statuscodes und Formulare sofort geprüft
• Crawl-Vergleich und Redirect-Test durchgeführt
• Sitemap eingereicht und Indexierung beobachtet
• 404s, Ketten und interne alte Links bereinigt
• Anfragen und Nutzerfeedback gesammelt
• 30-Tage-Auswertung terminiert
• Weiterentwicklung aus Diagnose statt Nervosität priorisiert

Kurz gesagt

Ein Website-Relaunch ist erfolgreich, wenn der neue Auftritt nicht nur moderner aussieht, sondern die richtigen Werte übernimmt, bekannte Risiken kontrolliert und seine Aufgabe nach dem Launch besser erfüllt.

Dafür brauchst du keine möglichst lange Checkliste. Du brauchst Entscheidungen in der richtigen Reihenfolge, klare Verantwortungen und Belege dafür, dass die kritischen Wege funktionieren.

Erst schützen. Dann verändern. Dann kontrollieren. Genau so wird aus einem riskanten Neustart ein planbarer Umbau.