Most teams check GDPR compliance the same way: they open the site in an incognito window, see a cookie banner appear, click around, and conclude "we have consent covered." Their cookie scanner agrees — it lists the trackers, categorises them, and prints a tidy report.
Both of those checks answer the same shallow question: does a banner exist?
Neither answers the question a regulator actually asks: does the banner work? Specifically — can a visitor refuse non-essential cookies as easily as they can accept them? Under the GDPR and ePrivacy guidance, consent must be freely given, which in practice means a first-level "Reject" must be as available as "Accept." A banner that only offers "Accept" (or buries refusal two clicks deep) is not consent. It is the appearance of consent.
This is the gap between "banner exists" and "banner works." Cookie scanners live entirely on the wrong side of it.
What a cookie scanner measures
A cookie scanner loads your page, enumerates the cookies and storage entries, and matches them against a database of known trackers. That is genuinely useful for building a cookie inventory. But notice what it never does: it never interacts with your consent banner. It does not click Reject. It does not check whether Reject even exists. It cannot, because measuring tracker presence and measuring consent behaviour are two different jobs.
So a scanner can hand you a clean-looking report for a site whose consent banner is, in regulatory terms, broken. The report is accurate. It is also answering the wrong question.
What an effectiveness audit measures
Our engine does the thing a scanner skips: it drives a real browser, finds the consent banner, and then tries to click Reject and Accept separately, recording what actually happens. For each run it records a banner status (was a banner served?), a click status (could the engine find and click the Reject / Accept control?), and — critically — a verification signal (did the page actually change its consent state afterwards: banner disappeared, consent storage changed, a TCF tcString was written, or a success message appeared).
The discipline that makes this a moat: we only claim a consent flow is "verified" when Reject AND Accept were both clicked and at least one signal confirms the behaviour. When we cannot prove it — no Reject button, banner served behind an iframe we cannot reach, the site blocks the probe — we say why instead of overclaiming. Honest classification beats a green checkmark that means nothing.
Here is what that looks like on real, well-known European sites.
Le Monde: banner present, Accept works, Reject is not there
We ran lemonde.fr through the engine on two separate passes — one trying to reject, one trying to accept.
On the Accept pass, the banner was served, the engine found and clicked the Accept control, and the banner disappeared afterwards — a confirmed consent change.
On the Reject pass, the same banner was served — but the engine could not find a first-level Reject control at all.
In the engine's own words, the Reject run recorded bannerStatus: found and clickStatus: not_found. Because Reject was never clickable, the engine refused to mark the consent flow verified, recording the reason as reject_not_clicked. A cookie scanner would have shown this site a clean report. The audit shows the actual problem: you can say yes in one click, but there is no equally easy way to say no.
Spiegel and Süddeutsche: the same pattern, at scale
This is not a Le Monde quirk. We probed major German news sites directly — spiegel.de and sueddeutsche.de — and saw the same shape: a consent wall is served, but the first-level interaction the visitor is steered toward is Accept. The full-page captures below are the engine's direct, non-proxied view of each site's consent wall as a real visitor first encounters it.
These are some of the most-visited publishers in Europe. They have legal teams. They have CMP vendors. And the consent flow still steers visitors toward "Accept" while making refusal harder — exactly the failure mode that a tracker-counting scan is structurally blind to.
Why "we have a CMP" is not the answer
Buying a consent management platform installs a banner. It does not guarantee the banner is configured so refusal is first-level and effective. The two failure modes we see most often:
- No first-level Reject. Accept is one click; refusal requires opening a "manage preferences" panel — or is absent entirely. (This is the Le Monde case above.)
- The banner the scanner can see is not the banner the user must defeat. The CMP renders inside a cross-origin iframe, so a scanner that only inspects the parent document reports "no banner / no trackers" while a real visitor is stopped by a wall.
In both cases the scanner's report and the regulator's view diverge. The scanner says fine. The audit says the consent is not freely given.
How to check your own site
You do not need to take our word for it — run the same Reject-vs-Accept check yourself. The free ComplyTest CLI drives a real browser and reports per-rule pass/fail, including consent interaction:
npx complytest scan https://your-site.com
If you want the full effectiveness audit — both passes, the verification signals, and the honest classification when behaviour cannot be proven — that is what Complicer does on top of the CLI's deterministic rules.
The takeaway
A cookie scan and a compliance audit are not the same product, and the difference is not cosmetic. One counts trackers. The other tests whether a visitor can actually refuse them. If your only evidence of "consent compliance" is a scanner report or the fact that a banner appears, you have measured that a banner exists — not that it works. On the sites above, those two answers were not the same.