Website-Änderungsprotokoll: Änderungen erfassen und Traffic-Schwankungen erklären

Was ist ein Website-Änderungsprotokoll, und wie unterscheidet es sich vom Changelog der Entwickler?

Das Website-Änderungsprotokoll ist eine Historie für das Marketing: alles, was sich an der Website geändert hat, so festgehalten, dass jeder, der auf eine Traffic- oder Conversion-Kurve schaut, ein Datum einer Ursache zuordnen kann. Es ist weder die Git-Historie noch das Produkt-Changelog.

Das Entwickler-Changelog listet Commits und Versionsnummern. Selten steht dort, dass dasselbe Release auch die H1 von 40 Kategorieseiten geändert, ein Formularfeld entfernt oder das Cookie-Banner verschoben hat. Genau diese Details erklären aber einen Rückgang bei organischen Klicks oder Leads, und genau sie hält das Website-Protokoll fest.

Betrachten Sie es als eine Spur in einem umfassenderen Marketing-Änderungsprotokoll: die Website neben Werbekonten, Tracking und CRM. Die Website ist oft die gemeinsame Ursache von Schwankungen, die in mehreren Kanälen gleichzeitig auftauchen, denn bezahlter, organischer und E-Mail-Traffic landet auf denselben Seiten.

Was sollte ein Website-Änderungsprotokoll enthalten?

Erfassen Sie jede Änderung, die beeinflussen kann, wie Seiten gecrawlt, gerankt oder geladen werden oder wie Besucher konvertieren. Im Zweifel eintragen: Ein Eintrag kostet eine Minute, ein fehlender unter Umständen Tage an Analyse.

Tragen Sie auch ein, was nicht Ihr Team gemacht hat, aber die Website betrifft: ein automatisches Plugin-Update, einen Hosting-Ausfall oder ein Google-Ranking-Update. Diese Ereignisse konkurrieren mit Ihren eigenen Änderungen als Erklärung und gehören deshalb auf dieselbe Zeitachse.

Wie richte ich ein Website-Änderungsprotokoll ein?

Nutzen Sie immer dieselben Felder, einen Eintrag pro Änderung, und machen Sie das Protokollieren zu einem Schritt des Releases statt zu einer Gedächtnisübung im Nachhinein.

1. Datum und Uhrzeit der Liveschaltung. Nicht das Datum, an dem das Ticket geschlossen wurde. Notieren Sie die Zeitzone, denn Analytics und Server nutzen oft unterschiedliche.
2. Umfang. Welche URLs, Templates, Bereiche oder Märkte betroffen sind (zum Beispiel „alle /blog/-Seiten“ oder „Checkout, nur mobil“).
3. Was sich geändert hat, vorher → nachher. „Title-Muster: Produkt | Marke → Produkt online kaufen | Marke“ hilft. „SEO-Anpassungen“ hilft nicht.
4. Typ-Tag. Release, Inhalt, Weiterleitung, Technik, Tracking, Angebot. Mit Tags können Sie später filtern.
5. Verantwortlich. Die Person oder Agentur, die die Änderung vorgenommen hat, damit klar ist, wen Sie fragen.
6. Grund und erwartete Wirkung. Eine Zeile: was Sie erwartet haben und bei welcher Kennzahl.
7. Link. Ticket, Pull Request, GTM-Version oder Screenshot.

Für den Anfang genügt eine gemeinsame Tabelle; unsere Vorlage für ein Marketing-Änderungsprotokoll enthält die Spalten bereits. Wichtiger als das Werkzeug ist die Regel: Wer veröffentlicht, protokolliert. Ergänzen Sie Ihre Release-Checkliste um den Punkt „protokolliert?“, damit der Eintrag am selben Tag entsteht und nicht einen Monat später rekonstruiert wird.

Kann ich stattdessen die Vermerke in GA4 oder die Anmerkungen in der Search Console nutzen?

Beide Tools erlauben es, Daten in ihren Diagrammen zu markieren, was allen hilft, die in diesen Berichten arbeiten. Ein vollständiges Protokoll ersetzen sie nicht, wegen der Längen- und Aufbewahrungsgrenzen.

In der Search Console lässt sich eine Anmerkung nach dem Anlegen nicht bearbeiten, und Google rät davon ab, personenbezogene Daten wie Namen einzutragen. GA4 legt außerdem eigene Systemvermerke an, wenn ein Ereignis die Daten beeinflusst. Nutzen Sie diese Markierungen als Verweise („Checkout-Template v3 live, siehe Protokoll“) und halten Sie Details, Verantwortliche und Vorher/Nachher in Ihrem eigenen Protokoll fest. Unser Ratgeber zu GA4-Anmerkungen erklärt die Einrichtung ausführlicher.

Wie finde ich mit dem Protokoll heraus, was eine Traffic- oder Conversion-Änderung verursacht hat?

Gehen Sie vom Datum aus, an dem sich die Kennzahl bewegt hat, und legen Sie alle Änderungen der Tage davor aus allen Quellen auf eine Zeitachse. Schließen Sie dann Tracking aus, prüfen Sie externe Ursachen und testen Sie jeweils eine Hypothese.

1. Datum festlegen. Finden Sie den ersten auffälligen Tag und prüfen Sie, ob die ganze Website betroffen ist oder nur bestimmte Seiten, Geräte, Länder oder Kanäle.
2. Alles aus den 7 bis 14 Tagen davor sammeln. Website-Einträge, Tag- und GTM-Veröffentlichungen, Änderungen in Werbekonten, im CRM oder an Formularen. Ein Release und ein Wechsel der Gebotsstrategie in derselben Woche bleiben beide verdächtig, bis einer ausgeschlossen ist.
3. Zuerst das Tracking ausschließen. Sinken die gemessenen Conversions, aber nicht die Bestellungen oder CRM-Leads, liegt das Problem in der Messung, oft bei einem Tag, einem Formular oder der Einwilligung. Unser Beitrag zum Versionsverlauf im Google Tag Manager hilft, Tag-Änderungen zu datieren.
4. Externe Ursachen prüfen. Googles Leitfaden zu Rückgängen beim Suchtraffic nennt Algorithmus-Updates, technische Probleme, Sicherheits- und Spam-Probleme, verändertes Suchinteresse und Website-Umzüge. Vergleichen Sie im Leistungsbericht die letzten 16 Monate, um saisonale Muster zu erkennen.
5. Umfang mit Umfang abgleichen. Ein Rückgang nur auf /blog/-Seiten deutet auf eine Änderung, die /blog/ betraf. Eine Checkout-Änderung erklärt keine sinkenden organischen Impressionen.
6. Eine Hypothese testen. Nehmen Sie eine Änderung zurück oder passen Sie sie an, oder vergleichen Sie betroffene mit nicht betroffenen Seitengruppen, und beobachten Sie die Kennzahl über einen angemessenen Zeitraum.

Rechnen Sie mit Verzögerung: Laut Google kann es bei einem Umzug mit URL-Änderungen bei einer mittelgroßen Website einige Wochen dauern, bis die meisten Seiten umgezogen sind, und die Sichtbarkeit kann in dieser Zeit schwanken. Für eine rein organische Diagnose lesen Sie Warum ist mein organischer Traffic gesunken.

Liegen Website-Releases, GTM-Veröffentlichungen und Änderungen in Werbekonten auf einer Zeitachse, steht ein Rückgang nur auf Produktseiten sofort neben dem Template-Release, das genau diese Seiten betraf. Legen Sie in Changeline kostenlos ein Änderungsprotokoll an und halten Sie Website- und Werbeänderungen an einem Ort.

Beispiel: einen Rückgang einem Template-Release zuordnen

Ein erfundenes Beispiel, kein echter Kunde. Ein Onlineshop sieht, dass die organischen Sitzungen auf Produktseiten von einer Woche zur nächsten um etwa 20 % sinken, während der Blog stabil bleibt.

• Zeitachse der 14 Tage davor: Release des neuen Produktseiten-Templates (Dienstag), GTM-Veröffentlichung mit einem neuen Event (Mittwoch), Budgeterhöhung in Google Ads (Donnerstag).
• Tracking-Prüfung: Auch die Klicks in der Search Console sind gesunken, nicht nur die Sitzungen in GA4, also liegt es nicht an einem Tag. Die GTM-Veröffentlichung scheidet aus.
• Umfang-Prüfung: Nur die Produktseiten sind gesunken, genau die mit dem neuen Template. Das Google-Ads-Budget senkt keine organischen Klicks.
• Detail aus dem Protokoll: Der Vorher/Nachher-Eintrag zeigt, dass das Release den Beschreibungsblock durch einen Tab ersetzt hat, der erst beim Klick lädt.
• Test: Das Team stellt die Beschreibung in der Hälfte der Kategorien wieder ins initiale HTML und vergleicht beide Gruppen in den folgenden Wochen.

Ohne Protokoll hätte das Team mit einer Vermutung begonnen, vermutlich mit der neuesten oder auffälligsten Änderung.

Wie halte ich Website- und Werbeänderungen auf einer Zeitachse?

Führen Sie alles an einem Ort zusammen, denn die Frage lautet selten „Was hat sich an der Website geändert?“, sondern „Was hat sich irgendwo geändert, bevor sich diese Kennzahl bewegt hat?“.

In Changeline protokollieren Sie Website-, Tracking- und CRM-Änderungen pro Projekt mit Datum, Verantwortlichen, Tags und Grund, und Änderungen aus Google Ads lassen sich über eine reine Leseverbindung automatisch importieren, mit Vorher → Nachher-Werten. Integrationen für die Website und weitere Tools sind noch nicht verfügbar, Website-Änderungen trägt also das Team ein. Die Einträge bleiben gespeichert, solange das Projekt existiert, sodass Sie leicht sehen, was in denselben Wochen des Vorjahres geändert wurde.

Unabhängig vom Werkzeug: Gehen Sie das Protokoll im Monatsbericht durch, listen Sie die Website-Änderungen des Zeitraums neben den Kennzahlen auf, die sie bewegen sollten, und notieren Sie, welche gewirkt haben.