What is a GDPR cookie audit? (And how to pass one in 2026)

The GDPR is now eight years old, and yet the most common compliance failure on SMB websites is still the cookie banner. Every regulator in the EU has guidance on it; most have issued at least one fine for non-compliance. The bar is not high, it is just specific, and most banners fail on details that look small but matter.

A GDPR cookie audit is the structured check that tells you whether your site would survive scrutiny from the CNIL, the ICO, the Italian Garante, the Irish DPC, or any of their counterparts. This article walks through what the audit actually does, the rules it applies, and the failures we see most often on SMB sites.

The legal foundation (in plain English)

Two laws apply. The ePrivacy Directive (Article 5(3), the “cookie rule”) requires consent before any non-strictly-necessary information is stored on or read from a user’s device. The GDPR defines what valid consent looks like (Article 4(11), Article 7): freely given, specific, informed, unambiguous, and revocable as easily as it was given.

Stitched together, the rule is straightforward. Before you set or read a non-essential cookie, before you fire a tracking pixel, before you load a third-party script that does either, you need to ask. The user must be able to refuse without penalty, in one click, and to change their mind later just as easily.

What an audit checks, step by step

1. First-page-load network capture

The audit visits your site as a fresh user and records every cookie set, every localStorage write, and every network request fired before the user interacts with the consent banner. Anything non-essential firing here is a violation. This is the single highest-yield check, it catches the majority of real failures on SMB sites.

2. Cookie and storage inventory

The audit lists every cookie your site sets and every storage key it writes, together with the domain that set each one. That is the whole of it: we record names and domains, never values, and a cookie’s declared lifetime and purpose are not visible from the wire, so we do not report duration or purpose. We also do not grade your cookie policy against the list, because a declared-versus-observed comparison is a reading exercise, not a machine check. Do it yourself, with our inventory on one screen and your policy on the other. Most SMB cookie policies are stale templates, and regulators read them.

3. Banner-design check

Regulators have called out five banner patterns. Two of them can be judged from the banner’s markup, and Veracly checks those automatically:

• Equal-weight Accept/Reject. If “Accept all” is a prominent button and “Reject” is hidden in a settings link, the consent is not freely given. On 31 December 2021 the CNIL fined Google €150M and Facebook Ireland €60M for exactly this. We compare the two controls as they sit in the DOM, their kind, their visibility, and their visual weight. It is an inspection of the design, not a test of what happens after a click.
• No pre-ticked boxes. Every category, analytics, marketing, functional, must default to off.

The other three matter just as much and cannot be settled from a single snapshot of the page. Walk them yourself:

• Granular categories. A single “accept everything” switch is no longer enough; users must be able to consent to analytics without consenting to advertising.
• Withdrawal as easy as consent. A persistent “Cookie settings” link in the footer, opening the same banner, is the standard.
• No dark patterns. No countdowns, no “continued use of this site means consent,” no “legitimate interest” toggles for advertising.

4. Consent-record proof

The GDPR requires you to be able to prove, for every visitor, that consent was given and what it covered. A modern Consent Management Platform (CMP) does this for you; home-rolled banners almost never do.

5. Third-party script behaviour

Veracly captures every third-party script, cookie, and storage write that fires before any consent gesture, the pre-consent state regulators care about most. We never click your banner, and that is deliberate: a click is itself a consent gesture, and it would pollute the reading we came for. It also means we run no post-consent pass. To confirm that scripts respect a choice once it’s made, repeat each path yourself, “Accept all,” “Reject all,” and any granular partial consent, in a fresh private window with the Network tab open. The most common failure here: a script that loads anyway after “Reject,” often because a tag manager fires it on the wrong trigger.

The failures we see most often on SMB sites

Meta Pixel firing on page load. By far the most common. The Meta Pixel installation guide tells you to drop the snippet in <head>; the snippet fires immediately. In the EU, that’s a violation on every visit. The fix is to either gate the snippet behind your CMP or use Meta’s consent-mode tags.

Google Analytics with no consent gate. GA4 has a consent-mode v2 that most SMBs do not configure. The audit catches it because the script fires regardless of the banner’s state.

Hotjar / Microsoft Clarity / Hubspot recording before consent. Session recorders are particularly sensitive, they capture what the user types, where they move the mouse, and personal data revealed in the page DOM. They cannot run pre-consent without a clear ePrivacy violation.

YouTube embeds in privacy mode but not really. youtube-nocookie.com reduces tracking but still sets cookies and contacts Google. Some regulators accept this as “essential” for video content; most require consent for embeds.

The “continued use of this site” banner. Implied consent has been explicitly rejected by every EU regulator. If your banner uses that phrasing, replace it today.

How to pass the audit

The fix list, in priority order, is the same on most SMB sites:

1. Install a real CMP that records consent (not just a banner that hides). Cookiebot, Usercentrics, Iubenda, OneTrust, and Termly all work; pick one that integrates with your stack.
2. Move every analytics, advertising, and session-recording script behind the CMP’s consent gate. In Google Tag Manager, this means using consent triggers; in plain HTML, it means deferring the script until the CMP fires its “granted” event.
3. Replace the existing banner with one that has equal-weight Accept and Reject, no pre-ticked categories, and granular toggles.
4. Add a persistent “Cookie settings” link in the footer.
5. Regenerate the cookie policy so it lists what your site actually sets.
6. Re-scan for the pre-consent state, then walk the Accept and Reject paths yourself in a private window.

Why continuous scanning matters here

Cookie compliance breaks silently. Marketing adds a new tag in GTM, a developer drops in a chat widget, a third party updates their script and starts setting a cookie they didn’t before. None of these will trigger an alert in your existing tooling. The audit pattern that works for SMBs is: a baseline scan, fixes, then scheduled re-scans that rebuild the cookie inventory from scratch, so anything new shows up in the next report.

Veracly does this, a free baseline scan of one page, then scheduled re-scans on the paid plans. Be precise about the alerting, because we are: you get an email when a report is ready, and an alert when your average score drops by more than the threshold you set. We do not yet diff finding sets or tracker inventories between scans, so a newly added tracker reaches you as a score drop and as a line in the next report, not as a “new tracker” notification. Run a scan and see your site as a regulator would see it.

See also: What is a cookie banner audit? · Tracking pixel audit: GDPR & ePrivacy · What is a website compliance audit?