Why a Cookie Audit Matters More Than Ever
Every website sets cookies, yet most site owners cannot list every cookie their pages drop. That blind spot carries real financial risk. The CNIL issued combined fines exceeding 139 million euros between December 2022 and December 2024 for breaches of Article 82 of the French Data Protection Act, which implements Article 5(3) of the ePrivacy Directive. Google alone received a 325 million euro fine from the CNIL in September 2025 for cookie management violations.
A cookie audit is the foundation of any compliance programme. Without one, your cookie banner is guesswork.
The audit process covers three phases: discovery (finding every cookie), categorisation (classifying each cookie by purpose), and documentation (recording details for your cookie policy and DPA investigation readiness). Each phase has both manual and automated components. Skipping the manual checks leaves gaps that scanners miss, while relying solely on manual methods does not scale across large sites.
Phase 1: Discover Every Cookie on Your Site
Start with a clean browser profile. Open an incognito or private window, navigate to your homepage, and do not interact with any consent banner. Open Chrome DevTools (F12), switch to the Application tab, and expand the Cookies section in the left sidebar. Note every cookie present before any user interaction - these are cookies that load without consent, and under GDPR and ePrivacy rules, only strictly necessary cookies should appear at this stage.
Repeat this process across at least five representative pages: the homepage, a product or content page, a form page, the checkout or conversion page, and any page with embedded third-party content such as YouTube videos or social media widgets. Different pages often trigger different scripts and cookies.
Three Testing Scenarios
The EDPB Website Auditing Tool recommends testing under three distinct consent states. Run each scenario and record the cookies that appear:
| Scenario | User Action | What to Check |
|---|---|---|
| No interaction | Load the page without touching the banner | Only strictly necessary cookies should be present |
| Reject all | Click the reject or decline button | No analytics, marketing, or preference cookies should remain |
| Accept all | Click accept or allow all | Full cookie inventory - record every cookie that appears |
If cookies from _ga, _fbp, or other analytics and marketing cookies appear in the first two scenarios, your consent mechanism has a blocking problem. This is exactly what regulators test during investigations.
Manual vs Automated Scanning
Manual inspection using Chrome DevTools gives you granular control. You can observe the exact moment a cookie is set, identify which script creates it, and check its attributes (SameSite, Secure, HttpOnly, expiry). For a small site with five to ten pages, manual scanning may be sufficient.
Automated scanners crawl your entire site and report every cookie found across all pages. They catch cookies that only appear on specific URL paths or after particular user interactions. Tools like Kukie.io's free cookie scanner can detect cookies across your full site and automatically suggest categories.
The most thorough approach combines both. Run an automated scan first for breadth, then manually verify the results on key pages for accuracy.
Phase 2: Categorise Each Cookie
Once you have a complete list, assign each cookie to a standard category. The categories below align with the IAB TCF framework and most European DPA guidance:
| Category | Consent Required? | Examples |
|---|---|---|
| Strictly necessary | No (exempt under ePrivacy) | PHPSESSID, csrf_token, cart_id |
| Functional / Preferences | Yes (under GDPR/ePrivacy) | pll_language, timezone_offset |
| Analytics / Performance | Yes (with limited exceptions) | _ga, _ga_*, _hjSession |
| Marketing / Advertising | Yes | _fbp, _gcl_au, IDE |
The strictly necessary exemption is narrow. Article 5(3) of the ePrivacy Directive only exempts cookies that are strictly necessary for a service explicitly requested by the user. A session cookie that keeps a user logged in qualifies. An analytics cookie that measures page views does not - even if you consider it important for running your business.
Common Categorisation Mistakes
Misclassifying cookies is one of the most frequent compliance failures. Regulators specifically check whether cookies labelled as strictly necessary genuinely meet the legal test.
Do not classify analytics cookies as strictly necessary. The ICO, CNIL, and most European DPAs have confirmed that web analytics requires consent. The UK Data Use and Access Act introduced a limited analytics cookie exemption for UK-only sites, but this does not apply under EU rules.
Functional cookies such as language preferences sit in a grey area. While they improve user experience, they are not strictly necessary for delivering the service. Most DPAs require consent for these. If in doubt, require consent - over-classifying cookies as exempt is riskier than asking for permission.
Phase 3: Document Your Findings
Documentation serves two purposes: it feeds your public-facing cookie policy and provides evidence during a regulatory inquiry. For each cookie, record the following fields:
- Cookie name - the exact name as it appears in the browser (e.g.,
_ga) - Provider - the domain that sets it (first-party or third-party domain)
- Purpose - a plain-language description of what it does
- Category - strictly necessary, functional, analytics, or marketing
- Duration - session or persistent, with exact expiry for persistent cookies
- Type - HTTP cookie, localStorage, sessionStorage, or pixel/tag
- Data shared - whether data is sent to third parties
Keep this documentation in a structured format such as a spreadsheet or database. It needs to be updated every time you add a new tool, plugin, or tracking script to your site.
Third-Party Script Inventory
Cookies do not appear from nowhere. Each one originates from a script, tag, or pixel embedded on your site. Map every cookie back to the third-party script that creates it. This mapping is critical because removing or blocking a script is the actual mechanism for controlling cookies - you cannot block individual cookies without blocking the script that sets them.
Check your tag manager configuration. If you use Google Consent Mode v2, verify that tags fire only after the appropriate consent signal. If you use GTM, confirm your conditional loading setup matches the categories in your audit.
Setting Up Ongoing Monitoring
A single audit is a snapshot. Websites change constantly - new plugins, updated SDKs, redesigned pages. A cookie that did not exist last month may appear after a routine WordPress update or a marketing team member adding a new tracking pixel.
Schedule regular automated scans at a frequency that matches your release cycle. For most sites, weekly or fortnightly scans strike a good balance between vigilance and noise. Each scan should compare results against your documented cookie inventory and flag any new or changed cookies for review.
Set up alerts for unexpected cookies. An unknown third-party cookie appearing on your checkout page is a security concern as much as a compliance one.
What to Do with Audit Results
The audit output drives several downstream actions. Update your cookie banner categories to match your categorisation. Configure your CMP to block non-essential cookies until consent is granted. Update your cookie policy with accurate, current information about every cookie.
Review your data processing agreements with third-party vendors whose scripts set cookies on your site. Under GDPR Article 28, you need a DPA with each processor. If a vendor's cookie falls into the marketing category, your visitors' consent must cover that specific purpose.
Share the audit results with your development team. They need to know which scripts require consent-gating and which can load freely. Provide them with the category-to-script mapping so they can configure the tag manager or script loader correctly.
Common Pitfalls to Avoid
Auditing only the homepage is insufficient. Cookies vary by page, and regulators test multiple pages during investigations.
Ignoring non-cookie storage is a growing risk. The EDPB's October 2024 guidelines on the technical scope of Article 5(3) confirmed that local storage, session storage, and pixel tags all fall within the same consent requirements as cookies. Your audit should capture these technologies too.
Forgetting to test the reject scenario leaves a dangerous gap. The CNIL fined 11 organisations in 2024 specifically for not allowing users to refuse cookies as easily as accepting them. If cookies persist after a user clicks reject, your entire consent mechanism fails the basic compliance test.
Treating the audit as a one-off exercise rather than an ongoing process means your compliance degrades over time. Every site change is a potential new cookie.
Frequently Asked Questions
How often should I run a cookie audit on my website?
Run a full manual audit at least quarterly, with automated scans running weekly or fortnightly. Trigger an additional audit whenever you add a new third-party tool, update a plugin, or redesign a section of your site.
Can I use a free tool to scan my website for cookies?
Yes, free scanners provide a useful starting point. They crawl your pages and list detected cookies. Pair the automated scan with manual DevTools checks to catch cookies that only appear after specific user interactions or on authenticated pages.
What happens if my cookie audit finds cookies I did not know about?
Unknown cookies typically come from third-party scripts, plugins, or embedded content. Identify the source script, classify the cookie, and either add it to your consent categories or remove the script if it is no longer needed.
Do I need to audit local storage and session storage as well as cookies?
Yes. The EDPB confirmed in 2024 that Article 5(3) of the ePrivacy Directive applies to all information stored on or accessed from a user's device, not just HTTP cookies. Local storage, session storage, and IndexedDB all fall within scope.
Is a cookie audit required by GDPR?
GDPR does not explicitly mandate a cookie audit, but Articles 5, 24, and 30 require you to know what personal data you process and demonstrate compliance. A cookie audit is the practical way to meet these obligations for your website.
What is the difference between first-party and third-party cookies in an audit?
First-party cookies are set by your own domain. Third-party cookies come from external domains loaded via scripts, pixels, or iframes on your pages. Third-party cookies carry higher compliance risk because data leaves your control.
Take Control of Your Cookie Compliance
If you are not sure which cookies your site sets, start with a free scan. Kukie.io detects, categorises, and helps you manage every cookie - so your visitors get a clear choice, and you stay on the right side of the law.
