Skip to content

GDPR8 min

A cookie banner that blocks nothing: what we found and what we fixed

A banner on the page is not blocking. In this project the banner was there and requests still went out before consent. Below: what the measurements showed, why even the audit itself got three things wrong, and how to check your own site in ten minutes.

In short

  • 0 cookies and 0 third-party requests before consent
  • Withdrawal deletes the analytics cookies from the device
  • Cookie list rescanned logged out: 5 services, 17 cookies
  • Three audit findings turned out to be inaccurate, with evidence
  • All work on a copy; the live site was never touched

Where it started: an external audit with items to close

The client is a B2B consultancy. An external auditor reviewed their site and handed over a list of items. Two of them were about consent: a broken consent widget, and the question of whether the site really sends nothing to third parties before consent.

All the work was done on a full copy, not on the live site. Live stayed untouched until migration, and every finding was captured in screenshots and a network log. Without evidence, an audit is an opinion.

What we found: a permanent “Denied” label and a category that does not exist

The footer carried a consent widget stuck on “Current status: Denied”. The button label was an invisible character, and the surrounding container forced the status text to render. The same widget was duplicated across two templates, so the pages carried duplicate element IDs.

The banner offered a Marketing category the site does not use. It came from two false positives in the cookie scan: Google Fonts, which were in fact already served from the site's own server, and reCAPTCHA, which was not installed at all. Removing both entries made the category disappear on its own.

When the audit itself is wrong

Three of the audit's statements did not match the code. It reported the ad transparency framework as enabled. It was not, and on that version it could not be, because it is a paid feature. Leftover markup from it is hidden, and no visitor ever sees it.

The second statement was about visible consent placeholders: they render at zero height and are hidden. The same is true of the inactive categories, because the consent platform always outputs all four category templates and hides the unused ones. An auditor reading raw HTML will find them. This is exactly why an audit has to be measured in the browser rather than read out of the code.

How to check your own site in ten minutes

Open the site in a fresh private window. Before touching the banner, open the browser tools, go to Application, and count the cookies. Then check Network for requests to other domains. If even one analytics or advertising request is there, the banner is not blocking.

The second test is simpler still: accept, reload, then withdraw consent and count the cookies again. If the number has not changed, withdrawal is only a button. Want this measured and fixed? Audit €200, get in touch.

Five signs your cookie banner is not blocking

Answer for your own website. “Not sure” counts as a risk: what you don't know, nobody is checking.

  • Cookies are in the browser before anyone touches the banner.

    Private window, browser dev tools, Application tab. Correct: 0.

  • Before consent, the site contacts Google, Meta or other third-party servers.

    Network tab. Requests to your own domain are fine, to anyone else they are not.

  • After consent is withdrawn, analytics cookies stay in the browser.

    Accept, reload, withdraw and count again.

  • The cookie policy list does not match what is in the browser.

    Compare the names with the Application tab.

  • “Reject” is only in the settings, or less visible than “Accept”.

    Both choices belong in the same window, with equal weight.

Answer, and your result appears here.

Order an audit, €200

End

FAQ.

Next article

Meta ads report different purchases than your store