We've scanned thousands of websites with ComplyTest, and the results are consistently striking: the majority of sites that display a cookie consent banner are still non-compliant. Not because they're missing a banner — most have one — but because the banner doesn't actually work as the GDPR requires.
What's surprising is that some of the most egregious violations come from sites selling compliance tools. We're talking about Cookiebot's own website, OneTrust's marketing pages, Monsido, and Deque Systems — companies whose entire business proposition is helping others achieve compliance. If the cobbler's children have no shoes, you at least have some idea of how hard this problem is.
Here are the seven most common mistakes, drawn directly from our scan data, with real examples and specific fixes.
Mistake 1: Setting Cookies Before Consent
What it is: Non-essential cookies — analytics, advertising, tracking pixels — fire before the user has made any choice on the consent banner. The banner is displayed, but cookies are already being set in the background.
Why it's a violation: GDPR Article 7 and Recital 32 require that consent be obtained before processing begins, not simultaneously or after. If your analytics tracker fires on page load before any click, you've already processed personal data without a legal basis.
What we find in the real world: This is the single most common technical violation in our dataset. When we scanned Cookiebot's own website, analytics cookies were present in network requests before any consent interaction had occurred. OneTrust's marketing site showed similar behavior with third-party scripts initializing on load.
How to fix it: Your tag manager or consent management platform should block all non-essential scripts until the user has affirmatively accepted. Use a script blocking approach (not just cookie blocking — some trackers use localStorage or fingerprinting). Test with your browser's network tab open: on first visit, with no prior consent record, the only requests you should see are for essential functionality.
Mistake 2: No Reject Button (or Hiding It)
What it is: The consent banner offers an "Accept All" button prominently but makes rejecting difficult — either by hiding a reject option behind a "Manage Preferences" flow, or by not offering one at all.
Why it's a violation: The Article 29 Working Party (now the EDPB) has been clear since 2018: if it takes more steps to reject than to accept, consent is not freely given. The French CNIL has fined multiple organizations specifically for this design pattern.
What we find in the real world: Monsido's website has no reject button on its consent banner. Users who want to decline non-essential cookies are not given a direct path to do so. This is not an obscure edge case — it's the banner presented to every visitor.
How to fix it: Place an "Accept" and "Reject All" button at the same level of interaction. If you want to offer granular controls, you can have a third "Manage Preferences" option, but "Accept" and "Reject All" must be equally accessible without any additional clicks.
Mistake 3: Pre-Checked Consent Boxes
What it is: Granular cookie preference panels where non-essential cookie categories are checked by default, so that a user who clicks through without unchecking anything has "consented."
Why it's a violation: The Planet49 ruling (CJEU, October 2019) definitively settled this: pre-ticked boxes do not constitute valid consent under the GDPR. Consent requires an active, affirmative act — a box that was already ticked is not one.
What we find in the real world: This pattern persists in older consent management platform configurations, particularly in the "Functional" and "Performance" cookie categories where vendors argue a legitimate interest exists. The argument doesn't hold — if you're asking for consent, the boxes start unchecked.
How to fix it: All non-essential categories in your preference center must default to off (unchecked, toggled off, deselected). Only strictly necessary cookies, which don't require consent at all, can be pre-enabled and should be non-interactive to make this distinction clear.
Mistake 4: Dark Patterns — Visual Parity Failures
What it is: The "Accept" button is styled to draw attention — large, brightly colored, prominent — while the "Reject" or "Manage Preferences" option is rendered as grey text, a small link, or visually de-emphasized to the point of near-invisibility.
Why it's a violation: The EDPB's Guidelines 3/2022 on Dark Patterns explicitly identify this as a "hidden in plain sight" pattern that undermines the validity of consent. If the visual design of your banner makes one choice significantly more salient than another, consent is not freely given.
What we find in the real world: This is extremely common. A typical offending banner has a bright green "Accept All" button spanning the full width of the banner, with "Cookie Settings" in small grey text below it. The visual hierarchy does all the work that the pre-checked boxes used to do.
How to fix it: Accept and Reject must have the same button style, size, and color weight. Both should be presented as buttons, not as a button and a link. Run your banner through a color contrast and visual hierarchy check — if a user's eye is drawn to Accept before they consciously choose, redesign it.
Mistake 5: No Withdrawal Mechanism
What it is: Once a user has accepted cookies, there is no persistent, accessible way to change their preferences or withdraw consent.
Why it's a violation: GDPR Article 7(3) states that withdrawal of consent must be as easy as giving it. If there's a one-click "Accept All" on the banner but no way to undo that choice without clearing browser cookies, you've failed this requirement.
What we find in the real world: Many sites bury the consent management link or don't include it at all after the initial banner is dismissed. Some link to it only from within the privacy policy, which is itself not easily findable.
How to fix it: Place a "Cookie Settings" or "Manage Consent" link in your site footer, visible on every page. When a user changes their preferences to withdraw previously given consent, your CMP must immediately stop the processing for the deselected categories — including firing a tag manager trigger that removes or blocks the relevant scripts for the remainder of the session.
Mistake 6: Vague Cookie Descriptions
What it is: Cookie purposes are described in generic, meaningless language that doesn't tell the user what data is being collected, by whom, or why.
Why it's a violation: GDPR Article 5(1)(a) requires transparency. Informed consent requires that users understand what they're consenting to. "These cookies help us improve your browsing experience" describes nothing. The EDPB has stated that descriptions must be specific enough for the user to understand the concrete implications of consenting.
What we find in the real world: Cookie banners describing "Analytics cookies" as improving "site performance" without naming the analytics provider, describing the data collected (session duration, pages visited, IP-derived location), or explaining the retention period.
How to fix it: For each cookie category, provide: the specific third-party vendors involved by name, what data each vendor collects, how long that data is retained, and a link to each vendor's own privacy policy. This is more work to maintain, but it's what the regulation actually requires.
Mistake 7: Not Testing Whether Consent Actually Works
What it is: The consent banner looks correct and is technically configured, but clicking "Reject All" doesn't actually prevent trackers from firing.
Why it's a violation: A consent mechanism that doesn't function is worse than no consent mechanism at all — it creates a false paper trail of "user consented to nothing" while data is still being collected.
What we find in the real world: This is one of the most striking findings from our scans. On Deque Systems' website — a company that sells web accessibility and compliance tooling — our scanner detected analytics tracking continuing to function after a reject interaction. The consent banner went through all the right motions, but the underlying script blocking was not working correctly.
How to fix it: After implementing your CMP, run a proper technical test: open a fresh browser profile with no existing cookies, visit your site, click "Reject All," then inspect the network tab for tracking requests (Google Analytics, Facebook Pixel, LinkedIn Insight Tag, etc.). None should appear. Repeat this test after any change to your tag manager setup, CMP configuration, or consent banner. Add it to your deployment checklist.
Testing Your Cookie Consent
The only way to know whether your cookie consent is working correctly is to test it — not by reading your CMP's documentation, but by actually scanning the live behavior of your site.
npx complytest scan https://your-site.com
ComplyTest's cookie consent rules check pre-consent firing, banner visual parity, reject button presence, withdrawal mechanism accessibility, and post-reject tracker behavior — the seven categories above — as part of a single automated scan.
See how your site scores. Complicer runs ComplyTest on every deployment so you catch consent regressions before they become enforcement findings.