Pre-Consent Tag Blocking: Verifying Nothing Fires Before the Click
Every consent platform claims it blocks tags before consent. The claim is testable in ten minutes, and the test fails often enough that experienced auditors run it before they read a single policy document. A tag manager container loaded early, a hard coded script in the theme, a chat widget that phones home on render: each one bypasses the platform while the banner still displays beautifully.
Dashboards cannot settle this. Only the browser's own record of what left the machine, and when, can.
The clean profile test
Use a fresh browser profile or a cleared container, because your everyday browser carries consent cookies from your last visit and will happily show you the after consent state while you believe you are testing the before. Open the developer tools network panel, load the homepage, and do not click anything. Filter for the domains your notice lists: analytics, advertising, video embeds, chat, heatmaps.
Read two things. The requests themselves, and the cookies set by the response and by scripts, in the application panel. A request to an analytics endpoint before consent is a leak even if it claims to be cookieless, because the request itself carries identifiers like IP address and user agent to a third party the visitor has not agreed to. Note each offender with its trigger if you can find it.
Where the leaks hide
Tag managers are the first suspect. A container that loads unconditionally will fire any tag whose trigger is a page view unless consent conditions are built into the tag itself or enforced by consent mode with real blocking behind it. Consent mode alone, set to denied, limits what compliant Google tags store; it does not stop third party tags in the same container from firing.
Theme and plugin scripts are the second. Anything hard coded outside the consent platform's control, an analytics snippet in a header file, a pixel installed by a marketing plugin, fires on its own schedule. Embeds are the third: video players, social feeds, and maps that load their full third party stack to render a thumbnail. Each category needs a different fix, which is why the inventory from the test matters more than the pass or fail.
Fix, then prove it again
Bring stray scripts under consent control: remove hard coded tags into the managed container, gate embeds behind click to load placeholders, and set tag level consent checks so a purpose denial actually suppresses firing. Then repeat the clean profile test and test the other two states as well: refused, where nothing non essential should fire at any point in the session, and partially accepted, where only the chosen purposes fire.
Save the network log exports with the audit. When a vendor or a colleague later insists blocking has always worked, a dated log showing a pre consent request is a shorter conversation. Re run the test after every tag manager publish, because that is when new leaks are born.
Related reading
These earlier guides cover connected questions in more depth: Consent Cookie Lifetimes: Auditing Expiry Dates Nobody Set on Purpose, Auditing Tag Manager Consent Defaults: Where the Leaks Actually Are, and Consent State Across Subdomains: Why Your Banner Keeps Coming Back.
Frequently asked questions
Does consent mode count as blocking?
Not by itself for all tags. Consent mode communicates state to tags that honour it and limits storage when denied, but non compliant third party tags can still fire. Verification has to observe actual network behaviour, not configuration screens.
What should fire before consent?
Only what is strictly necessary for the page the user requested: the site's own resources and genuinely essential services. Analytics, advertising, social embeds, and most chat and heatmap tools should wait.
How do I test the refused state, not just the untouched state?
Load in a clean profile, refuse, then navigate several pages including pages with embeds and forms, watching the network panel throughout. Some tools behave on the landing page and leak deeper in the site where different templates load different scripts.
How often should pre consent blocking be verified?
After every tag manager or template change, and on a regular audit cycle. New tags arrive through routine marketing work, and each one is a fresh chance for a pre consent leak that no dashboard will flag.