Back to News & Insights
Web Development October 5, 2026 · 6 min read

Your Cookie Banner Is Probably Lying: Trackers That Fire Before Consent, and How to Actually Block Them

Most consent banners look compliant and still send analytics hits before anyone clicks. How to catch it in DevTools in two minutes, and how to build a consent gate that really blocks.

Your Cookie Banner Is Probably Lying: Trackers That Fire Before Consent, and How to Actually Block Them

Open almost any small business website in a fresh incognito window, don't touch the cookie banner, and open DevTools. On a surprising number of them, the banner is still waiting for your answer while the analytics tag has already reported your visit.

The banner is there. The "Reject all" button is there. The privacy policy is there. And none of it matters, because the tracking happened in the first 400 milliseconds, before the banner even finished rendering.

This is not usually malice. It is an ordering problem, and it is one of the most common gaps between a site that looks compliant and one that is.

You don't need any tooling beyond the browser. Open a private window, so no previous consent is stored. Open DevTools, go to the Network tab, tick Preserve log. Load the page. Do not click anything on the banner. Type collect in the Network filter.

The requests go to region1.google-analytics.com/g/collect, the status is 204 No Content, and the initiator is the analytics script itself. That is a page view being sent without consent.

Three tracking identifiers, written before the visitor said yes. If your banner claims to block non-essential cookies until consent, this output says otherwise.

The analytics tag runs as soon as it downloads. The banner script is deferred, so it runs after the document is parsed, by which time the page view is already gone. Some banner libraries try to fix this after the fact by deleting cookies once they load. That removes the evidence from the cookie jar, but the network request has already left the building. You can't un-send a hit.

The second common cause is embeds. A YouTube iframe or a Google Maps embed in the footer sets its own cookies and makes its own requests the moment the iframe loads, regardless of what your banner says.

The most robust pattern is also the oldest: don't give the browser executable scripts until consent exists. Mark them as inert data instead.

A with type="text/plain" is parsed but never executed. When the visitor accepts a category, you swap it for a real one:

Note that simply changing the type attribute of an existing inert script does not make the browser run it. You have to insert a new element. This is a classic bug in hand-rolled consent code: the attribute flips, nothing executes, and someone "fixes" it by removing the text/plain entirely.

If you rely on Google Tag Manager or gtag.js, Consent Mode gives you a way to declare the default state before any tag runs. The critical detail is order: this snippet must execute before the tag library loads.

One thing worth understanding before you ship this: Consent Mode has two implementations. In the basic setup, Google tags are not loaded at all until consent is given. In the advanced setup, the tags load immediately and, while consent is denied, send cookieless pings instead of full hits. Whether cookieless pings are acceptable for your case is a legal and policy decision, not a technical one, so make it deliberately rather than inheriting it from a template.

For YouTube and Maps, the cleanest answer is to not load the iframe until the visitor asks for it. Render a static placeholder, a thumbnail image and a play button, and only inject the real iframe on click:

The privacy-enhanced domain alone is not a full solution, but combined with click-to-load it means nothing third-party happens until the visitor explicitly wants the video. As a side effect, the page gets noticeably faster, since a YouTube embed pulls in a substantial amount of JavaScript on its own.

A banner can block perfectly and still fail on design. European regulators have been consistent that refusing must be as easy as accepting. Italy's data protection authority, the Garante, published cookie guidelines in 2021 that treat closing the banner with an X as a refusal. A banner whose "Reject" option is hidden behind a second screen, while "Accept" is a big coloured button, is asking for trouble regardless of how good the blocking code is.

The same goes for re-opening the choice. There should be a persistent way for the visitor to change their mind, typically a link in the footer, and changing from "granted" to "denied" must actually stop future hits, not just update a checkbox.

Manual checks catch the problem once. A tiny automated check catches it every time someone changes the header. Here is a minimal Playwright script that loads the page with no stored consent and fails if any request reaches a known tracking host before the banner is touched:

Want to discuss this further?

Book a free strategy call with our team to see how these insights apply to your specific business goals.

Book a consultation