There’s a special kind of bug that’s invisible because everything looks right: the cookie banner that asks for consent, shows the buttons, stores the choice — and loads Google, Meta and analytics anyway, before you ever click, or regardless of whether you click “reject”. It looks compliant. It isn’t. And it’s the failure European regulators now look for first.
This is the privacy version of the gap we keep coming back to: it looks done, but it isn’t doing the one thing it claims to.
Why it happens (especially in vibe-coded apps)
Adding a cookie banner is a five-minute job: drop in a widget, it renders, it remembers the click. What it usually doesn’t do — and what almost no tutorial makes you wire up — is actually gate the scripts behind the choice. The tracking tags sit in the page and fire on load. The banner is a sticker over a door that’s already open.
European enforcement in 2026 has shifted to exactly this: not what your banner says, but whether your back-end behaviour matches it. A beautiful consent UI that doesn’t truly block non-essential cookies until consent is the textbook violation — and “we used a plugin” is not a defence.
How to check yours in two minutes
- Open your site in a private/incognito window.
- Open DevTools → Network tab, and filter for the usual suspects (
google,gtm,facebook,analytics). - Before clicking anything, reload. Do those requests fire? If yes, you’re tracking before consent.
- Now click Reject. Do they still fire? If yes, your “reject” does nothing.
If either step lights up, your banner is decorative. Real consent means nothing non-essential loads until the user opts in — and reject genuinely loads nothing.
What “real” looks like
The compliant pattern is block-until-consent (or Google Consent Mode with everything defaulted to denied): the analytics and ad tags are not in the page until the visitor accepts, and declining leaves them out entirely. Essential cookies — your session, CSRF protection — don’t need consent and stay. Everything else waits. It’s the same principle as the rest of going live with a vibe-coded app under GDPR: what your app actually does has to match what it tells users it does.
A banner that doesn’t block is the kind of thing that looks fine in every demo and only surfaces when someone — a regulator, a competitor, a privacy-savvy user — actually checks the network tab. A senior read checks whether your consent and data handling do what they claim, not just whether the UI renders. Looks compliant and is compliant are two different things — and only one of them holds up.