Why you should audit your cookie consent (even if you have a CMP)
Having a cookie consent banner doesn't mean you're compliant. We've seen hundreds of websites where the banner looks fine but the implementation is broken: scripts load before consent, the reject button doesn't actually block cookies, or Consent Mode signals never reach Google.
Regulators don't check whether you have a banner. They check whether it works. Here's how to check the same things they do.
The 10-point audit
You can run this audit in 30 minutes with nothing more than your browser's DevTools. Open your website in Chrome (or any Chromium browser), clear all cookies, and work through each check.
Cookie consent audit checklist
1
Check 1: Does the banner appear before any non-essential cookies are set?
Open DevTools > Application > Cookies. Clear all cookies. Reload the page. Before you interact with the banner, check the cookies list. You should see ONLY strictly necessary cookies (session IDs, CSRF tokens, load balancer cookies). If you see _ga, _fbp, _gcl_au, or any analytics/marketing cookies, your site is tracking before consent. That's the number one violation regulators catch.
2
Check 2: Does 'Reject all' actually work?
Click 'Reject all' (or its equivalent). Now check cookies again. No new analytics or marketing cookies should appear. Navigate to a few pages. Check again. If cookies appear after rejection, your blocking isn't working. Also check the Network tab for requests to google-analytics.com, facebook.com, or other tracking domains. If those fire after rejection, you have a leak.
3
Check 3: Is rejecting as easy as accepting?
Count the clicks. If 'Accept all' takes 1 click but rejecting requires opening settings and toggling each category, that's a dark pattern. EDPB guidelines require equal prominence. Both 'Accept all' and 'Reject all' should be visible on the first layer of the banner with the same visual weight.
4
Check 4: Does the banner explain what you're consenting to?
The banner should clearly state what cookie categories exist, what each category does (in plain language), and link to your cookie policy. Vague text like 'we use cookies to improve your experience' is not sufficient. Each category needs a real description.
5
Check 5: Does consent persist across pages?
Accept cookies, then navigate to several other pages. The banner should not reappear. Check that the consent cookie is set with an appropriate expiry (6-12 months, not session-only). Clear just the consent cookie and reload. The banner should reappear.
6
Check 6: Is Google Consent Mode firing correctly?
Install Google Tag Assistant (Chrome extension). Load the page. Before interacting with the banner, check that consent default signals appear with all types set to 'denied' for EEA visitors. After accepting, check that consent update signals fire with the correct types set to 'granted.' If you see no consent signals at all, your Consent Mode integration is broken.
7
Check 7: Are consent records being stored?
Check your CMP's dashboard for consent log entries. Each consent action (accept, reject, customize) should generate a record with a timestamp, consent ID, and the specific choices made. If your consent logs are empty or missing, you can't prove consent was given, which is a GDPR requirement.
8
Check 8: Does the floating settings button work?
After dismissing the banner, look for a small privacy icon or 'Cookie Settings' button (usually in a corner of the screen). Click it. It should reopen the preference center and let you change your choices. If there's no way to change consent after the initial choice, that's a violation. Consent must be withdrawable.
9
Check 9: Does regional behavior work correctly?
If you serve visitors globally, test with a VPN. From a German IP, you should see GDPR opt-in (everything denied by default). From a California IP, you should see CCPA opt-out ('Do Not Sell' option). From a country with no privacy law, the behavior depends on your policy. If all visitors see the same banner regardless of location, you're either over-consenting (annoying) or under-consenting (non-compliant).
10
Check 10: Are all cookies accounted for in your categories?
Compare the cookies you found in Check 1 and Check 2 with the categories listed in your banner's preference center. Every cookie should belong to a declared category. Unknown or uncategorized cookies are a gap. Run CookieBeam's scanner or a similar tool to find cookies you might have missed.
What to do if you find problems
Most audit failures come from one of three root causes:
- Scripts loading before consent: Your consent banner's script tag needs to load before any tracking tags. If you're using Google Tag Manager, make sure the consent default fires in a Consent Initialization trigger, not on All Pages.
- Reject not actually blocking: Your CMP needs to intercept and block scripts, not just set a flag. Check that your tracking scripts are conditional on consent, not just documented in the cookie policy.
- Missing Consent Mode signals: If you're using Google tags without Consent Mode, Google doesn't know about the consent state. Your CMP should fire gtag consent commands automatically.
CookieBeam handles all three automatically: scripts are blocked before consent, the reject action genuinely prevents tracking, and Consent Mode signals fire for Google, Microsoft, and Meta without manual configuration.
How often should I run a cookie consent audit?
At minimum quarterly. Ideally monthly, or after any significant website change (new marketing tools, CMS updates, redesigns). Automated scanning tools like CookieBeam's scanner can do this continuously.
Can I use browser extensions to audit my cookie consent?
Yes. Google Tag Assistant helps verify Consent Mode. The 'Edit This Cookie' extension lets you inspect cookies easily. The CookieServe scanner provides a basic audit. But for a comprehensive check, use DevTools and follow the 10-point checklist above.
What's the most common audit failure?
Scripts loading before consent. In most cases, the banner looks correct and the buttons work, but Google Analytics or Facebook Pixel loads before the visitor has a chance to choose. This is invisible to the user but clearly visible in DevTools and to regulators.