# Einen Button testen, einen kompletten Website-Relaunch als sicher ansehen

> Warum ein Website-Relaunch Design, CMS, URLs, Inhalte, Formulare und Messung getrennt behandeln sollte und wie schrittweises Vorgehen Migrationsrisiken senkt.

Ein Team kann eine Änderung am Button-Text als Hypothese behandeln und dafür einen Testplan aufstellen. Dasselbe Team kann in einer einzigen Nacht eine neue Website mit Hunderten Entscheidungen veröffentlichen.

Soll auf dem Button „Angebot anfordern“ oder „Jetzt Ihr Angebot anfordern“ stehen? Soll ein Formular vier oder sechs Felder haben? Teams aus digitalem Marketing, CRO, UX, Produkt und Web können eine Meinung haben, behandeln sie aber nicht als Beleg. Wo es möglich ist, testen sie, messen sie und entscheiden dann.

Sobald aus der Arbeit ein vollständiger Relaunch wird, können sich Design, Navigation, Texte, Formulare, URL-Struktur, CMS und Messkonzept über Monate hinweg zugleich ändern. Dann wird die alte Website abgeschaltet und die neue für alle live geschaltet.

> Unsere neue Website ist live.

Warum nehmen Teams, die bei einem Button fragen „Sind wir sicher, dass das besser ist?“, so viel schneller an, dass eine neue Website aus Hunderten Entscheidungen besser sein wird?

> 💡 **Kurz gesagt: zentrale Punkte**
>
> - Die alte Website muss vielleicht ersetzt werden. Das bestätigt nicht jede Entscheidung der neuen.
> - Ein Website-Relaunch ist keine einzelne Änderung. Er verbindet Design, Migration und Geschäftsabläufe.
> - Der wesentliche Ansatz besteht darin, Änderungen zu trennen, zu bewahrendes Verhalten als Vertrag zu definieren und jede Stufe an ihrem eigenen Ergebnis zu messen.

## Die alte Website kann schlecht sein. Das macht die neue nicht automatisch gut.

Die alte Website kann langsam sein, auf Mobilgeräten schwer nutzbar oder nicht mehr passend für die Marke. Das Veröffentlichen von Inhalten kann mühsam geworden sein. Schulden bei Barrierefreiheit oder Sicherheit können sich angehäuft haben. In manchen Fällen ist ein Ersatz überfällig.

Doch „wir müssen die alte Website ersetzen“ und „die Hunderte Entscheidungen im Ersatz sind richtig“ sind unterschiedliche Aussagen. Die erste beweist die zweite nicht.

Die Probleme der alten Website sind sichtbar und vertraut. Die Probleme der neuen sind noch nicht eingetreten. Ein klareres Design, schnellere Technologie und bessere Texte begründen eine plausible Erwartung. Eine plausible Erwartung ist kein Beleg.

## Ein Website-Relaunch ist nicht eine Änderung

Die Arbeit von Ronny Kohavi und seinen Kollegen zu groß angelegten Experimenten bei Microsoft berichtet, dass ungefähr ein Drittel der getesteten Ideen die vorgesehenen Kennzahlen verbesserte. Das heißt nicht, dass ein Drittel aller Website-Relaunches erfolgreich ist. Die Forschung betrifft Ideen in Microsoft-Produkten und vorab definierte Erfolgskennzahlen. Sie zeigt jedoch, dass Ideen, die erfahrenen Teams vernünftig erscheinen, häufig nicht das erwartete Ergebnis liefern. [Das ist die hilfreiche Grenze der Arbeit](https://chbrown.github.io/kdd-2013-usb/kdd/p1168.pdf).

Wenn Sie einen Button ändern, ist klar, was geprüft wird. Ersetzen Sie eine Website, können sich neben dem visuellen Design auch Informationsarchitektur, Seitenhierarchie, Inhalte, URLs, Analytics-Ereignisse, Einwilligungsverhalten, Werbe-Conversions, CRM-Felder und Integrationen ändern.

Wenn Formularübermittlungen zurückgehen, kann die Ursache der neue Ablauf sein, ein zusätzliches Feld, ein Fehler bei der Browser-Validierung, ein fehlendes Conversion-Ereignis oder eine defekte CRM-Anbindung. Ändern Sie alles am selben Tag, wissen Sie nicht mehr, wo Sie beginnen sollen. Selbst wenn die Website besser funktioniert, wird es schwieriger zu lernen, welche Entscheidung geholfen hat.

Ein Relaunch ist deshalb ebenso sehr eine Migration wie eine Designaufgabe. Google empfiehlt, Änderungen an Elementen wie Domain, CMS und Seitenlayout nicht gleichzeitig vorzunehmen. Zudem sollen Teams die neue Website vorab testen, alte URLs neuen URLs zuordnen und den Traffic nach dem Umzug überwachen. Die [offiziellen Hinweise zu Website-Umzügen](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) richten sich an die Suche, stützen aber eine allgemeinere Projektlektion: Mit der Zahl gleichzeitiger Änderungen wird die Diagnose schwieriger.

## Der zentrale Ansatz: schrittweiser Relaunch

Die Antwort beginnt meines Erachtens damit, die Website als Folge zusammenhängender, aber trennbarer Änderungen zu behandeln. Nennen wir das einen *schrittweisen Relaunch*.

Trennen Sie zunächst, was tatsächlich geändert werden muss. Reicht das CMS nicht mehr aus? Ist das Design das Problem? Leitet die Informationsarchitektur Menschen an den falschen Ort? Ändert sich die Marke? Ist die URL-Struktur zu einer technischen Beschränkung geworden? Jeder Punkt kann ein berechtigter Handlungsgrund sein. Sie müssen nicht alle am selben Tag ändern.

Wenn das CMS ersetzt werden muss, kann die neue Plattform zunächst das wichtige Verhalten der aktuellen Website nachbilden. Sobald dieser Umzug geprüft ist, kann die Navigation folgen. Wichtige Landingpages können die nächste Stufe sein. Formularfelder und -ablauf können eine weitere Stufe bilden.

Diese Reihenfolge funktioniert nicht in jedem Projekt. Ein neues Backend kann das alte Frontend möglicherweise nicht unterstützen. Zwei Teile der Informationsarchitektur lassen sich vielleicht nicht trennen. Ein Rebranding kann zwei visuelle Identitäten nicht gleichzeitig zulassen. Sie können dennoch trennen, was trennbar ist, und erklären, warum der Rest gemeinsam umziehen muss.

## Erst festlegen, was gleich bleibt; dann Änderungen staffeln

Anforderungen für einen Relaunch beschreiben meist, was die neue Website leisten soll. Sie sollten auch festhalten, was in der ersten Stufe nicht verändert werden darf.

Behalten Sie bestehende URLs bei, wenn es keinen Grund für ihren Ersatz gibt. Müssen sie sich ändern, ordnen Sie jeder wichtigen alten URL im Voraus ihr neues Ziel zu. Dasselbe Nutzerverhalten sollte dasselbe Analytics-Ereignis auslösen. Eine erfolgreiche Formularübermittlung sollte den erwarteten CRM-Datensatz mit korrekten Quellen- und Kampagnendaten erzeugen.

Das werden Verträge, die vor und nach dem Start geprüft werden können. „Das Formular funktioniert“ ist ein schwaches Abnahmekriterium. „Das Formular liefert eine erfolgreiche Antwort, erzeugt genau einen Lead mit den richtigen Feldern im CRM und löst das Conversion-Ereignis erst nach erfolgreicher Übermittlung aus“ ist hilfreicher.

Der erste Erfolgsmaßstab einer technischen Migration ist nicht eine höhere Conversion-Rate. Es geht darum, das Geschäftsverhalten zu erhalten, das das alte System bereits erzeugte. Navigation, Seitenbotschaft und Formularlänge können danach als getrennte Verhaltensentscheidungen geändert werden.

Die Trennung erleichtert auch die Rücknahme. Funktioniert das neue CMS, aber nicht die neue Navigation, lässt sich die Navigationsentscheidung korrigieren, ohne die gesamte Migration zurückzurollen.

## In jeder Stufe das Richtige messen

Beobachten Sie bei einer technischen Migration 404- und 5xx-Fehler, Crawlability, Canonical Tags, Analytics-Ereignisse, Erfolgsquoten von Formularen und die Integrität der CRM-Datensätze. Ziel ist Kontinuität, nicht der Nachweis von Wachstum.

Bei einer Verhaltensänderung können Conversion, Aufgabenerledigung, Nutzung der Navigation oder die Quote qualifizierter Leads zählen. Behalten Sie Schutzkennzahlen wie organischen Traffic, Fehlerquote und Formularzustellung im Blick.

Nicht jede Stufe braucht einen A/B-Test. Sie sollten aber in gewissem Maß nachvollziehen können, welche Änderung welches Ergebnis ausgelöst haben könnte. Kampagnen, Saisonalität und die erneute Verarbeitung durch Suchmaschinen verhindern perfekte Kausalität. Jede Stufe mit Datum zu dokumentieren, verringert dennoch Unsicherheit.

## Ein gestaffelter Rollout ist ein Werkzeug, nicht das Modell

Bei einem Canary Release wird eine Änderung zunächst einem kleinen Teil der Produktion ausgesetzt und erst dann ausgeweitet. Die [Google-SRE-Hinweise](https://sre.google/workbook/canarying-releases/) zeigen seinen Nutzen für stark frequentierte Dienste, bei denen Signale wie Fehlerquote oder Latenz rasch sichtbar werden.

Nicht jede Website hat diese Voraussetzungen. Bei einer B2B-Website mit wenig Traffic kann es lange dauern, bis eine aussagekräftige Kontrollgruppe entsteht. Organische Sichtbarkeit lässt sich schwer nach Nutzeranteil aufteilen. Suchmaschinen brauchen Zeit für URLs; Markenwahrnehmung und Informationsarchitektur ändern sich langsamer als Serverfehler.

Googles Hinweise zu Website-Umzügen ergänzen eine wichtige Nuance. Sie empfehlen, verschiedene Arten von Änderungen zu staffeln, raten bei kleinen oder mittelgroßen Websites aber im Allgemeinen dazu, alle URLs auf einmal umzuziehen. Größere Websites können möglicherweise Abschnitt für Abschnitt umziehen.

Ein schrittweiser Relaunch trennt Projektentscheidungen. Ein gestaffelter Rollout ist ein Werkzeug für Releases, wenn Technologie und Messung ihn sinnvoll machen. Manchmal übersteigen die Kosten der Trennung ihren Nutzen. Die Fälle von [Google Drive](https://research.google/pubs/minimizing-change-aversion-for-the-google-drive-launch/) und [Spotify](https://research.atspotify.com/publications/minimizing-change-aversion-through-mixed-methods-research-a-case-study-of-redesigning-spotifys-your-library) beschreiben, wie Teams Reaktionen von Nutzerinnen und Nutzern auf große Interface-Änderungen erforschen und steuern können. Meine Schlussfolgerung ist nicht, die erste Reaktion als dauerhaftes Qualitätsurteil zu behandeln. Sichtbar werden sollte, welche Unsicherheiten Sie gemeinsam tragen und warum.

## Was sollten Sie morgen früh tun?

Bevor Sie eine ausführlichere Liste von Funktionen für die neue Website schreiben, zerlegen Sie das Projekt in eine Tabelle wie diese:

| Bereich | Erste Entscheidung | Zu bewahrender Vertrag | Prüfung |
| --- | --- | --- | --- |
| CMS und Infrastruktur | Muss es sich ändern? | Wichtige URLs und Inhalte bleiben erhalten. Formulare und Messung verhalten sich wie zuvor. | Crawls vergleichen, Fehler prüfen sowie Formulare und Ereignisse testen. |
| URLs und Inhalte | Müssen sie wirklich geändert werden? | Jede wichtige alte URL bleibt erhalten oder leitet auf einen sinnvollen Ersatz weiter. | URL-Zuordnung, Statuscodes, Canonical Tags und interne Links prüfen. |
| Navigation und Design | Welches Geschäftsergebnis soll sich ändern? | Wichtige Inhalte, Aktionen und Messpunkte verschwinden nicht. | Aufgabenerledigung, Conversion, organischen Traffic und Barrierefreiheit messen. |
| Formulare, Messung und CRM | Warum sollten sie in der ersten Stufe geändert werden? | Eine erfolgreiche Übermittlung erzeugt genau einen Geschäftsdaten-satz mit den richtigen Feldern. | End-to-End-Übermittlungen ausführen und CRM-, Fehler- und Erfolgsprotokolle prüfen. |

Ordnen Sie jede Zeile einer von drei Gruppen zu: muss jetzt geändert werden, in der ersten Stufe erhalten oder später testen. Halten Sie dann für jede Stufe Ausgangswert, Abnahmekriterium und Abbruchbedingung fest. Gehen Sie weiter, weil die vorherige Stufe ihre Verträge erhalten hat, nicht weil der nächste Termin erreicht ist.

Die Website kann bereit sein. Das ist kein Beleg dafür, dass sie besser ist. Im Launch-Meeting fehlen zwei Fragen:

> Welche Änderung veröffentlichen wir?
>
> Funktionieren die Verhaltensweisen, die unverändert bleiben sollen, weiterhin?

## Quellen

- [Kohavi et al. — Online Controlled Experiments at Large Scale](https://chbrown.github.io/kdd-2013-usb/kdd/p1168.pdf)
- [Google Search Central — Website-Umzüge und Migrationen](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)
- [Google SRE — Canarying Releases](https://sre.google/workbook/canarying-releases/)
- [Google Research — Veränderungsaversion beim Start von Google Drive verringern](https://research.google/pubs/minimizing-change-aversion-for-the-google-drive-launch/)
- [Spotify Research — Redesign von Your Library](https://research.atspotify.com/publications/minimizing-change-aversion-through-mixed-methods-research-a-case-study-of-redesigning-spotifys-your-library)

---

Language: German
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/de/website-relaunch-schrittweise-steuern