Ein Website-Relaunch legt die Messung nur selten sichtbar lahm. Die neue Version sieht besser aus, Formulare funktionieren, das Telefon klingelt – nur der Bericht zeigt nicht mehr, woher die Anfragen kommen. Dieser Text ist kein Redesign-Ratgeber. Er ist eine Liste der Dinge, die du vorher absichern und danach prüfen musst, damit deine neue Website nicht ohne Vorgeschichte startet.
Was ein Relaunch konkret kaputtmacht
Die Messung auf einer Website ist kein einzelnes System. Sie besteht aus mehreren Ebenen, die an unterschiedliche Elemente geknüpft sind: an den Template-Code, an Unterseiten-URLs, an Namen und IDs im Code sowie an das visuelle Layout. Ein Relaunch verändert all diese Ebenen gleichzeitig – doch jede fällt anders und zu einem anderen Zeitpunkt aus.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Element | Was beim Relaunch passiert | So sicherst du es ab |
|---|---|---|
| An IDs und Labels gebundene Geschäftsziele | Das Ziel wird im Dashboard definiert, aber durch einen Aufruf auf der Website erfasst. Ändert das neue Template die ID einer Schaltfläche oder das Label eines Formulars, wird dieser Aufruf nicht mehr ausgeführt – ohne Hinweis und ohne Fehlermeldung | Liste alle Ziele zusammen mit der Stelle im Code auf, an die sie gebunden sind, und übergib diese Liste dem Dienstleister als festen Teil des Auftrags, nicht als beiläufige Anmerkung |
| Unterseiten-URLs | Eine neue URL-Struktur unterbricht die Kontinuität der Berichte. Dieselbe Unterseite erscheint als zwei verschiedene Einträge, während die Historie vor dem Relaunch bei der alten URL bleibt | Erstelle vor der Veröffentlichung eine Zuordnung von alten zu neuen URLs, richte die Weiterleitungen am selben Tag ein und bewahre die Liste als Schlüssel für die Zusammenführung der Daten auf |
| Klick- und Scroll-Heatmaps | Heatmaps werden je URL erfasst und beziehen sich auf ein bestimmtes Layout. Nach einer Layoutänderung liegen die Klickpunkte an Stellen, an denen sich nichts mehr befindet | Exportiere oder beschreibe die Auswertungen des alten Layouts vor der Veröffentlichung und behandle sie als abgeschlossenes Kapitel, nicht als Vergleichsbasis |
| Sichtbarkeitsregeln des Widgets | Die Regeln basieren auf Pfadpräfixen. Durch neue URLs erscheint das Widget nicht mehr dort, wo es vorgesehen war – oder taucht dort auf, wo es verborgen bleiben sollte | Gleiche die Regeln noch vor der Veröffentlichung mit der neuen URL-Zuordnung ab und prüfe sie in der Testumgebung, bevor Besucher auf die neue Version gelangen |
| In Theme-Dateien eingefügte Skripte | Beim Austausch des Themes verschwindet alles, was irgendwann direkt in seine Dateien eingefügt wurde. Das Skript wird zusammen mit dem alten Template gelöscht, ohne dass es jemand bemerkt | Lade das Widget über ein Plugin, das keine Bearbeitung des Themes erfordert, und hinterlege andere Skripte an einer vom Template unabhängigen Stelle |
| Einwilligungen und Cookie-Banner | Das neue Banner hat andere Standardeinstellungen und einen anderen Ladezeitpunkt. Ein Teil der Ereignisse wird nicht mehr erfasst, obwohl alle Skripte vorhanden sind | Behandle das Banner als eigene Implementierung und prüfe es separat, indem du die Anzahl der Ereignisse vor und nach der Änderung vergleichst |
All diese Ausfälle haben eines gemeinsam: Keiner meldet sich von selbst. Die Website funktioniert, die Schaltfläche lässt sich anklicken, das Formular wird versendet. Es fehlt nur die Aufzeichnung des Ereignisses – und eine fehlende Aufzeichnung sieht im Bericht genauso aus wie sinkendes Interesse.
Ein deaktiviertes Ziel zeigt keinen Fehler an – es zeigt einfach null und sieht wie eine schwache Woche aus. Sieh dir an, wie Meetlead die Datenabdeckung in Berichten ausweist, damit du fehlende Ereignisse von einer ausgefallenen Messung unterscheiden kannst.
Warum ein Vorher-Nachher-Vergleich wertlos sein kann
Die erste Frage nach jedem Relaunch lautet: Ist die neue Website besser? Meist wird sie beantwortet, indem der Monat vor der Veröffentlichung mit dem Monat danach verglichen wird. In den meisten Fällen ist dieser Vergleich nicht belastbar, denn nicht nur die Website hat sich verändert, sondern auch die Zählweise und die Zusammensetzung des Traffics.
- Der Zähler hat sich geändertNeu definierte Ziele haben andere Auslösebedingungen als zuvor und zählen deshalb ein etwas anderes Ereignis.
- Der Nenner hat sich geändertNeue URLs teilen Unterseiten auf oder führen sie zusammen. Damit beruhen die Seitenaufrufe nicht mehr auf derselben Basis.
- Der Traffic hat sich geändertNach einem Relaunch pendeln sich die Suchpositionen über mehrere Wochen neu ein, während sich der Anteil der Zugriffsquellen verschiebt.
- Der Zeitpunkt hat sich geändertEine Veröffentlichung fällt selten in eine neutrale Woche. Der Kalendereffekt vermischt sich deshalb mit der Wirkung der Änderung.
Damit der Vergleich aussagekräftig ist, musst du ihn eingrenzen. Frage nicht, ob die gesamte Website besser ist, sondern wähle einige konkrete Übergänge, die vor und nach der Veröffentlichung dasselbe bedeuten: Einstieg auf einer Leistungsseite und Wechsel zur Kontaktaufnahme, Öffnen der Preisseite und Beginn eines Gesprächs oder Absenden des Formulars auf einer bestimmten Unterseite. Wie du solche Ereignisse auswählst, erklären wir separat im Artikel über Mikro-Conversions auf einer Website.
Wir nennen hier keine feste Anzahl von Wochen, nach denen Daten nach einem Relaunch wieder vergleichbar sind. Dieser Zeitraum hängt vom Traffic-Volumen, der Geschwindigkeit der erneuten Indexierung, dem Umfang der URL-Änderungen und der Saison ab, in der die Veröffentlichung stattfindet. Ein belastbarer Bezugspunkt ist der Moment, in dem deine eigenen Tageswerte wieder eine gleichmäßige Streuung zeigen – nicht eine Zahl aus einem fremden Artikel.
Eine weitere Falle ist der Vergleich von Zahlen aus zwei verschiedenen Tools vor und nach der Veröffentlichung. Wenn du vor dem Relaunch ein Dashboard und danach ein anderes genutzt hast, beruht ein Teil der Abweichung auf unterschiedlichen Definitionen – nicht auf der Website. Die Ursachen solcher Unterschiede erläutern wir im Artikel darüber, warum Daten nicht übereinstimmen.
Was du vor dem Relaunch für eine belastbare Ausgangsbasis erfassen solltest
Eine Ausgangsbasis lässt sich im Nachhinein nicht wiederherstellen. Wenn das alte Template verschwindet, gehen auch die Informationen darüber verloren, woran die Messung gebunden war und welche Ergebnisse das alte Layout lieferte. Diese Liste kostet einen Arbeitstag und ist das Einzige, was sich nicht auf später verschieben lässt.
- Vier Wochen vor der Veröffentlichung: Ziele erfassen.Liste jedes gemessene Geschäftsziel mit der Unterseite, dem Element und dem Label auf, an die es gebunden ist. Diese Aufstellung erhält der Dienstleister als Teil des Auftrags.
- Vier Wochen vorher: Ladeorte der Messung erfassen.Kläre, was über ein Plugin, was über den Tag-Manager und was irgendwann direkt aus den Theme-Dateien geladen wurde. Die dritte Gruppe ist diejenige, die verschwinden wird.
- Drei Wochen vorher: URL-Zuordnung erstellen.Erstelle eine vollständige Liste der aktuellen URLs und ordne ihnen die neuen zu. Dieselbe Liste dient später den Weiterleitungen, den Sichtbarkeitsregeln des Widgets und der Zusammenführung der Berichte.
- Zwei Wochen vorher: Ausgangswerte festhalten.Halte die wichtigsten Kennzahlen für einen einheitlichen, abgeschlossenen Zeitraum fest – samt Datumsbereich und Angaben zur Datenabdeckung. Später lässt sich nicht mehr rekonstruieren, auf welcher Stichprobe die Berechnung beruhte.
- Zwei Wochen vorher: Heatmaps beschreiben und Aufzeichnungen auswählen.Beschreibe, was die Klick- und Scroll-Heatmaps der wichtigsten Unterseiten zeigen, und sichere Verweise auf einige Aufzeichnungen, die bekannte Probleme des alten Layouts veranschaulichen.
- Eine Woche vorher: Sichtbarkeitsregeln des Widgets erfassen.Liste die Pfadpräfixe auf, unter denen das Widget erscheinen oder verborgen bleiben soll, und gleiche sie mit der neuen URL-Zuordnung ab.
- Am Tag der Veröffentlichung: Datum und Uhrzeit notieren.Halte den genauen Zeitpunkt der Umschaltung an einer zentralen Stelle fest. In drei Monaten entscheidet diese eine Zeile die Hälfte aller Diskussionen darüber, wann der Rückgang begonnen hat.
Der letzte Punkt wirkt trivial und wird am häufigsten ausgelassen. Ohne dokumentiertes Umschaltdatum beginnt jede spätere Analyse mit der Frage, wann sich die Website eigentlich geändert hat – und schon nach einem Monat gehen die Erinnerungen im Team auseinander.
Du kannst die Daten zum alten Layout nur erfassen, bevor es abgeschaltet wird. Sieh dir an, wie Meetlead Heatmaps, Aufzeichnungen und Geschäftsziele in einem Dashboard zusammenführt, damit du diese Bestandsaufnahme an einem Ort erledigen kannst.
Die erste Woche nach der Veröffentlichung: erst die Messung, dann die Ergebnisse
Der häufigste Fehler nach einer Veröffentlichung: Das Team schaut sofort auf die Ergebnisse. Die Kurve fällt, eine hektische Diskussion über das neue Layout beginnt – und zwei Wochen später stellt sich heraus, dass das Ziel seit dem Tag der Umschaltung nicht mehr ausgelöst wurde. Die Reihenfolge muss umgekehrt sein: Prüfe zuerst, ob die Messung überhaupt funktioniert, und interpretiere erst danach die Zahlen.
- Tag eins: ein Testbesuch über den gesamten Pfad.Durchlaufe selbst den Weg vom Einstieg bis zur Kontaktaufnahme und prüfe, ob im Dashboard eine Sitzung, ein Gespräch oder eine Anfrage aus diesem Besuch erscheint. Dieser eine Test räumt die meisten Zweifel aus.
- Tag eins: das Widget auf allen Arten von Unterseiten.Öffne aus jeder URL-Gruppe je eine Unterseite und bestätige, dass das Widget genau dort erscheint, wo es vorgesehen ist, und dort verborgen bleibt, wo es nicht angezeigt werden soll.
- Tag zwei: jedes Geschäftsziel einzeln.Löse jedes gemessene Ziel manuell aus und prüfe seine Erfassung. Ein Ziel, das du nicht selbst ausgelöst hast, ist nicht geprüft – ein Nullwert im Bericht beweist nicht, dass kein Interesse besteht.
- Tag zwei: URLs in den Berichten.Prüfe, ob die neuen URLs in den Berichten erscheinen, ob alte URLs weiterhin Seitenaufrufe sammeln und ob Weiterleitungen Schleifen oder zusätzliche Sprünge erzeugen.
- Tag drei: Datenabdeckung.Vergleiche den Anteil der Sitzungen mit erfasster Zugriffsquelle mit dem Wert vor der Veröffentlichung. Ein plötzlicher Anstieg nicht abgedeckter Sitzungen deutet meist auf eine Änderung am Einwilligungsbanner oder an der Ladereihenfolge der Skripte hin.
- Tag fünf: Heatmaps und Aufzeichnungen im neuen Layout.Vergewissere dich, dass auf den neuen URLs Daten erfasst werden. Für eine Ergebnisbewertung ist es noch zu früh, doch die Erfassung selbst muss bestätigt sein.
- Erst nach einer Woche: die erste Ergebnisanalyse.Sind alle vorherigen Punkte erledigt, kannst du einen Rückgang oder Anstieg endlich als Information über die Website und nicht über die Messung betrachten.
- Mittwoch, Veröffentlichung
Die neue Website-Version geht zusammen mit dem neuen Theme live
- Donnerstag
Die Besucherzahl sieht normal aus, deshalb prüft niemand etwas
- Montag
Der Bericht zeigt null versendete Formulare, doch per E-Mail gehen weiterhin Anfragen ein
- Dienstag
Ein Testbesuch zeigt: Das Formular funktioniert, aber das Ziel wird nicht erfasst
- Mittwoch
Das neue Template hat die Formular-ID geändert; der Aufruf auf der Website wurde nie ausgeführt
Dieselbe Reihenfolge funktioniert bei der Einführung jedes neuen Tools, nicht nur bei einem Redesign. Ausführlicher beschreiben wir sie im Artikel darüber, wie der erste Monat nach der Implementierung aussieht.
Ein Testbesuch über den gesamten Pfad deckt mehr auf als eine Woche, in der du auf eine Kurve starrst. Buche die Implementierung – wir gehen die Liste gemeinsam auf deiner neuen Website-Version durch.
Beim Messen von Navigation ohne vollständiges Neuladen hilft der Leitfaden: Seitenmessung in SPAs: erscheint jeder Bildschirmwechsel im Verlauf?.
Heatmaps und Aufzeichnungen nach der Layoutänderung
Klick- und Scroll-Heatmaps sind stärker an ein bestimmtes Website-Layout gebunden als jede andere Datenart. Ein Punkt auf der Heatmap bedeutet: „Hier haben Menschen geklickt.“ Aussagekräftig ist er aber nur, wenn du weißt, was sich damals an dieser Stelle befand. Nach einem Relaunch gilt dieses Wissen nicht mehr – selbst wenn sich die URL der Unterseite nicht geändert hat.
- Die Auswertungen des alten Layouts wurden in Worten beschrieben, bevor das Template verschwand – ein Screenshot der Heatmap ohne Beschreibung der Elemente wird schnell unverständlich.
- Heatmap-Daten vor und nach der Veröffentlichung werden weder addiert noch in einer gemeinsamen Auswertung gemittelt.
- Die neue Erfassung beginnt am Tag der Umschaltung, nicht an dem Tag, an dem jemand die Layoutänderung bemerkt.
- Erste Schlüsse aus den neuen Heatmaps ziehst du erst, nachdem auf den wichtigsten Unterseiten eine vergleichbare Anzahl von Sitzungen erfasst wurde.
- Aufzeichnungen aus der Zeit vor dem Relaunch wurden gezielt als Beispiele bekannter Probleme gesichert, nicht als Material für quantitative Vergleiche.
- Bei Unterseiten mit geänderter URL wurde eindeutig dokumentiert, dass die Heatmap-Historie der alten URL zugeordnet ist.
Die praktische Regel lautet: Heatmaps des alten Layouts beantworten die Frage, warum der Relaunch nötig war. Heatmaps des neuen Layouts zeigen, ob er geholfen hat. Es sind zwei getrennte Datensätze; vermischst du sie, erhältst du eine Kurve, die sich nicht interpretieren lässt. Wie du die Ergebnisse selbst liest, erklären wir im Leitfaden darüber, wie du Heatmaps auswertest.
Bei Aufzeichnungen ist die Situation weniger kritisch: Eine Aufzeichnung zeigt immer den Verlauf eines konkreten Besuchs auf einer bestimmten Website-Version und gibt sich nicht als aggregierter Datensatz aus. Denk nur daran, dass eine Aufzeichnung vor dem Relaunch ein Layout dokumentiert, das nicht mehr existiert. Vermerke deshalb bei jedem Ergebnis, auf welche Version es sich bezieht.
Was du nicht gleichzeitig mit dem Relaunch ändern solltest
Ein Relaunch verführt dazu, nebenbei alles andere aufzuräumen. Wenn wir die Website ohnehin anfassen, können wir auch gleich das Analysetool wechseln, die Ziele neu definieren, das Einwilligungsbanner überarbeiten und die Formulare umziehen. Das Ergebnis ist eine Veränderung, deren Wirkungen sich nicht mehr trennen lassen, weil sich alles am selben Tag verschoben hat.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Änderung | Warum nicht gleichzeitig | Wann du sie umsetzen solltest |
|---|---|---|
| Wechsel des Analysetools | Unterschiedliche Definitionen überlagern die Layoutänderung, sodass unklar bleibt, was die Zahlen beeinflusst hat | Mindestens einen Monat vor dem Relaunch oder einen Monat, nachdem sich der Traffic stabilisiert hat |
| Neue Definition der Ziele | Neue Auslösebedingungen zählen ein anderes Ereignis. Damit taugt der bisherige Ausgangswert nicht mehr als Referenz | Vor dem Relaunch auf der alten Website-Version, damit du rechtzeitig Ausgangswerte für die neuen Definitionen erfassen kannst |
| Änderung des Einwilligungsbanners | Sie verschiebt die Stichprobe, auf der alle Kennzahlen beruhen, und sieht genauso aus wie ein Traffic-Rückgang | Als eigene Implementierung mit einer separaten Prüfung der Datenabdeckung vor und nach der Änderung |
| Werbekampagne zum Neustart | Sie verändert die Zusammensetzung des Traffics genau in den Wochen, in denen du das neue Layout bewerten wolltest | Nach der ersten vollständigen Woche mit nachweislich funktionierender Messung |
| Änderung der Kontaktkanäle auf der Website | Es bleibt unklar, ob mehr Anfragen auf das Layout oder den neuen Kontaktweg zurückgehen | Zwei bis vier Wochen nach dem Relaunch als separat gemessene Änderung |
Die Regel ist einfach: immer nur eine große Änderung, mit genügend Abstand für die Datenerfassung. Lässt der Zeitplan das nicht zu und müssen mehrere Änderungen gleichzeitig live gehen, halte das ausdrücklich in den Notizen zur Veröffentlichung fest. Zu wissen, dass sich ein bestimmter Monat nicht eindeutig auswerten lässt, ist besser als Schlüsse aus einem Vergleich zu ziehen, in dem fünf Ursachen vermischt sind. Fällt der Relaunch kurz vor die Hauptsaison, hilft dir unser Leitfaden zum Änderungsstopp vor Weihnachten, die Reihenfolge der Arbeiten festzulegen.
Bedenke außerdem, dass einige Aspekte auch nach dem Relaunch außerhalb der Reichweite quantitativer Messung bleiben. Die Grenzen der Webanalyse beschreiben wir im Artikel darüber, was Google Analytics nicht zeigt. Nach URL-Änderungen liefert die Search Console mehrere Wochen lang ein Übergangsbild und eignet sich ebenfalls nicht als einziges Kriterium zur Bewertung der neuen Version.
