What's the correct pattern to block GA/GTM/AdSense from loading until the visitor accepts cookies?
Short answer
The correct pattern is to prevent the tag's script from ever executing in the first place - mark it as an inert placeholder (type="text/plain" with a data-category attribute) and have the consent banner swap it to a real, executable script only after the matching category is accepted, rather than loading the real script and trying to stop its behavior afterward.
Why this happens
Many scripts, AdSense in particular, start doing things - setting cookies, opening connections, making requests - the instant their JavaScript executes, not after some later "enable" call. Any approach that lets the real script run and then tries to suppress its side effects after the fact is fighting code that has already done what it was going to do; the only reliable point of control is before the browser parses and executes the tag at all.
Fix it
- 1
Convert every consent-gated script tag to an inert placeholder
Change
<script src="...">to<script type="text/plain" data-category="analytics">(or whatever category name your CMP uses) for GA, GTM, and AdSense tags - browsers do not executetext/plainscript blocks, so nothing runs until something explicitly activates them. - 2
Configure your CMP to activate the matching category on accept
Point your consent library (this family's sites use vanilla-cookieconsent) at the
data-categoryattribute so it finds and activates the right placeholders when a visitor accepts that category - typically by swapping thetypeattribute or cloning and replacing the node so the browser treats it as new, executable script. - 3
For GTM specifically, gate the container plus set per-tag consent, not just the container script
Load the GTM container itself behind the same consent gate, but also use GTM's own built-in Consent Settings on each tag inside the container - some tags (the consent-listener tag itself, for example) may need to run regardless, so container-level gating alone is usually too blunt.
- 4
For AdSense, confirm which compliance mode your policy actually requires
If restricted-but-not-fully-blocked ads are the correct approach for a given consent state, Google's documented pattern is
window.adsbygoogle.requestNonPersonalizedAds = 1;rather than blocking the tag outright - confirm with whoever owns the ad-compliance decision which behavior is required before implementing either approach. - 5
Test for absence of the request, not just the absence of a visible ad or event
A tag can appear to "do nothing" visually while still firing a network request in the background - the pass/fail signal is whether the request to the vendor's domain exists at all, not whether you can see an effect on the page.
How to verify it worked
Load the page in a fresh/incognito session, don't interact with the consent banner, and check the Network tab for zero requests to google-analytics.com, googletagmanager.com, and googlesyndication.com.
Accept the relevant category and confirm the requests now appear without a page reload.
Decline, then check again after a reload to confirm the gate re-applies consistently rather than only working on first load.
Related
Still stuck, or want this checked against your specific setup?
We scope every engagement in discovery, before implementation - no assumptions about your stack.