Cookie banners that do nothing: trackers firing before consent

The banner is the visible part. What matters is which requests leave the browser before anybody clicks Accept — and how to see them.

Privacy · Published: 28 August 2026 · 3 min read · Ольга Мирошник

Almost every site has a consent banner. A surprising number of them are decorative: the scripts they are supposed to gate have already loaded by the time the banner renders. The banner asks permission for something that has happened.

What regulators actually look at

Not the banner design. The question is narrow and technical: between page load and the click on Accept, did anything leave the browser that identifies the visitor? That includes analytics beacons, advertising pixels, session recorders, embedded video players, chat widgets, font services that log IPs, and any cookie set with an identifier in it.

Two things follow. Refusal must be as easy as acceptance — a "Reject all" button on the first screen, not three clicks into a settings modal. And a pre-ticked box is not consent anywhere in the EU, which has been settled law since Planet49.

Where the leaks come from

Tag managers. The container itself is usually harmless; the tags inside fire on page view unless every single one is bound to a consent trigger. One forgotten tag is one violation.

Third-party embeds. A YouTube iframe or a map sets cookies the moment it renders. The fix is a click-to-load placeholder, not a note in the privacy policy.

Self-hosted assumptions. A font or a script loaded from a CDN sends the visitor's IP to that CDN. That is a transfer, whether or not you think of the CDN as a tracker.

The banner script itself. Several consent platforms set an identifier before any choice is made — ironically, the tool bought for compliance.

How to see the truth

Reading the code will not tell you; the network will. Load the page in a clean profile, do not click anything, and record every request:

requests before consent
  .filter(r => r.setsCookie || r.thirdParty)
  .groupBy(r => r.domain)

Anything in that list that is not strictly necessary for the page to function is a finding. Repeat with "Reject all" clicked — a depressing number of sites fire the same requests either way — and again after Accept, to confirm the tags that should fire actually do.

The pages people forget

The consent state has to hold across the whole site, not just the home page. Campaign landing pages built outside the CMS, old microsites on a subdomain, the checkout, and anything served by a different stack are where the exceptions live. A per-page crawl catches them; a manual check of the home page never will.

Keep the legal pages honest

The privacy policy should list the same processors your network log shows. When the two disagree, it is almost always the policy that is out of date — a vendor was swapped a year ago and nobody told legal. Checking that the linked policy, the cookie list and the actual requests agree takes one crawl and settles the question that a regulator will otherwise ask you to answer under time pressure.