Aktualisiert: März 2026 · Lesezeit: 11 Min.
Hier ist eine unbequeme Wahrheit: Bei ungefähr 60 % der Websites, die ich audite, werden Tracking-Cookies gesetzt, bevor der Nutzer überhaupt eine Chance hatte, auf „Akzeptieren" zu klicken. Das Cookie-Banner steht da, sieht professionell aus — und hinter den Kulissen feuert Google Analytics fröhlich los.
Warum? Weil das Banner und das Tracking technisch nichts miteinander zu tun haben. Das eine ist ein Overlay, das andere ein Skript im Header. Ohne korrekte Verknüpfung arbeiten beide unabhängig voneinander. Das Banner ist Dekoration.
Und genau das prüfen die Aufsichtsbehörden seit 2025 automatisiert. Nicht ob ein Banner existiert — sondern ob es technisch funktioniert.
Die technischen Ursachen lassen sich auf eine Handvoll Szenarien eingrenzen:
Der Klassiker. Google Analytics oder der Meta Pixel sind direkt im <head> eingebunden — per Copy-Paste aus der Anleitung. Der Browser lädt diese Skripte, bevor das CMP überhaupt initialisiert ist. Ergebnis: Cookies vom ersten Millisekunde an.
WooCommerce, Contact Form 7, Elementor, WPForms — viele Plugins laden eigene Tracking-Skripte oder binden Drittanbieter ein. Ihr CMP weiß davon nichts, weil es diese Skripte nicht steuern kann. Besonders tückisch: Plugins, die nach einem Update plötzlich neue Tracker mitbringen.
Google Tag Manager ist installiert, die Tags sind konfiguriert — aber ohne Consent-Trigger. Das heißt: Alle Tags feuern beim Seitenaufruf, unabhängig davon, was das Banner sagt. Der GTM ist ein mächtiges Tool, aber ohne korrekte Consent-Integration ist er eine Datenschutz-Zeitbombe.
Manche CMPs werden asynchron geladen. Auf langsamen Seiten oder bei hohem Traffic kann es passieren, dass andere Skripte schneller sind als das CMP. Das Tracking läuft schon, bevor das Banner überhaupt angezeigt wird. Ein Race Condition, die in der Theorie nicht passieren sollte — in der Praxis aber regelmäßig vorkommt.
google-analytics.com, googletagmanager.com, connect.facebook.net, hotjar.comZusätzlich: Tab „Application" → Cookies prüfen. Alles außer dem CMP-Cookie (z. B. CookieConsent, borlabs-cookie) ist verdächtig.
Schneller und zuverlässiger. Ein Cookie-Scanner prüft automatisch, welche Cookies und Netzwerk-Requests vor dem Consent stattfinden. Das nimmt die menschliche Fehlerquelle raus — denn manuell übersieht man leicht einen Request.
| Problem | Lösung | Aufwand |
|---|---|---|
| GA4 direkt im Header | Über GTM + Consent Mode einbinden | 30 Min. |
| Meta Pixel im Header | Über GTM + Consent-Trigger einbinden | 30 Min. |
| YouTube-Embeds | 2-Klick-Lösung oder CMP Content Blocker | 15 Min. |
| WordPress-Plugin-Tracker | Skripte über CMP-Kategorien steuern | 1-2 Std. |
| GTM ohne Consent-Trigger | Consent Mode v2 konfigurieren | 1 Std. |
| Google Fonts extern | Lokal einbinden | 30 Min. |
| CMP Race Condition | CMP-Skript als erstes im Head laden | 15 Min. |
Seit März 2024 verlangt Google den Consent Mode v2 für alle Werbetreibenden in der EU. Das betrifft GA4, Google Ads und alle anderen Google-Marketing-Produkte.
So funktioniert es: Ihr CMP sendet beim Seitenaufruf zunächst ein „denied"-Signal an den GTM. Keine Tags feuern. Erst wenn der Nutzer einwilligt, sendet das CMP ein „granted"-Signal — und dann erst feuern die Tags.
Was viele nicht wissen: Im „denied"-Zustand sendet Google trotzdem sogenannte „Pings" — cookielose Signale, die für Conversion-Modellierung genutzt werden. Das ist datenschutzrechtlich umstritten. Die Aufsichtsbehörden haben sich dazu noch nicht abschließend geäußert, aber persönlich würde ich sagen: besser als gar keine Daten, und besser als Cookies ohne Consent.
Das Problem einmal zu beheben, reicht nicht. Websites ändern sich — neue Plugins, Theme-Updates, Marketing-Kampagnen mit neuen Tracking-Pixeln. Was heute sauber ist, kann nächste Woche wieder kaputt sein.
Meine Empfehlung: Quartalsmäßige Cookie-Audits. Wer es ernster nimmt: monatlich. Und nach jedem größeren Update sofort prüfen.