Wenn das Cookie-Banner wechselt und es dir niemand sagt

Cookie Banner Monitoring bedeutet, im Blick zu behalten, welche Consent Management Platform (CMP) auf einer Website läuft, sicherzustellen, dass sie jeden Deploy übersteht, und zu prüfen, ob sich die Marketing-Tags rund um die Einwilligung noch korrekt verhalten. Verschwindet das Banner, setzt die Website Tracking-Cookies, ohne zu fragen, und das ist ein DSGVO-Problem; wechselt es, können GA4 und der Meta Pixel aufhören zu laden, während jede Seite völlig gesund aussieht.

Keine Seite liefert einen 404, kein Uptime-Check wird rot. Das erste Anzeichen ist meist eine Conversion-Kurve, die ein paar Wochen später keinen Sinn mehr ergibt.

Wer am Banner dreht und warum dir niemand Bescheid sagt

Consent liegt zwischen den Abteilungen. Die Rechtsabteilung verantwortet die Cookie-Richtlinie und oft auch den CMP-Vertrag. Ein Entwickler verantwortet das Plugin oder das Skript im <head>. Das Marketing verantwortet die Tags, die davon abhängen. Für das Ergebnis ist niemand zuständig, also passieren Änderungen aus Gründen, die für ein Team sinnvoll sind und die anderen nie erreichen.

Typische Beispiele: Ein Entwickler installiert Complianz oder CookieYes auf einer WordPress-Website, die bereits ein Consent-Setup hatte. Die Rechtsabteilung zieht den Account von Cookiebot zu OneTrust um und behandelt das als Vertragsthema. Ein Theme- oder CMS-Update wirft das Snippet raus, das die CMP geladen hat. Jemand benennt die Consent-Kategorien um, und ein Tag landet in einer Kategorie, die kein Besucher je aktiviert. Oder das Banner war auf Staging deaktiviert, um das Testen zu erleichtern, und diese Einstellung geht mit dem Release live.

Jeder dieser Fälle ist eine klassische stille SEO-Änderung, nur dass der Schaden in Analytics und Compliance entsteht statt in den Rankings.

Was ein CMP-Wechsel mit GA4 und dem Meta Pixel macht

Die meisten CMPs blockieren Skripte vor der Einwilligung, entweder anhand der Skript-URLs oder indem sie Tags Kategorien zuordnen. Eine neue CMP kennt die Ausnahmen nicht, die in der alten eingerichtet waren. Ein Tag, das früher nach „Akzeptieren“ geladen hat, lädt dann womöglich nie. Google Tag Manager ist vorhanden, der Container feuert, und das GA4-Tag darin bleibt blockiert.

Mit dem Google Consent Mode v2 ist der Fehler schwerer zu erkennen. Die Seite setzt einen Standardzustand mit gtag('consent', 'default', {...}), und das Banner soll gtag('consent', 'update', {...}) aufrufen, sobald der Besucher zustimmt. Schickt das neue Banner dieses Update nie, bleiben analytics_storage und ad_storage auf „denied“. GA4 empfängt weiterhin Hits, aber als cookielose Pings, und die Berichte füllen sich mit modellierten Daten statt mit beobachteten Sitzungen. Im Network-Tab siehst du das an der Anfrage an /g/collect: Der Parameter gcs steht auf G100, wenn beide Speichertypen abgelehnt sind, und auf G111, wenn beide erlaubt sind.

Der umgekehrte Fehler sieht nach einer guten Nachricht aus. Verschwindet das Banner komplett, feuern die Tags für alle, und die GA4-Sitzungen springen nach oben. Dieser Sprung ist ein Compliance-Problem und kein Wachstum.

Ein Kategorie-Mismatch trifft Paid Media am härtesten. Hängt der Meta Pixel an einer Kategorie „Marketing“, die das neue Banner hinter einem zweiten Bildschirm versteckt, laufen die Kampagnen weiter und geben Budget aus, während Conversions nicht mehr zugeordnet werden.

Was die Seite in jedem Zustand tun sollte

Zustand	GA4 / GTM	Meta Pixel	Cookies, die du sehen solltest
Vor jeder Auswahl	Blockiert oder Consent Mode standardmäßig „denied“	Nicht geladen	Kein _ga, kein _fbp
Nach „Akzeptieren“	gtag.js lädt, /g/collect mit gcs=G111	fbevents.js lädt	_ga, _ga_<ID>, _fbp
Nach „Ablehnen“	Keine Hits oder nur cookielose Hits	Nicht geladen	Kein _ga, kein _fbp

Den Consent von Hand prüfen

1. Öffne ein frisches privates Fenster. Eine gespeicherte Einwilligung aus einem früheren Besuch verdeckt das Problem.
2. Lade die Startseite und notiere, welche CMP das Banner anzeigt. Cookiebot, Iubenda, OneTrust, CookieYes und Complianz haben alle erkennbares Markup und eindeutige Skript-URLs.
3. Öffne die DevTools, geh auf Network und filtere nach collect, gtag und fbevents. Schau dir auch Application > Cookies an.
4. Klick auf „Akzeptieren“ und prüf, ob die Anfragen und Cookies aus der Tabelle oben erscheinen. Kontrolliere, ob die Measurement-ID in der Anfrage (tid=G-...) noch die des Kunden ist.
5. Wiederhole das in einem neuen privaten Fenster und klick diesmal auf „Ablehnen“.
6. Mach dasselbe auf jedem wichtigen Template und lass die Danke-Seite oder Bestellbestätigung nicht aus, denn dort feuern die Conversion-Tags.

Das dauert etwa zehn Minuten pro Website. Einmal ist das in Ordnung, nach jedem Release auf dreißig Kundenseiten ist es unrealistisch.

Wobei Deltio hilft und wo es aufhört

Deltio prüft einmal täglich die Startseite jeder Website, hält fest, welche CMP vorhanden ist, und meldet per Slack und E-Mail, wenn der Anbieter auftaucht, verschwindet oder wechselt. Im selben Tageszyklus prüft es GA4, GTM und den Meta Pixel auf den überwachten Seiten und meldet ein Tag, das fehlt oder dessen ID sich geändert hat. Ein Banner-Wechsel und ein fehlendes Pixel landen also am selben Ort und am selben Tag.

Ob deine Consent-Konfiguration rechtlich ausreicht, prüft Deltio nicht, und es erstellt auch kein Inventar der Cookies, die eine Website setzt. Es sagt dir, was auf der Seite liegt und was sich seit der letzten Prüfung geändert hat. Für den Rest einer Kundenseite siehe die Website-Monitoring-Checkliste für Agenturen und unseren Leitfaden, wie du Kunden-Websites auf Änderungen überwachst.

Ein guter Anfang ist der Kunde, bei dem Rechtsabteilung, Entwickler und Marketing noch nie gemeinsam in einem Call saßen. Du kannst diese Website 14 Tage kostenlos testen.