Cookiebot: Reject Path Leaks Trackers
Your site uses Cookiebot. The banner is in place. Yet the dsgvochecker.de reject-path test shows trackers still firing after "Reject all". That is a GDPR violation under Art. 6 + 7 GDPR and the ECJ ruling C-673/17 Planet49. This page lists the four most common Cookiebot-specific causes with concrete fixes — every recommendation sourced from the official Cookiebot docs.
TL;DR: The four most common reject-path leaks on Cookiebot: (1) script not loaded first, (2) data-cookieconsent="ignore" mis-applied, (3) GTM without Consent Mode, (4) server-side-tagging endpoints outside the auto-block list.
How does the reject-path test work?
Three phases, each in a fresh browser. We record tracking behaviour separately and compare.
We load your page in an automated browser, click your Cookiebot banner's "Reject" button, and compare which tracker domains still send requests after the click. Properly configured: none. If any fire, that is non-compliant consent — see also the CNIL fines against Google (€150M) and Facebook (€60M) for exactly this case.
Cause 1: Is the Cookiebot script loaded first?
By far the most common mistake. If a tracker loads before Cookiebot is ready, auto-blocking cannot intercept it.
By far the most common cause. Cookiebot's auto-blocking works by modifying DOM elements before they load. If a tracker script loads before the Cookiebot script is fully initialised, Cookiebot cannot intercept it.
Fix: The Cookiebot tag must literally be the first entry in <head> — before Google Analytics, before GTM, before any marketing pixel. Even async or defer on the Cookiebot tag is dangerous, because other scripts may then finish faster.
Source: 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.")
Cause 2: Was data-cookieconsent="ignore" accidentally applied to a tracker?
Scripts with this marker bypass Cookiebot's auto-blocker. On trackers, that's a reject-path leak.
Cookiebot's auto-blocker respects manual markup. Putting data-cookieconsent="ignore" on a script tells the auto-blocker: "I'm in charge of this element, always run." Legitimate for technically required scripts (e.g. the banner itself), but if someone accidentally puts it on a tracker script, that script runs both before and after reject.
Fix: Search your site's source code for data-cookieconsent="ignore" and verify each occurrence is really a strictly necessary script. When in doubt, remove ignore and either drop the script or steer it via Cookiebot's Categories.
Source: Cookiebot Support — Disable automatic cookie blocking for a specific script
Cause 3: Do GTM tags fire without checking Consent Mode?
Cookiebot only blocks its own routing. GTM tags without a Consent Mode trigger run before that.
If you have Google Tag Manager on the page and dispatch tags via GTM, Cookiebot blocks the Cookiebot-side script routing — but GTM can fire its own tags without Cookiebot's auto-block in the loop. Classic case: marketing pixel in GTM, trigger "Page View" without a consent condition — fires immediately, no matter what the user clicks.
Fix: In GTM under Admin → Container Settings → Consent Settings, enable Consent Mode and mark all marketing/statistics tags with analytics_storage resp. ad_storage as required. Then GTM only fires those tags when Cookiebot signals granted for those storage types.
Source: Cookiebot Support — Google Tag Manager and Automatic cookie blocking + Google Consent Mode v2 docs
Cause 4: Is server-side tagging routing trackers via your own subdomain?
SST endpoints look like first-party subdomains. Cookiebot's auto-blocker does not recognise them as trackers.
Some sites route tracker calls through a first-party subdomain (e.g. gtm.your-domain.com or analytics.your-domain.com) — so-called server-side tagging. Upside for the site owner: first-party cookies, no ad-blocker issues. Problem for Cookiebot's auto-blocker: it does not recognise the first-party subdomain as a known tracker endpoint and lets it through.
Fix: SST endpoints must be wrapped explicitly via Cookiebot's manual markup (type="text/plain" + data-cookieconsent="marketing"), or the triggering code (typically inside the server-side GTM container) must itself check the Cookiebot consent API Cookiebot.consent.marketing.
Source: Cookiebot Support — Manual cookie blocking
How do I verify the fix worked?
Clear all caches, then re-scan. If the test reports "Reject path effective", you are GDPR-compliant.
After every change: redeploy the site, clear caches (CDN + browser), and start another reject-path scan at dsgvochecker.de. The scan is free. If it reports "Reject path effective", your Cookiebot configuration is now GDPR-compliant.
For the full three-phase comparison (Pre-Consent / Reject / Accept incl. detailed report), the one-time audit is $4.95 — no subscription, with a Markdown report by email.
As of: 2026-04-29 · Sources from support.cookiebot.com are linked at each point.