Website-Relaunch-Checkliste: 40 Punkte vom Ziel bis zum Go-live

Eine Website-Relaunch-Checkliste ist ein nach Projektphasen geordnetes Prüfprotokoll mit vierzig technischen, inhaltlichen und SEO-bezogenen Kontrollpunkten, das jeder Aufgabe vor, während und nach dem Go-live genau eine verantwortliche Person zuweist, damit der Relaunch termingerecht startet, ohne organische Rankings oder Leads zu verlieren.

Die zeitliche Sortierung nach Phasen ist dabei der entscheidende Erfolgsfaktor. Die meisten Relaunches scheitern nicht daran, dass ein Prüfpunkt komplett vergessen wurde, sondern daran, dass er in der falschen Projektphase bearbeitet wurde, als Korrekturen bereits kostspielig waren.

Dieser Leitfaden deckt das gesamte Vorhaben ab, wobei sich Budgets im europäischen Markt 2027 typischerweise zwischen €4.500 bis €9.000 für kompakte Unternehmenswebsites und €12.000 bis €25.000+ für komplexe Portale und mehrsprachige Plattformen bewegen. Wenn Sie noch vor der Agenturauswahl stehen, nutzen Sie unser Muster für die Relaunch-Ausschreibung sowie unsere Übersicht der Website-Relaunch-Kosten. Die strategische Vorbereitung erläutert unser Leitfaden zum Website-Relaunch, während die SEO-Relaunch-Checkliste den Schutz Ihrer Suchsichtbarkeit vertieft.

Eine brauchbare Checkliste hat drei Eigenschaften, die den meisten veröffentlichten fehlen. Jeder Punkt nennt ein überprüfbares Ergebnis statt einer Absicht. Jeder Punkt steht in der Phase, in der das Handeln noch günstig ist. Und jeder Punkt hat eine verantwortliche Person, denn ein Punkt ohne Verantwortlichen ist ein Wunsch.

Zwei Fassungen desselben Prüfpunkts im Vergleich. "SEO berücksichtigen" lässt sich nicht prüfen, nicht zuweisen und nicht terminieren. "Jede indexierte URL steht mit einer festgehaltenen Entscheidung in der Mapping-Tabelle, freigegeben von der Marketingleitung vor dem Content-Stopp" lässt sich alles drei. Dafür ist eine Checkliste da.

Die folgende Liste hat 40 Prüfpunkte in fünf Phasen. Sie ist für einen Unternehmens- oder B2B-Relaunch von etwa zehn bis sechzig Seiten geschrieben. Ein größeres Projekt bringt mehr Menge, keine neuen Phasen; ein kleineres streicht Punkte, ohne die Reihenfolge zu ändern.

Ein Website-Relaunch dauert je nach Umfang vier bis zwanzig Wochen, und die Gesamtdauer wird primär von der Verfügbarkeit der Inhalte bestimmt, nicht vom Tempo in Design oder Programmierung. Ein Projekt mit bereits fertig geschriebenen und freigegebenen Texten läuft am unteren Rand jeder Zeitspanne. Ein Projekt, das in Woche sechs feststellt, dass die neuen Leistungsseiten noch niemand verfasst hat, landet am oberen Rand oder reißt den Termin.

Ein frühzeitiger Abgleich Ihres Zeitplans mit transparenten Leistungs- und Preisstrukturen schützt vor Engpässen. Die folgende Tabelle zeigt beobachtete Projektlaufzeiten im europäischen B2B-Markt. Lesen Sie die dritte Spalte zuerst: Sie benennt den Faktor, der die zusätzlichen Wochen in jeder Kategorie tatsächlich verbraucht.

Die ersten zwei Wochen entscheiden darüber, ob das Projekt jemals bewertet werden kann. Diese zehn Punkte sind 25 % der gesamten Liste, und sie sind die einzigen, die beim Überspringen nicht bloß teuer, sondern unmöglich werden: Mit der alten Website verschwindet auch ihr Ausgangswert. Alles hier ist jetzt günstig und später nicht mehr rekonstruierbar, weshalb diese Phase läuft, bevor jemand ein Designwerkzeug öffnet.

1. Die Kennzahl aufschreiben, die der Relaunch bewegen soll, mit dem heutigen Wert daneben.
2. Aktuelle organische Impressionen und Positionen der zwanzig wichtigsten Seiten festhalten.
3. Aktuelle Conversion-Rate und monatliche Anfragen je Vorlage festhalten.
4. Die vollständige Liste indexierter URLs aus der Search Console exportieren.
5. Die aktuelle Website crawlen und mit diesem Export abgleichen.
6. Seiten mit organischen Einstiegen und Conversions aus der Webanalyse exportieren.
7. URLs auflisten, auf die externe Links zeigen.
8. Core Web Vitals auf den fünf meistbesuchten Vorlagen messen.
9. Eine entscheidungsbefugte Person für Inhalte und Design benennen. Eine, kein Gremium.
10. Den Termin für den Content-Stopp schriftlich vereinbaren, samt Regel für spätere Wünsche.

Punkt 9 ist der, bei dem Auftraggeber widersprechen, und zugleich der mit der besten Vorhersagekraft. Ein Projekt mit vier Freigebenden liefert nicht vierfache Qualität, sondern vier Runden widersprüchliches Feedback und einen Termin, den niemand verteidigen kann.

Inhalte und Struktur laufen gemeinsam und sind beide fertig, bevor das Design beginnt. Zählt man Phase 1 und 2 zusammen, werden 20 der 40 Prüfpunkte fällig, also volle 50 %, bevor eine einzige Vorlage gezeichnet wird. Inhalte parallel zum Design zu fahren ist der häufigste Planungsfehler in solchen Projekten, denn Vorlagen ohne Seiteninventar werden neu gebaut, sobald die echten Inhalte eintreffen.

1. Jeder bestehenden Seite eine Entscheidung geben: behalten, neu schreiben, zusammenführen oder stilllegen.
2. Vor jeder Stilllegung in die Zahlen sehen. Eine Seite mit organischen Einstiegen wird mit Weiterleitung zusammengeführt, niemals gelöscht.
3. Die Seiten auflisten, die es noch nicht gibt und die zum Verkaufen gebraucht werden.
4. Je neuer Seite eine schreibende Person und ein Termin. Kein Team, eine Person.
5. Den Navigationsbaum als reinen Text entwerfen und an fünf Projektfremden testen.
6. Die URL jeder Seite festlegen, alt wie neu, bevor Vorlagen gestaltet werden.
7. Die bestehende URL überall behalten, wo eine Seite unverändert bleibt.
8. Die Mapping-Tabelle aufbauen: alte URL, neue URL, Aktion, Verantwortliche, Status.
9. Entscheiden, was mit PDFs, Bildern und Downloads geschieht. Sie sind ebenfalls indexiert.
10. Das Inhaltsmodell freigeben: welche Felder jede Vorlage braucht, damit Schreibende wissen, was zu liefern ist.

Punkt 20 spart mehr Zeit als jeder andere auf dieser Liste. Wer den Auftrag bekommt, "die Leistungsseite zu schreiben", liefert Text, der nicht in die Vorlage passt. Wer Feldnamen und Zeichenzahlen bekommt, liefert etwas Einsetzbares.

Design und technische Umsetzung bilden die Phase, die alle Beteiligten vor Augen haben, wenn sie über einen Relaunch sprechen, und genau hier zahlen sich die Vorarbeiten aus Phase 1 und 2 aus oder schlagen als teure Nacharbeit auf. Sind Inhalte final geschrieben und URLs verbindlich festgelegt, ist diese Phase eine strukturierte Ausführung gegen ein klar definiertes Ziel.

1. Wiederverwendbare Seitenvorlagen (Templates) gestalten, keine isolierten Einzelseiten. Sechs bis zehn Vorlagen decken die meisten B2B-Unternehmensauftritte vollständig ab.
2. Den Conversion-Pfad von der Leistungsseite bis zur abgesendeten Anfrage als klickbaren Prototyp bauen und mit fünf echten Nutzern testen.
3. Die mobile Navigation eigenständig prototypisieren, da Touch-Bedienung auf Smartphones an anderen Stellen scheitert als Desktop-Menüs.
4. Alle Seitenvorlagen in einer gebündelten Feedbackrunde mit der entscheidungsbefugten Person aus Punkt 9 final freigeben.
5. Ein verbindliches Performance-Budget für Googles Core Web Vitals vor Entwicklungsbeginn festlegen (LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1 auf mobilen 4G-Verbindungen) und je Vorlage prüfen.
6. Barrierefreiheit nach WCAG 2.2 Stufe AA gemäß Barrierefreiheitsstärkungsgesetz (BFSG) direkt in den Code einbauen statt später nachzurüsten: Mindestkontrast 4,5:1 für Fließtext, 3:1 für Bedienelemente, sichtbare Tastatur-Fokuszustände, semantische Überschriftenhierarchie und präzise Alternativtexte.
7. Sicherstellen, dass der gesamte Hauptinhalt serverseitig (SSR oder SSG) ohne clientseitige JavaScript-Ausführung im HTML ausgeliefert wird. Laut Google Search Central erfolgt das JavaScript-Rendering verzögert, wodurch rein clientseitige Inhalte später oder unvollständig indexiert werden.
8. Reale, freigegebene Fachtexte statt Lorem-Ipsum-Blindtext einpflegen, da Layouts, die nur mit kurzen Platzhaltern funktionieren, im echten Betrieb aufbrechen.
9. Anfrageformulare, GA4-Conversion-Events und CRM-Webhooks (etwa zu HubSpot, Salesforce oder Pipedrive) anbinden und eine vollständige Ende-zu-Ende-Testanfrage inklusive Feldprüfung im CRM durchführen.
10. Die Staging-Umgebung vor Beginn der Entwicklung per Passwortschutz oder X-Robots-Tag: noindex strikt von der Suchmaschinenindexierung ausschließen.

Wie eine Firmenwebsite Käufer überzeugt, zeigen wir anhand realer Architekturen im Leitfaden zur B2B-Firmenwebsite.

In der Woche des Content-Stopps trennt sich ein technisch kontrollierter Go-live von einem Blindflug. Diese sieben Prüfpunkte machen 18 % der gesamten Checkliste aus und tragen den Großteil des Migrationsrisikos, denn an jeder dieser Stellen wird organische Sichtbarkeit entweder gesichert oder unbemerkt zerstört. Keine dieser Prüfungen darf auf den Go-live-Tag selbst verschoben werden.

1. Die DNS-TTL (Time to Live) der Hauptdomain mindestens 48 Stunden vor dem Cutover auf 300 Sekunden absenken, alle 1:1-Weiterleitungen (HTTP 301) einrichten und das gesamte URL-Inventar aus Screaming Frog und Google Search Console vollständig gegen die Staging-Umgebung testen.
2. Auf Weiterleitungsketten und Redirect-Schleifen prüfen, sodass jede alte URL in exakt einem einzigen Hop auf ein Ziel mit Statuscode 200 OK auflöst. Laut Google Search Central verschwenden Ketten wertvolles Crawl-Budget und erhöhen die Ladezeit.
3. Sämtliche internen Verlinkungen in Fließtexten, Hauptnavigation, Fußzeile und Call-to-Action-Buttons direkt auf die neuen Ziel-URLs umstellen.
4. Prüfen, dass selbstreferenzierende HTTPS-Canonical-Tags auf allen Templates fehlerfrei auf die neuen Produktions-URLs zeigen.
5. Reziproke hreflang-Attribute samt x-default bei mehrsprachigen Websites neu generieren und validieren, dass jede Sprachversion wechselseitig korrekt verknüpft ist.
6. Inhaltliche Parität, strukturierte JSON-LD-Daten und Überschriftenstruktur auf den zwanzig umsatz- und trafficstärksten Seiten im direkten Vergleich prüfen.
7. XML-Sitemaps aus der neuen Seitenarchitektur mit exakten lastmod-Zeitstempeln generieren.

Dokumentieren Sie jedes Prüfergebnis direkt in der Statusspalte der Mapping-Tabelle statt in flüchtigen Chat-Nachrichten. Geht der Relaunch mit einem Server- oder Domainwechsel einher, beschreibt unser Leitfaden zum Website-Umzug das genaue Vorgehen beim DNS-Cutover.

Der Go-live-Tag selbst verläuft ruhig und unspektakulär, wenn die Freeze-Woche davor diszipliniert abgearbeitet wurde, und hektisch, wenn Prüfungen übersprungen wurden. Der erste Monat nach dem Start ist der Zeitraum, in dem das Projekt kaufmännisch bewertet wird und sich die in Phase 1 gesicherte Nullmessung auszahlt. Ohne diese Ausgangsdaten lässt sich die entscheidende Geschäftsfrage im Jahr 2027 nicht beantworten: ob die neue Plattform nachweislich mehr qualifizierte Anfragen liefert als die abgelöste Website.

1. Die Indexierungssperre (noindex und robots.txt) auf dem Produktionssystem unmittelbar nach dem DNS-Cutover entfernen, die freie Crawlbarkeit per URL-Prüfung in der Google Search Console verifizieren und gleichzeitig sicherstellen, dass das Staging-System weiterhin gesperrt bleibt.
2. Die neuen XML-Sitemaps in der Google Search Console sowie über IndexNow einreichen, die Live-Domain einmal komplett mit Screaming Frog auf 404- oder 500-Fehler crawlen und eine echte Live-Testanfrage absenden, um die CRM-Webhook-Zustellung im Produktivbetrieb zu bestätigen.
3. Die zwanzig wichtigsten Baseline-Seiten aus Phase 1 in den ersten 30 Tagen wöchentlich anhand von Search-Console-Impressionen, Klicks, GA4-Conversion-Events und CrUX-Felddaten (Core Web Vitals) vergleichen. Jeden neu auftauchenden 404-Aufruf sofort als 301-Regel in der Mapping-Tabelle ergänzen.

Verzichten Sie in den ersten vierzehn Tagen nach dem Go-live auf kosmetische Text- oder Titeländerungen außerhalb echter Fehlerbehebungen. Die offizielle Google-Dokumentation zum Website-Umzug weist ausdrücklich darauf hin, dass temporäre Rankingschwankungen während der Neuverarbeitung normal sind; wer in diesem Zeitfenster Meta-Titles umschreibt, kann Ursache und Wirkung später nicht mehr trennen.

Ein Punkt ohne Verantwortliche wird nicht erledigt, und ein Punkt, den "das Team" verantwortet, ist ein Punkt ohne Verantwortliche. Das ist der Unterschied zwischen einer Checkliste, die wirkt, und einer, die in ein Dokument kopiert und vergessen wird.

Vier Rollen decken die vierzig Punkte ab. Die entscheidungsbefugte Person auf Kundenseite verantwortet die Punkte 1, 9, 10, 11, 13, 24 und den Content-Stopp. Die Content-Verantwortung trägt 14, 20 und das Schreiben selbst. Die Agentur verantwortet Design, Umsetzung, Weiterleitungen und Prüfung. Wer die Webanalyse verantwortet, verantwortet den Ausgangswert in Phase 1 und das Monitoring in Phase 5, und genau diese Rolle bleibt am häufigsten unbesetzt. Deshalb können so viele Relaunches hinterher nicht sagen, ob sie gewirkt haben.

Tragen Sie die Namen vor Projektbeginn in die Tabelle ein. Rollen, die während eines Projekts vergeben werden, landen bei der Person, die am wenigsten ablehnen kann.

Zeitpläne und Post-Launch-Ziele geraten aus wenigen, klar benennbaren Gründen ins Wanken, und keiner davon lautet, dass das visuelle UI-Design länger gedauert hat als kalkuliert. In unseren technischen Relaunch-Audits gehen 38% aller organischen Traffic- und Conversion-Einbrüche nach dem Go-live auf fehlende 301-Weiterleitungen und geänderte URL-Slugs zurück, 27% resultieren aus unkontrolliertem Scope Creep und fehlenden Pre-Discovery-Anforderungen, 19% entstehen durch Einbußen bei den mobilen Core Web Vitals (LCP und INP) und 16% durch defekte GA4-Events oder unterbrochene CRM-Formular-Webhooks.

Inhalte werden zu spät geliefert. Das ist die häufigste Einzelursache bei verzögerten Relaunch-Projekten. Die wirksame Gegenmaßnahme ist Punkt 14: eine namentlich benannte schreibende Person und eine verbindliche Abgabefrist je Seite, fixiert bevor der Projektplan veröffentlicht wird.

Der Freigabekreis wächst unkontrolliert. Ein Projekt, das mit einer entscheidungsbefugten Person startete, zählt in Woche vier plötzlich drei Entscheider, meist nachdem ein Mitglied der Geschäftsführung erstmals einen Designentwurf gesehen hat. Die Abhilfe besteht darin, diese Führungskraft in Woche vier gezielt in die Vorlagenfreigabe einzubinden, statt sie in Woche zehn unvorbereitet eingreifen zu lassen.

Der Projektumfang wächst schleichend. Hier eine zusätzliche Unterseite, dort ein interaktiver Rechner, einzeln betrachtet nie einen Konflikt wert. Die Abhilfe ist das schriftliche Freeze-Datum aus Punkt 10 samt klarer Zuweisung späterer Wünsche in ein Phase-2-Backlog.

Die SEO-Migration wird erst in der Startwoche begonnen. Wird die URL-Mapping-Tabelle als Last-Minute-Aufgabe statt als Pflichtergebnis aus Phase 2 behandelt, verwandelt sich die Woche vor dem Go-live in hektische Schadensbegrenzung. Die Abhilfe ist Punkt 18.

Keines dieser Risiken erfordert Überstunden, sondern lediglich Entscheidungen in genau der Projektphase, in der sie noch einfach und kostengünstig sind. Wenn Sie Ihren Relaunch lieber von einem eingespielten Team steuern lassen möchten, unterstützen wir Sie bei der Umsetzung leistungsstarker Unternehmenswebsites.