Cookie consent checker

Consent has to be given before anything non-essential runs, freely, specifically and unambiguously. In practice that rules out several things people still ship: pre-ticked boxes, a banner that treats continued scrolling as agreement, a design where Accept is a button and Reject is a link three clicks away, and a wall that makes the site unusable until someone agrees to tracking.

It also has to be reversible. Someone who agreed in January needs a way to change their mind in March, which means a persistent link somewhere ordinary rather than a banner that never returns. Withdrawing consent should be as easy as giving it, and the tags should stop when it is withdrawn rather than continuing until the cookie expires.

Granularity is the part homemade banners usually miss. Analytics, personalisation and advertising are separate purposes, and someone can reasonably accept one and refuse another. If you are serving ads through Google, the certified platform requirement is doing this work for you, which is a good reason to use one even where you would rather not.

A consent platform is the one third-party script you cannot defer, because everything it gates has to wait for it. It loads early, it blocks, and on a slow connection the banner arrives visibly after the text does. That makes it the heaviest script on many otherwise light sites, and it is worth measuring against the load time rather than assuming it is free.

The layout cost is just as real. A banner injected after render shifts everything below it, which is exactly what the layout shift metric penalises, and on a phone the combination of a sticky header, the banner and a floating button can leave almost no readable area. Reserving the space the banner will occupy, rather than letting it push the page down, fixes most of that.

Then there is the data. Once tracking is properly gated, analytics stops recording the visitors who declined, so the numbers drop on the day it is implemented and that drop is not a bug. Wiring the consent signal through to your tag setup, rather than simply blocking the scripts, is what keeps the modelling and the reporting coherent afterwards. The policy audit checks the mechanism rather than the appearance for this reason: a banner that changed nothing about what fires has cost you performance and bought you nothing.

You can test the thing that actually matters in five minutes with a browser. Open a private window, open developer tools on the network panel, load your site, and touch nothing. Read the request list before you make any choice on the banner: requests to googletagmanager, google-analytics, doubleclick, facebook or any other tracking domain at this point mean the tags are not gated, whatever the banner says. Then check the application panel's cookie list, a _ga cookie sitting there before you have clicked anything is the failure in one line.

Now exercise both paths. Click reject, reload, and confirm the tracking requests stay absent, not just the banner. Clear the site's cookies, accept instead, and confirm the tags now appear, so consent actually connects to something. While you are in the banner, count the clicks: if accepting is one click and refusing is a journey through a preferences screen, the design is the kind regulators have explicitly called out, whatever the wiring says.

When the test fails, the cause is usually one of three wirings. An analytics snippet pasted directly into the page template fires unconditionally, no matter how correctly the consent platform is configured, because nothing connects them. A consent tool running in advanced consent mode sends cookieless pings to Google even before consent, by design, which is a configuration you should be running knowingly rather than discovering. And some themes ship a built-in banner that only hides itself on click, gating nothing, which is decoration rather than consent.

The fix is always the same shape: every tag routes through the consent platform's integration, none is pasted raw into the template, and the test above is repeated after every new tool is added, because the tag you add in November is not covered by the wiring you verified in June. The policy audit runs this same logic from the outside, the privacy policy has to describe what the mechanism actually does, and the banner's weight belongs in the performance budget, since it is the one script that legitimately refuses to be deferred.