Your Cookie Banner Probably Doesn't Block Anything. Here's the 5-Minute Test.

There is a dirty secret in the consent industry: a banner can be beautifully designed, legally worded, GDPR-branded — and functionally decorative. The visitor clicks Reject; the trackers fire anyway. This isn't usually malice. It's the gap between showing a banner and actually controlling scripts, and it exists because the second part is much harder than the first. Under ePrivacy Article 5(3) and GDPR, non-essential trackers require *prior* consent — a banner that doesn't prevent them isn't compliance, it's decoration. The good news: you can test any site's banner, including your own and including ours, in about five minutes with tools already in your browser.

The test

• Open a clean context. Use a private/incognito window so no prior consent cookie skews the result. Open DevTools (F12) → Network tab before loading the page.
• Load the page and don't touch the banner. Filter the network log for the usual suspects: googletagmanager, google-analytics, doubleclick, facebook, connect.facebook.net, tiktok, hotjar, clarity. Anything from that list loading *before you've made a choice* is a prior-consent failure right there.
• Click Reject and watch. The filtered log should stay quiet. If gtm.js or fbevents.js appears after a rejection, the banner is decorative.
• Check what got stored. DevTools → Application → Cookies and Local storage. After a rejection you should see, at most, the consent record itself (the cookie remembering "this person declined" is strictly necessary). A _ga, _fbp, or _hjSession cookie after rejecting is a failure.
• Reload and re-test. Some setups block on the first view and leak on the second, when cached tags initialize from stored state. The network log should stay clean on reload too.

Why banners fail this test

The most common failure isn't the banner at all — it's *how trackers arrive*. Consent tools that rely on rewriting <script> tags in the page's HTML catch exactly those tags and nothing else. But Google Tag Manager, Meta Pixel, TikTok, and most modern trackers don't arrive as static tags: their install snippet is a tiny inline script that *creates* the real script element programmatically and injects it. A blocker that only scans the HTML never sees it. Catching the dynamic path requires intercepting script insertion itself, at the DOM API level, synchronously — a mutation observer that reacts after the fact is already too late, because a script executes the moment it enters the document. This is genuinely hard to get right, it's where we've invested most of our engineering time, and it's the first thing we'd tell you to test — on any vendor, us included.

A second failure mode: the Reject button that saves a "rejected" state but is consulted by nothing. The state machine works; no script ever asks it for permission. This is why the network tab, not the banner's own UI, is the ground truth.

What regulators have said

This isn't a theoretical standard. France's CNIL issued multi-million-euro fines against major platforms over consent flows where rejecting was harder than accepting, and has stated that consent must be as easy to refuse as to give. Italy's Garante has rejected scroll-based and implied consent. The consistent principle across EU enforcement: consent must be prior, informed, specific, and freely given — and "freely given" includes the Reject button actually working. If a dispute ever arrives, the network-tab behavior of your site is exactly the kind of evidence that gets examined.

Make it a habit, not an audit

Run the five-minute test after anything touches your tag setup: a new marketing pixel, a GTM container change, a consent-tool update, a site redesign. Tag setups drift — a colleague pastes a pixel above the consent snippet, a plugin update re-orders scripts — and every drift fails silently in your favor until someone looks. We run this exact test as an automated suite on every change to our own widget (network-level assertions that rejected trackers produce zero requests, including dynamically injected ones), and we still recommend our customers spot-check manually. Trust, but verify — especially the vendor telling you to verify.

*This is a technical testing guide, not legal advice. What counts as "strictly necessary" for your site is a legal question worth asking properly.*