Cookiebot19 May 2026·Updated 25 July 2026·5 min read

Cookiebot is installed but tags still fire before consent. Here's why.

The most common CMP misconfiguration we see: Cookiebot is live, the banner shows, and Google Analytics fires anyway. Why it happens, and the fix.

YaBy Yaroslav · Perfmetrix

Short answer: a cookie banner and your tags are two separate systems, and installing the first does nothing to the second. Cookiebot blocks by rewriting script tags in the page, but Google Tag Manager injects tags dynamically after Cookiebot has scanned the DOM — so it never sees them. The fix is almost never a Cookiebot setting. It's a Consent Mode default that runs before the container, plus consent checks on the tags themselves.

You installed Cookiebot. The banner appears. You assumed that meant your tags wait for consent. Then a scan shows _ga and _gcl_au being set on page load, before anyone clicks anything.

This is the single most common consent problem we see, and it's almost always one of a handful of causes. It is also not a Cookiebot defect — the same thing happens with every CMP that relies on auto-blocking, because the cause is architectural.

Cause 1: Auto-blocking isn't actually on

Cookiebot's automatic cookie-blocking works by rewriting script tags on the page. If your tags are injected through Google Tag Manager, Cookiebot often can't see or rewrite them — GTM loads them dynamically after Cookiebot has already scanned the DOM.

The fix isn't Cookiebot's auto-blocking. It's Consent Mode + GTM triggers.

Cause 2: GTM tags fire on "All Pages" with no consent check

Open your GTM container and look at your GA4 and Ads tags. If their trigger is "All Pages — Page View" with no consent condition, they fire the instant GTM loads. The banner is irrelevant to them.

A cookie banner controls the UI. It does not control your GTM tags unless you explicitly wire consent into them. These are two separate systems, and installing the first does nothing to the second.

Cause 3: Consent Mode default state is missing

Google Consent Mode expects a default command to run before any tags — telling Google to assume consent is denied until the user says otherwise:

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500,
});

If this doesn't run first — as a Consent Initialization trigger in GTM, ahead of everything — tags behave as if consent were granted.

The correct setup, in order

Consent Initialization trigger fires the Consent Mode default (all denied).
Cookiebot updates the consent state when the user chooses, via gtag('consent', 'update', …).
Your GA4, Ads and Meta tags are configured with built-in consent checks (Additional Consent Checks in GTM) so they respect the state.
Nothing non-essential fires until consent is granted.

Verify it

Don't trust that it worked — prove it. Reload the page with a clean profile and confirm no analytics or ads cookies appear before you interact with the banner. Then accept, and confirm they appear after.

You can run this check automatically: our Consent Mode v2 detector loads your site, inspects the dataLayer, and tells you whether the default state and the v2 signals are actually present.

What we've seen

This is the single thing we get called in to fix more than any other, and the shape of it is always the same: the CMP is live, the banner renders, the client believes the job is done, and GTM is still firing everything on All Pages with no consent condition attached.

We put numbers on it when we scanned a sample of private UK clinic sites. 37% were leaking data before any interaction — and every one of those had already bought a consent platform. Nobody in that sample was ignoring the law. They'd all paid for a solution and nobody had checked whether it did anything.

The reason it survives so long is that it's invisible from the inside. The admin panel says the CMP is active. The banner appears when you load the site. Nothing looks broken, and nothing will look broken until somebody opens the network tab or a regulator does.

The two-minute check anyone can run

You don't need a tool for the first pass, and doing it by hand is worth it once because it shows you what the tools are looking at.

Open your site in a fresh private window and open DevTools before the page loads.
Go to the Application tab, then Cookies. Don't touch the banner.
Look for _ga, _gid, _gcl_au or _fbp. If any of them are there before you've clicked anything, tags fired without consent.
Now switch to the Network tab, filter for collect or google-analytics, and reload. Requests appearing before your click are the same problem seen from the other side.
Finally, type dataLayer in the Console and look for a consent default entry. If there isn't one, Consent Mode was never initialised, whatever the CMP's dashboard says.

Do this again after accepting, and you should see the opposite result. If both states look identical, the banner is decorative.

When to get help

If your tags are hardcoded into the theme (common on WordPress builders) rather than in GTM, Cookiebot and GTM consent checks can't reach them — those need to be removed at the page level. That's the half of cases where a scan says "still leaking" even after the GTM side looks right.

If you'd rather not spelunk through your own container, we fix exactly this — including the hardcoded-tag cases — and prove it with a before/after scan.

Sources

1.Google — Consent Mode: default and update commands, and the Consent Initialization trigger · Checked 2026-07-25
2.Google — Consent Mode for CMP providers (ad_user_data, ad_personalization) · Checked 2026-07-25
3.Google Ads Help — Set up your consent banner with a consent management platform · Checked 2026-07-25
4.Perfmetrix — UK private clinic consent benchmark (our own scan data) · 2026-07-08