To find out whether a cookie banner really blocks tags, load the site in a clean browser profile, open the network panel before you click anything, and list every request to a third party domain. Repeat after rejecting and after accepting. Requests before a choice, or after a reject, are the gaps.
Why the banner is not proof
A banner is a user interface. What matters is what the tag manager and the page do behind it. Tags can fire from a trigger that ignores consent, from code hard coded in a template, or from a vendor script that loads another vendor. Google's consent mode documentation also makes clear that its mode adjusts how Google tags behave and does not by itself promise to block everything.
The three state test
State 1: no choice. Fresh profile, no saved cookies, network panel open with Preserve log on.
State 2: reject all. Clear site data, reload, choose the reject option.
State 3: accept all. Clear site data, reload, accept.
For each state, record the domains contacted and the cookies set. Use the Application panel for cookies and local storage.
What to compare
| Observation | What it suggests |
|---|---|
| Third party requests before any choice | Tags fire without waiting for consent |
| The same requests after reject as after accept | The banner is not wired to the tags |
| New cookies set before a choice | Storage happens ahead of consent |
| Requests only after accept | Wiring works for those tags |
| Tags that fire on later pages after reject | The choice is not persisted across pages |
Google's guide notes consent mode does not save the visitor's choice, so persistence across page loads is a common failure. Test by navigating to a second and third page in each state.
Steps to fix what you find
- For each leaking tag, find where it is fired: tag manager trigger, template, or another script.
- Add a consent condition to the trigger, or move the load behind the banner callback.
- Make sure the default state runs before anything else on every page.
- Retest all three states and attach the results to the change record.
- Schedule a recheck after each major tag release, since new tags default to firing everywhere.
Do not forget embedded video, chat widgets and social buttons. They are third party scripts too. To list what a page loads, use the script inventory method.
This is a technical test, not a legal opinion. Ask counsel what your obligations are.
Try it yourself
Click through it at your own pace, or open it full screen. See how a recurring check catches drift, which is how a tag that starts firing early is found.
Quick check
Is a banner that shows a reject button enough?
Not on its own. Test that the reject choice changes which requests and cookies appear.
How often should I retest?
After any tag manager release and after any banner or template change.
Where Safeguard fits
Safeguard offers dependency scanning, SBOM, policies and gates for your code. The browser test above stays a manual or separate monitoring step. Try the free scan for the code side.
Sources
Last reviewed: 19 October 2026.
