Website-Relaunch-Projektplan: acht Phasen, damit der Launch-Tag langweilig wird

Was ein Projektplan leisten muss

Ein Projektplan für den Website-Relaunch legt fest, in welcher Reihenfolge gearbeitet wird, wer was entscheidet, welches Ergebnis jede Phase liefert und woran du erkennst, dass sie fertig ist. Ein Balkendiagramm für die Schublade ist er nicht. Er ist die Liste der Entscheidungen, die fallen müssen, und der Termine, an denen sie fallen.

Ich leite solche Relaunches selbst, 2026 fast immer mit meiner Crew bei clickpuls. Drei davon gingen im August und September live, bei zweien kamen auch Konzept und Design von mir. Die acht Phasen unten stammen aus diesen Projekten, die Zahlen auch. Kunden nenne ich nicht beim Namen, die Zahlen stimmen trotzdem. Willst du den Plan nicht selbst tragen, übernehme ich das: Wie ich einen Relaunch leite.

Die acht Phasen

Jede Phase endet mit einem Ergebnis, das man anfassen kann: einem Dokument, einem Prototyp, einer Liste. Was kein Ergebnis hat, hat auch kein Ende.

1. Messen und Ziel festlegen

   Bevor jemand über Farben spricht, wird gemessen: Crawl der alten Seite, Daten aus der Search Console, Ladezeit, Barrierefreiheit, Indexierung. Daraus entsteht ein Basiswert, gegen den du nach dem Launch vergleichst. Dann folgen ein Ziel mit einer Leitmessgröße und eine Liste der Nicht-Ziele. Fehlt das Ziel noch ganz, ist das eine eigene Etappe: Strategie und Konzept.

   Eine Messung, die niemand hören wollte: Bei einem medizinischen Institut stand die Startseite auf allen 4 Adressvarianten auf „noindex“, war für Google also unsichtbar, und 21 von 22 Seiten hatten keine Meta-Beschreibung. Im Haus hatte es niemand bemerkt. Mein Kurz-Audit lag 18 Tage vor dem ersten Termin vor. So etwas gehört in den Plan, bevor ein neues Design es zudeckt.

2. Fragen klären und Zuständigkeiten verteilen

   Jetzt kommt ein Fragenkatalog, und zwar nur mit Fragen, die allein du beantworten kannst. Was ein Crawl beantwortet, frage ich nicht. Meine Kataloge hatten zwischen 10 und 152 Fragen. Den großen habe ich in 10 Blöcke nach Zuständigkeit geschnitten, damit Geschäftsleitung, IT und Marketing parallel antworten konnten. Am Ende dieser Phase steht fest, wer Inhalte liefert, wer freigibt und wer erreichbar ist, wenn es klemmt. Fehlt einer dieser Namen, wackelt genau dort der erste Termin.

3. Struktur, Inhalte und Weiterleitungsplan

   Sitemap, Informationsarchitektur und Inhaltsmodell entstehen in dieser Phase, und mit ihnen der Weiterleitungsplan. Jede alte Adresse kommt aus echten Daten auf eine Liste und bekommt ein Ziel. Wer das bis zum Launch-Tag aufschiebt, plant den Verlust in den Suchergebnissen gleich mit.

   Beim Umzug eines Industrie-Distributors auf eine internationale Domain liefen Domain- und Technikwechsel in zwei getrennten Stufen, damit sich Schwankungen in den Suchergebnissen einer Ursache zuordnen lassen. Mein Kernsatz dazu: „Jede vermeidbare Adressänderung ist ein vermeidbares Risiko.“

4. Prototyp und Design

   Das Design verantworte ich in den meisten Fällen selbst, und du klickst dich durch die echte Seite, nicht durch ein Bild davon. Bei einem Hersteller stand der erste Prototyp mit 10 Seiten und Konfigurator an einem Tag.

   Barrierefreiheit beginnt hier und nicht erst bei den Tests. Kontrast, Schriftgröße, Fokus und Bewegung legt das Designsystem fest. Beim Hersteller waren alle Farbpaare der Kundenpalette schon im Prototyp nach WCAG AA geprüft. Beim Skiverleih galt WCAG 2.2 AA als Vorgabe für die ganze Seite, mit 17 px Basisschrift, Skip-Links, sichtbarem Fokus und Rücksicht auf die Systemeinstellung „weniger Bewegung“. Eine Schriftfarbe, die ein Teil deiner Besucher nicht lesen kann, ist im Designsystem eine Zeile. Nach dem Launch ist sie ein Umbau. Wie ich das angehe, steht unter Barrierefreie Website.

   Plan die Feedback-Runden mit ein. Bei einem anderen Projekt entstanden 52 Startseiten-Entwürfe in 15 Runden. Das kann richtig sein. Es gehört nur in den Zeitplan und nicht in die Spalte für Überraschungen.

5. Umsetzung und Inhalte

   Gebaut wird in kurzen Etappen auf einer Testumgebung, die für Suchmaschinen gesperrt ist. Freigaben bekommen bei mir eine Frist von 48 Stunden, und jede Entscheidung landet mit Nummer im Entscheidungslog. Die Frist ist unbeliebt. Sie ist trotzdem billiger als jede Woche, in der eine Freigabe in einem Postfach liegt.

   Inhalte liegen in einer eigenen Schicht, getrennt vom Layout. Für ein Technikdetail hält das jeder, bis sich eine Woche vor dem Launch die Modellpalette ändert. Weiter unten steht, wie das ausging.

   Die Umsetzung übernimmt bei mir die Crew aus dem clickpuls-Netzwerk: ein Kernteam von 4 Personen und über 15 Spezialisten. Was clickpuls in der Webentwicklung (externer Link) baut, steht dort. Ich bleibe dein Ansprechpartner, auch wenn andere programmieren, und oft programmiere ich mit: Beim Hersteller kamen 60 von 70 Commits von mir.

6. Tests und Weiterleitungen

   Getestet wird mit Zahlen, nicht mit Gefühl: jede alte Adresse, jede Bildschirmbreite, Formulare, Tracking, Barrierefreiheit nach WCAG 2.2 AA, Ladezeit. Beim Hersteller lief ein Responsive-Audit mit 90 Kombinationen, Ergebnis 0 px horizontaler Überlauf, und im Labortest von Lighthouse stand die Barrierefreiheit bei 98. Ein automatischer Test findet aber nur einen Teil der Hürden. Ob sich ein Formular mit der Tastatur ausfüllen lässt, merkst du erst, wenn du es tust.

7. Go-live

   Für den Launch-Tag gibt es ein Runbook: Schritte in Reihenfolge, Zuständige, Prüfpunkte und einen Rückweg (das ist der Teil, den alle für übertrieben halten, bis sie ihn brauchen). Die alte Installation bleibt als Rückfallebene stehen, umgeschaltet wird zu einer Zeit mit wenig Besuch. Für die DNS-Umstellung bekommt die Kundenseite eine Anleitung, die mit dem Satz beginnt: „Technisches Wissen ist nicht nötig.“

   Wie das aussieht, wenn man ihn braucht: Beim Distributor war am Go-live-Tag die Ein-Klick-Funktion des Hosters unbrauchbar, und die neue Domain war wegen eines DNS-Fehlers seit 19 Tagen nicht erreichbar. Das fällt am Go-live-Tag auf, wenn man nachschaut. Statt eines Klicks wurde es eine Komplettmigration, am selben Tag.

8. Nach dem Launch: Monitoring, Selbstprüfung, Übergabe

   Nach dem Go-live wird beobachtet, nicht gefeiert. Beim Distributor laufen 12 Wochen Monitoring, und bis dahin gibt es keine Wirkungszahlen. Ich erfinde auch keine. Dazu gehört eine Selbstprüfung: Ich prüfe meine eigene Arbeit und halte fest, was noch fehlt. Beim Hersteller lag 17 Tage nach dem Go-live ein Dokument mit 15 Ampelbereichen und 25 Tickets vor, Kernsatz: „Die Technik ist fertig, ab jetzt entscheidet der Inhalt.“

   Zur Übergabe gehören Dokumentation, eine aufgezeichnete Schulung und offene Punkte mit Namen. Code, Daten und Doku gehören dir.

Vorlage: der Plan als Tabelle

Kopier dir die Tabelle in eine Tabellenkalkulation und ergänze zwei Spalten: Termin und Name. Ein Plan ohne Namen ist eine Wunschliste.

Checkliste für den Launch-Tag

• Weiterleitungen: Jede alte Adresse hat genau ein Ziel. Nichts landet pauschal auf der Startseite.
• Ziele: Alle Zieladressen antworten mit Status 200.
• Indexierung: Die Sperre der Testumgebung ist auf der neuen Seite entfernt, robots.txt und Sitemap stimmen.
• Zertifikat: HTTPS läuft auf allen Adressvarianten.
• Search Console: Die neue Sitemap ist eingereicht, bei einem Domainwechsel ist die Adressänderung gemeldet.
• Formulare: Jedes Formular wurde einmal echt abgeschickt, und die Mail ist angekommen.
• Bedienbarkeit: Navigation und Formulare funktionieren auf der Live-Seite mit der Tastatur, der Fokus ist sichtbar.
• Tracking und Einwilligung: Die Messung läuft, und zwar nur dort, wo sie darf.
• Rückweg: Die alte Installation ist für den Notfall erreichbar, die Schritte zurück sind aufgeschrieben.
• Basiswert: Die Zahlen von vorher sind gesichert. Sonst gibt es nachher nichts zu vergleichen.
• Testumgebung: Nach dem Launch ist sie gesperrt oder abgeschaltet.

Beim Distributor sah das Ergebnis dieser Liste so aus:

481 von 481

alten Adressen mit genau einer Weiterleitung

319 von 319

Endzielen mit Status 200, dazu 168 von 168 festen Zielen

392

Seiten nach dem Go-live nachgeprüft

Woran Relaunch-Pläne kippen

Fast alle Arten, wie ein Projekt gegen die Wand fährt, sieht man früh kommen, wenn jemand hinschaut. Diese sechs begegnen mir immer wieder, und an fehlender Technik liegt keine davon:

• Das Ziel kommt nach dem Design. Dann wird über Geschmack gestritten statt über Wirkung. Ohne Ziel gibt es kein Nachschärfen, sondern nur Meinungen, und jede Feedbackrunde bringt neue mit.
• Die Inhalte kommen zum Schluss. Texte, Bilder und Produktdaten brauchen fast immer mehr Zeit als der Code. Plane sie ab Phase 3, mit Namen und Termin.
• Die Weiterleitungen kommen am Launch-Tag. Wer die alten Adressen erst dann zählt, findet sie später in der Search Console wieder, als Fehler.
• Die Barrierefreiheit kommt als Nachtrag. Dann prüft jemand nach dem Launch die Kontraste und findet das Problem im Designsystem, also auf jeder Seite. Was im Entwurf eine Zeile gewesen wäre, ist jetzt ein Umbau.
• Der Kurswechsel kommt nach der Freigabe. Passiert. Bei einem Skiverleih wollte die Leitung nach Preview und Freigabe eine neue, emotionalere Richtung. Das ging ohne Verlust, weil Inhalte und Preislogik übernommen werden konnten und nur Design und Technik neu entstanden. 4 Tage später stand das neue Designsystem, Suchmaschinen-Grundlagen, Preise und Tracking blieben erhalten. Wie schnell es danach ging, steht unter Projekte.
• Mehr Leute sollen Zeit ersetzen. Geld kauft parallele Kapazität, aber keine Kalenderwochen. Wer neu dazukommt, braucht zuerst Zeit von denen, die schon drin sind. Wenn der Termin wackelt, hilft ein kleinerer Umfang früher als ein größeres Team.

Was ein guter Plan nicht verspricht

Ein Projektplan sagt, was bis wann fertig ist. Er sagt nicht, um wie viel Prozent die Anfragen steigen. Wer nach einem Relaunch Steigerungsraten zusagt, sagt etwas zu, das er nicht kontrolliert, und verkauft eine Schätzung als Messwert. Was du von mir bekommst, ist ein Basiswert vor dem Launch und eine ehrliche Messung danach.

Willst du den Plan mit jemandem durchgehen, der ihn schon bis zum Launch-Tag getragen hat: Hier steht, wie ich Relaunches leite, und unter Projekte stehen die drei aus dem August und September ausführlich. Suchst du erst die richtige Person, hilft der Ratgeber Externen Projektleiter finden.

Relaunch-Plan mit mir durchgehen