Your cookie banner might not be blocking anything

Most website owners judge their cookie banner by one thing: does it appear? It does, visitors click it, and the job feels done.

But a banner is a question. What matters is whether the answer is respected — whether anything that tracks visitors waits for that answer. On a lot of sites it does not, and nobody notices, because nothing looks wrong.

1. The tags fire first

Analytics and ad pixels are usually loaded with the page. By the time the banner has drawn itself on screen, the browser has already fetched those scripts and they have already sent their first request.

The visitor is being asked a question that has already been answered for them.

A consent tool can only hold a script back if it runs before that script. That is why CookieRay’s tag goes as high in <head> as possible, and why it is not loaded with async or defer.

2. Scripts pasted into the HTML

Scripts from well-known tracking companies can be recognised by their address and held automatically. A script written straight into your theme’s HTML is different: the browser starts fetching it the moment it reads the line, before any banner can step in.

The fix is small. Turn the script into something the browser will not run, and tell the consent tool which category it belongs to:

<script type="text/plain" data-cmp="analytical" data-cmp-src="https://example.com/analytics.js"></script>

When the visitor accepts Analytics, the script is switched back on. Until then, it is inert. The blocking guide has the details.

3. “Log only” mode

Many consent tools — CookieRay included — start in a mode that records answers but blocks nothing. That is deliberate: a first install should never break a site.

It is also easy to forget. A banner in log-only mode collects answers while every tracker keeps running. The record looks like consent; the behaviour is not. Switching to Strict is the step that makes the banner mean something.

Your site changes without you

Even a site that was set up correctly drifts. A marketing team adds a pixel. A theme update ships a new script. A plugin starts loading a chat widget. Nobody tells the person responsible, and the site that held everything back in March does not in September.

That is what scheduled scans are for: the site is opened in a real browser on a schedule, and you are told only when something new turns up.

How to check

The quickest way to know is to look. A scan opens your pages in a real browser and lists every cookie and every third-party request it sees — which is the honest version of the question “is my banner working?”

Start a free account and scan your site, or read the quick start to set up blocking properly.

This article explains how consent tools work; it is not legal advice.