Website-Relaunch geplant? Worauf du vor, während und nach dem Go-live achten musst

Bei einem Relaunch geht es meistens um das neue Design. Die meisten Probleme kommen aber woanders her: Vor dem Umbau wurde nicht festgehalten, wie die alte Website abschneidet. In der Abstimmungsphase landet Feedback verstreut in E-Mails, Chats und Screenshot-PDFs. Die Barrierefreiheit wird erst am Ende geprüft. Und nach dem Go-live fehlen die Vergleichswerte. Teams, die gut relaunchen, sichern deshalb zuerst ihre Messwerte und Conversions, sammeln Feedback direkt auf der Website, prüfen die neuen Templates vor dem Go-live und überwachen die neue Website ab dem ersten Tag.

Das Wichtigste in Kürze

• Miss vor dem Relaunch: Ohne Messwerte und Conversions der alten Website gibt es später keinen Vorher-Nachher-Vergleich.

• Sammle Feedback am Element, nicht per E-Mail: Kommentare direkt auf der Website mit automatischem Screenshot sparen Rückfragen und lassen sich zuweisen.

• Prüf die Templates vor dem Go-live: Ein automatischer Check findet offensichtliche Fehler, ersetzt aber kein manuelles Audit.

• Vergleiche nach dem Go-live Conversions, nicht nur Klicks: Entscheidend ist, ob die neue Website mehr Anfragen oder Käufe bringt.

• Überwache dauerhaft: Deployments und neue Inhalte können jederzeit neue Barrieren einbauen.

Vor dem Relaunch: die Messlatte festlegen

Dein wichtigster Schritt kommt, bevor irgendjemand ein neues Template baut: Halte fest, wie die alte Website funktioniert. Später vergleicht jemand „vorher“ und „nachher“, und dann brauchst du belastbare Zahlen statt Erinnerungen.

Dafür bindest du unser Code-Snippet im HTML-Head der bestehenden Website ein. Ab dann erfassen unsere Metriken Seitenaufrufe, Absprungrate, Gerätenutzung und mehr, und zwar cookiefrei und in der EU gehostet. Die Live-Klick-Heatmaps zeigen, wo Besucher*innen klicken und wie weit sie scrollen. Die User Flows zeigen die häufigsten Pfade durch die Website und die Stellen, an denen Nutzer*innen abspringen.

Seitenaufrufe allein sagen aber wenig darüber, ob eine Website ihren Zweck erfüllt. Lege deshalb schon auf der alten Website Ziele an: Käufe, Anmeldungen, Leads, Formular-Absendungen oder Klicks auf zentrale Buttons. Buttons und Formulare wählst du dafür visuell aus, ganz ohne Entwicklung. sitebrunch zeigt dir dann Conversion-Rate, Anzahl und Wert pro Ziel und welche Kanäle die Conversions bringen. Genau diese Zahlen willst du nach dem Launch wiedersehen.

Ein Tipp aus der Praxis: Lass das Tracking mehrere Wochen vor dem Launch laufen. Bekommen wichtige Seiten wie Produktseite, Kontaktformular oder Checkout neue Adressen, erstelle schon jetzt eine Liste, welche alte URL zu welcher neuen gehört. Ohne diese Liste kannst du später Seiten nicht einzeln vergleichen.

Genauso sinnvoll ist eine Ausgangslage für die Barrierefreiheit. Unser kostenloser Barrierefreiheits-Check prüft eine einzelne Seite in wenigen Sekunden mit über 80 automatisierten WCAG-Tests auf Basis von Axe-core und gibt ihr einen Score von 0 bis 100 Prozent. So erkennst du, welche Fehler die alte Website immer wieder macht, damit sie im neuen Design nicht wieder auftauchen.

Während des Relaunchs: Feedback direkt auf der Website sammeln

Sobald die ersten Seiten der neuen Website stehen, beginnt die Abstimmung. Und die ist bei vielen Relaunches der größte Zeitfresser: Die Geschäftsführung schickt eine E-Mail, das Marketing einen Screenshot mit roten Pfeilen, der Vertrieb eine Nachricht im Chat. Wer welche Stelle meint und ob etwas schon erledigt ist, weiß am Ende niemand mehr genau.

Mit unserer Kommentarfunktion hinterlässt dein Team Feedback direkt an dem Element auf der Website, um das es geht:

1. Kommentar setzen. In der sitebrunch Browser-Extension wechselst du mit der Taste C in den Kommentarmodus und klickst auf die Stelle, die du meinst.

2. Screenshot kommt automatisch. Zu jedem Kommentar erstellt sitebrunch einen Screenshot mit Zeitstempel. So ist auch später klar, wie die Seite zu diesem Zeitpunkt aussah.

3. Aufgabe zuweisen. Du markierst die zuständige Person, sie wird per E-Mail benachrichtigt. Auf Wunsch wird aus dem Kommentar direkt eine Aufgabe in awork.

4. Mit KI umsetzen. Über den MCP Server gibst du Kommentare an KI-Coding-Assistenten wie Claude Code oder OpenAI Codex weiter. Weil der Kommentar am Element hängt, findet der Assistent die richtige Stelle im Code.

In der Kommentar-Ansicht der Extension siehst du alle Kommentare zu einer Seite an einem Ort, deine eigenen und die deines Teams. Die Kommentarfunktion ist in allen Plänen enthalten, auch im Free-Plan.

Barrierefreiheit: vor dem Go-live prüfen

Ein Relaunch ist der günstigste Moment für Barrierefreiheit. Was du jetzt in die Templates einbaust, musst du später nicht auf hunderten Seiten nachbessern. Automatisierte Tests decken aber nur einen Teil ab. Ob man die Website mit Tastatur oder Screenreader bedienen kann, zeigt nur eine manuelle Prüfung. Plane deshalb vor dem Go-live Zeit für ein Audit nach EN 301 549 und WCAG 2.2 ein.

1. Kick-off Audit für die wichtigsten Templates. Das ist ein verkürztes Audit mit den wichtigsten Prüfschritten. Nach etwa einem Personentag weißt du, wo die neue Website steht. Prüfe zuerst die Seiten, die viele andere Seiten tragen: Startseite, Produktseite, Formular, Checkout.

2. Komplettes Audit, wenn du die Anforderungen nachweisen musst. Es umfasst alle 96 Prüfschritte der EN 301 549 und WCAG 2.2.

3. Befunde in Tickets verwandeln. Du exportierst Befunde nach Jira, Notion oder Asana, oder lässt technische Befunde über den MCP Server direkt im Code beheben.

4. Re-Audit nach den Korrekturen. Das Re-Audit übernimmt alle bisherigen Befunde. Du hakst ab, was behoben ist.

Für viele Unternehmen ist das keine Kür. Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 für bestimmte Dienstleistungen für Verbraucher*innen, etwa Onlineshops und Bankdienstleistungen. Für einen Relaunch wichtig: Inhalte, die nach diesem Datum überarbeitet werden, fallen nicht mehr unter die Archiv-Ausnahme aus § 1 Absatz 4 Nummer 5 BFSG. Was du in das neue System übernimmst und dabei anpasst, muss also die Anforderungen erfüllen.

Ein häufiger Fehler ist, das Audit erst am Tag vor dem Launch zu starten. Dann fehlt die Zeit für die Korrekturen.

Nach dem Go-live: Vorher-Nachher-Vergleich und Monitoring

Trag am Tag des Launches in den Metriken eine Notiz ein, wann die neue Website live gegangen ist. Danach vergleichst du Zeiträume und Seiten direkt miteinander. Vergleiche am besten gleich lange Zeiträume mit ähnlicher Saison, sonst misst du den Sommer statt des Relaunchs.

Schau dabei zuerst auf deine Ziele: Steigt die Conversion-Rate, kommen mehr Anfragen oder Käufe, und aus welchen Kanälen? Mit mehrstufigen Funnels siehst du Schritt für Schritt, wo Besucher*innen abspringen, zum Beispiel im neuen Checkout. Die Heatmaps zeigen, ob die neuen Call-to-Actions angeklickt werden. Die User Flows zeigen, ob die neue Navigation Besucher*innen früher verliert als die alte. Die Ergebnisse exportierst du als .csv oder .pptx, zum Beispiel für die Präsentation im Lenkungskreis.

Für die Barrierefreiheit übernimmt das WCAG-Monitoring diese Aufgabe. Es prüft jede Seite gegen mehr als 80 WCAG-Prüfregeln, sortiert die Verstöße nach Schweregrad und zeigt dir die Entwicklung Woche für Woche. Nach einem Relaunch entstehen oft viele neue URLs. Ab dem Starter-Plan erkennt das Monitoring neue Seiten und prüft sie automatisch: bis zu 100 URLs im Starter-Plan, 250 im Solo-Plan und 600 im Agency-Plan.

Welcher Plan für welchen Teil des Relaunchs

Dein nächster Schritt: sitebrunch auf der alten Website starten

Für einen Relaunch passt unser Solo-Plan. Er vereint alles aus diesem Artikel: Messwerte und Ziele sichern, Feedback sammeln, Audit vor dem Go-live und Monitoring danach. Buche ihn auf der Preisseite, solange die alte Website noch online ist. Nur dann hast du am Launch-Tag etwas, womit du vergleichen kannst.

FAQ

Funktioniert die Kommentarfunktion auch auf der Vorschau der neuen Website?

Ja. Leg für die Vorschau, zum Beispiel staging.deine-domain.de, ein eigenes Projekt in sitebrunch an. Dann sammelst du das Feedback zur neuen Website getrennt von der Live-Website.

Reicht ein automatischer Check für die Barrierefreiheit?

Nein. Ein automatischer Check ist keine rechtliche Prüfung und kein Nachweis der Konformität. Er zeigt offensichtliche Probleme, zum Beispiel fehlende Alternativtexte für Bilder oder Formularfelder ohne Label. Für den Rest brauchst du das manuelle Audit.

Wir haben keine Kapazität für das Audit. Was nun?

Dann prüfen wir für dich. In rund vier Wochen bekommst du Report, Entwurf der Barrierefreiheitserklärung und einen priorisierten Maßnahmenplan. Der Preis hängt davon ab, wie viele Seiten, Templates und PDFs geprüft werden. Agenturen können das Audit auch im White Label an ihre Kund*innen weiterverkaufen.