Building It and Proving It Are Different Jobs
A 2023 study of thousands of EU sites found that most cookie banners still didn't meet the rules, and that hasn't changed much. The reason is rarely ignorance of the law. It's that teams build a banner, see it appear, and ship it without ever confirming it does what it claims. A banner with perfect buttons that lets analytics load anyway fails. So does one where "reject" is a grey link under a bright "accept" button.
This is a QA pass, run it after the banner is built and before (and after) every launch. Most of it happens in your browser's developer tools. For the failure patterns behind these checks, see why cookie banners fail compliance.
The QA pass
Load with a clean slate and watch the Network tab
Open a fresh private window, load the page, and don't touch the banner. In DevTools, check Application (cookies, local/session storage) and the Network tab. Anything non-essential present or firing at this point is a failure: it ran before consent.
Confirm reject-all exists and is equal to accept-all
On the first layer, "reject all" must sit beside "accept all" with equal prominence, same size, same visual weight, no grey-on-grey link versus a bright button. The EDPB's Cookie Banner Taskforce made this a baseline requirement.
Check for pre-ticked boxes
Every non-essential category toggle must default to off. A pre-selected box is invalid consent, settled by the CJEU in Planet49. Open the preferences panel and confirm nothing is on by default except strictly necessary.
Prove reject actually blocks
Click reject, reload, and re-check storage and the network. If an analytics or marketing cookie shows up after you declined, the banner's buttons aren't wired to the blocking. This is the test that catches decorative banners.
Confirm the choice is recorded
A consent decision you can't produce later isn't proof. Check that accepting and rejecting both write a consent record (timestamp, categories, version). See proof of consent.
Test re-consent on return and expiry
Reload as a returning visitor: the banner should stay hidden and the prior choice re-apply. Then confirm consent has a sensible expiry so it isn't treated as permanent, covered in consent expiry and re-consent.
The Button Rules, in Detail
The EU authorities converged on a short list through the EDPB's Cookie Banner Taskforce. Test each against your banner:
- Same-layer reject. If accept-all is on the first layer, reject-all has to be there too. Burying rejection one click deeper is a documented dark pattern.
- Equal prominence. Colour, contrast, and size must not steer the visitor toward accepting. A green "accept" next to a faint grey "reject" fails.
- No pre-selection. Toggles for analytics and marketing start off.
- No deceptive wording. "Reject" should reject, not "manage preferences" that leads to a maze.
If any of these feel like a grey area on your banner, they're a finding. Cross-check against cookie banner dark patterns.
The US Layer: Opt-Out Signals
If you have California or other US-state traffic, add one test the EU checklist misses. Under the CCPA, businesses must honour opt-out preference signals like Global Privacy Control (GPC), and as of January 2026 California's rules expect you to show that the signal was recognized. The regulator has been active: California, Colorado, and Connecticut launched a joint investigation into businesses ignoring these signals, and one retailer was fined for failing to honour GPC.
To test it, install a browser that sends GPC (or a GPC extension), load your site, and confirm your banner reads the signal and reflects an opt-out state without the visitor clicking anything. Details in Global Privacy Control explained and universal opt-out mechanisms.
The Tests People Skip
The homepage-accept-reload cycle catches the obvious failures. These are the ones that pass a quick look and fail an audit:
- Scroll-triggered tags. Some trackers fire on scroll, on a delay, or after a form interaction, not at page load. Reject, then actually use the page, and re-check the network.
- Second-page loads. A tag might respect consent on the homepage but fire on a product or article page that loads a different embed. Test more than one template.
- The banner that reappears. If the banner shows again on the next visit, the choice wasn't stored, which means you also can't prove it later. Confirm the choice persisted; a banner that merely closed is no evidence it was saved.
- Consent recorded but not enforced. A record can be written while the block silently fails. Verify both the log entry and the absence of the tracker, they're separate checks.
Run these on a real device and a throttled connection too. A race between the CMP and an eager tracker can look fine on fast broadband and leak on mobile.
Cookie banner QA checklist
No non-essential cookies or requests before a choice
Verified in a clean private window via the Network and Application tabs.
Reject-all is on the same layer as accept-all
EDPB Cookie Banner Taskforce baseline.
Reject and accept have equal prominence
No colour or size steering toward acceptance.
No pre-ticked non-essential boxes
Invalid consent per Planet49 (CJEU C-673/17).
Reject actually blocks the trackers
Re-check storage and network after clicking reject.
Every decision writes a consent record
Timestamp, categories, and policy version you can produce.
Return visits re-apply the prior choice
The banner stays hidden until expiry or withdrawal.
GPC / opt-out signals are honored automatically
Required for US-state traffic; California expects visible confirmation.
Tested across browsers and on mobile
Layout and blocking behave the same on small screens.
Automate the Regression
A banner that passed QA at launch can regress the moment someone adds a tag or ships a redesign. Pair this manual pass with continuous scanning so a new tracker firing pre-consent is flagged automatically, and re-run the button checks after any change to the banner. Use the full compliance checklist as the launch gate.