Cookiebot: Reject-Pfad leakt Tracker
Ihre Site nutzt Cookiebot. Der Banner ist da. Trotzdem zeigt der dsgvochecker.de-Reject-Pfad-Test, dass nach "Ablehnen" weiterhin Tracker feuern. Das ist ein DSGVO-Verstoß nach Art. 6 + 7 DSGVO und EuGH-Urteil C-673/17 Planet49. Diese Seite listet die vier häufigsten Cookiebot-spezifischen Ursachen mit konkretem Fix — alle Empfehlungen mit Quellen aus der offiziellen Cookiebot-Doku.
TL;DR: Die vier häufigsten Reject-Pfad-Lecks bei Cookiebot: (1) Skript nicht als erstes geladen, (2) data-cookieconsent="ignore" falsch verwendet, (3) GTM ohne Consent Mode, (4) Server-Side-Tagging-Endpoints außerhalb der Auto-Block-Liste.
Wie funktioniert der Reject-Pfad-Test?
Drei Phasen mit jeweils frischem Browser. Jede Phase nimmt das Tracking-Verhalten getrennt auf, dann vergleichen wir.
Wir laden Ihre Seite in einem fepo-eigenen Browser, klicken automatisiert den "Ablehnen"-Button Ihres Cookiebot-Banners, und vergleichen welche Tracker-Domains nach dem Klick noch Requests senden. Sauber konfiguriert: keine. Wenn doch welche feuern, gilt das als nicht-konforme Einwilligung — siehe auch CNIL-Bußgelder gegen Google (150 Mio. €) und Facebook (60 Mio. €) wegen genau dieses Falls.
Ursache 1: Wird das Cookiebot-Skript als Erstes geladen?
Mit Abstand der häufigste Fehler. Wenn ein Tracker lädt bevor Cookiebot fertig ist, kann das Auto-Blocking nicht greifen.
Cookiebots Auto-Blocking funktioniert, indem es DOM-Elemente vor dem Laden modifiziert. Wenn ein Tracker-Skript geladen wird bevor das Cookiebot-Skript voll initialisiert ist, kann Cookiebot es nicht abfangen.
Fix: Das Cookiebot-Tag muss buchstäblich der erste Eintrag im <head> sein — vor Google Analytics, vor GTM, vor jedem Marketing-Pixel. Auch async oder defer auf dem Cookiebot-Tag ist gefährlich, weil andere Skripte dann eventuell schneller fertig sind.
Quelle: Cookiebot Support — How does auto-blocking work? ("The Cookiebot script must be the first script to load and be fully loaded before other scripts start loading.")
Ursache 2: Wurde data-cookieconsent="ignore" versehentlich auf einem Tracker gesetzt?
Skripte mit dieser Markierung umgehen Cookiebots Auto-Blocker. Auf Trackern ist das ein Reject-Pfad-Leck.
Cookiebots Auto-Blocker respektiert manuelle Markierungen. Wer ein Skript mit data-cookieconsent="ignore" ausstattet, sagt dem Auto-Blocker: "Für dieses Element bin ich verantwortlich, läuft immer." Das ist legitim für technisch zwingend nötige Skripte (z.B. das Banner selbst), aber wenn jemand das versehentlich auf ein Tracker-Skript setzt, läuft das vor und nach Reject.
Fix: Im Source-Code Ihrer Site nach data-cookieconsent="ignore" suchen und für jedes Vorkommen prüfen, ob das wirklich ein technisch zwingendes Skript ist. Im Zweifel ignore entfernen und das Skript entweder löschen oder über Cookiebots Categories steuern.
Quelle: Cookiebot Support — Disable automatic cookie blocking for a specific script
Ursache 3: Feuern GTM-Tags ohne Consent-Mode-Prüfung?
Cookiebot blockt nur Cookiebot-eigene Routings. GTM-Tags ohne Consent-Mode-Trigger laufen davor.
Wenn Sie Google Tag Manager auf der Seite haben und Tags über GTM ausspielen, blockiert Cookiebot zwar das Cookiebot-eigene Skript-Routing, aber GTM kann eigene Tags auslösen, ohne Cookiebots Auto-Block dazwischenzuschalten. Klassisch: Marketing-Pixel im GTM, Trigger "Page View" ohne Consent-Bedingung — feuert sofort, egal was der User klickt.
Fix: In GTM unter Admin → Container Settings → Consent Settings den Consent Mode aktivieren und alle Marketing/Statistik-Tags mit analytics_storage bzw. ad_storage als required versehen. Dann triggert GTM die Tags nur, wenn Cookiebot ein granted für diese Storage-Typen liefert.
Quelle: Cookiebot Support — Google Tag Manager and Automatic cookie blocking + Google Consent Mode v2 Doku
Ursache 4: Wird Server-Side-Tagging (SST) über eine eigene Subdomain umgangen?
SST-Endpoints sehen wie eigene Subdomains aus. Cookiebots Auto-Blocker erkennt sie nicht als Tracker.
Manche Sites leiten Tracker-Calls über eine eigene Subdomain um (z.B. gtm.ihre-domain.de oder analytics.ihre-domain.de) — das sogenannte Server-Side-Tagging. Vorteil für den Site-Betreiber: First-Party-Cookies, keine Adblocker-Probleme. Problem für Cookiebots Auto-Blocker: er erkennt die Eigen-Subdomain nicht als bekannten Tracker-Endpoint und lässt sie passieren.
Fix: SST-Endpoints müssen explizit über Cookiebots Manual-Markup (type="text/plain" + data-cookieconsent="marketing") gewrappt werden, oder der Triggering-Code (typischerweise im Server-Side-GTM-Container) muss selbst die Cookiebot-Consent-API Cookiebot.consent.marketing abfragen.
Quelle: Cookiebot Support — Manual cookie blocking
Wie verifiziere ich, dass der Fix wirkt?
Cache komplett leeren, dann erneut scannen. Wenn der Reject-Pfad sauber ist, sind Sie DSGVO-konform.
Nach jeder Änderung: Site einmal vollständig deployen, Cache leeren (CDN + Browser), und einen erneuten Reject-Pfad-Scan auf dsgvochecker.de starten. Der Scan ist kostenlos. Wenn der Test "Reject-Pfad sauber" meldet, ist Ihre Cookiebot-Konfiguration jetzt DSGVO-konform.
Für den vollen Drei-Phasen-Vergleich (Pre-Consent / Reject / Accept inkl. Detailbericht) gibt es das einmalige Audit für 4,95 USD — ohne Abo, mit Markdown-Report per Mail.
Stand: 29.04.2026 · Quellen aus support.cookiebot.com sind bei den jeweiligen Punkten verlinkt.