A cookie audit identifies, classifies and documents every cookie and tracker your website actually sets. It is the first step of any GDPR compliance effort: without knowing what your site really does, you cannot write a reliable cookie policy, configure your consent banner correctly or demonstrate compliance during an inspection. This guide covers the full method, how scanners work, which tools to use, how to read the results and the mistakes that make an audit worthless.
What is a cookie audit?
A cookie audit is a technical inventory of all cookies and trackers set on a visitor's device while they browse your site. It covers first-party cookies (set by your own domain) and third-party cookies (set by integrated services such as Google Analytics, Meta Pixel, chat tools or embedded video players), along with similar technologies such as localStorage and sessionStorage entries or tracking pixels, which fall under the same rules.
Listing cookie names is not enough. A useful audit answers three questions:
- Which trackers are present? Name, domain, lifespan and the script that triggers each one.
- Who sets them? Your site or a third party, and for which purpose.
- Are they blocked before consent? Non-essential trackers must not run until the visitor agrees.
A complete audit produces the list of active cookies with their GDPR classification (strictly necessary, analytics, advertising, personalisation or social media), a check of behaviour before consent and after refusal, and enough documentation to write your cookie policy and answer a supervisory authority.
Why audit your website's cookies?
Legal obligation. The GDPR and the ePrivacy Directive only allow non-essential cookies after consent. If you do not know which cookies are active, you cannot guarantee that this rule is respected. The legal bar is set by the GDPR consent requirements: consent must be obtained before the tracker runs, so an audit is the only way to know whether yours is valid.
Accurate information. Without an audit, nothing guarantees that your cookie policy reflects reality. A gap between documented cookies and cookies actually set is a breach of the GDPR's information obligation.
An effective CMP. A consent management platform can only block what it knows about. Every service missing from its configuration is a tracker that fires without consent. Pre-consent firing is one of the most common failures found during inspections: analytics or advertising scripts that run on page load, before the visitor has interacted with the consent banner.
Proof during an inspection. Data protection authorities expect site operators to know precisely which trackers run on their domain. An up-to-date, dated inventory is often the first document requested.
When to run a cookie audit
The cookies on a website change constantly. Each new third-party script (analytics tool, advertising pixel, chat widget, video player) can bring new trackers without telling you. Run an audit:
- before setting up or replacing a CMP;
- after installing a new plugin, app or third-party script;
- when changing theme, platform or site builder;
- during a redesign;
- periodically: every 3 to 6 months for an active site, and after any change made by a marketing team.
How does a cookie scanner work?
A cookie scanner loads your pages in an automated (headless) browser, simulates a visitor and records everything set in the browser: on initial load, after scripts have run and, depending on the tool, after a simulated consent or refusal. The result is an inventory with each cookie's name, domain, likely purpose, lifespan and the script that triggered it.
What a scan detects
A good scanner identifies first-party cookies, third-party cookies (google-analytics.com, facebook.com, doubleclick.net and so on), session cookies (deleted when the browser closes), persistent cookies (kept until they expire), browser storage entries and tracking pixels. It also flags trackers that fire before consent.
Limitations of automated scanning
A scan does not cover 100% of cases. Some cookies only appear on specific journeys (checkout, member area, conversion funnel), behind a login or for visitors from certain countries. A thorough audit combines several scans and a few manual checks.
Inventory scan versus consent-refused scan
There are two kinds of scans, and they answer different questions. An inventory scan loads the page and lists what it finds, often after accepting everything or without touching the banner. It tells you what exists on the site. A consent-refused scan clicks "Reject all" (or interacts with nothing) and records what still runs. It tells you whether your banner is respected, which is what a supervisory authority tests.
The difference is not academic. On Webflow or Shopify, for example, a Google Analytics ID entered in the site settings or in a sales channel app can load Analytics outside the banner's control. An inventory scan reports the GA cookie and moves on; a refusal scan shows that it fires even when the visitor said no. For a real audit, run both.
What no browser scan can see
A scanner only sees what happens in the browser. Data sent from your server to an analytics or advertising platform, such as a server-side Google Tag Manager container or a Conversions API, never shows up in a cookie list, yet it still needs a legal basis. Our article on server-side tagging and its impact on consent explains how to include those flows in your audit. Cookieless tools are not automatically exempt either: see our guide to cookieless analytics.
Which tools to use for a cookie audit
Browser developer tools. Chrome DevTools or Firefox Developer Tools show the cookies set on a page (Application > Cookies tab) and the requests sent (Network tab). Ideal for a quick diagnosis or to confirm a finding, but you have to check every page by hand. Our step-by-step guide on how to check cookies on a website shows where to click in Chrome, Firefox, Safari and Edge.
Browser extensions. Extensions such as Cookie Editor make it easier to view and export the cookies of a given page. They remain limited to page-by-page analysis.
Online scanners. FlowConsent's free cookie scanner opens the URL you enter in a real browser, records every cookie, storage entry, third-party script and tracking pixel, and returns a clear report in 1 to 3 minutes: a privacy score out of 100, each service identified and classified, and a split between services that need consent and those that are technically essential. Run it on each key page of your site.
Vendor checkers. Most consent platforms offer a free online checker, for example Cookiebot, CookieYes or Termly. They are useful for a first inventory, but check whether they test the page after a refusal or only list what they find. If you are not sure what a consent platform does in the first place, read what a consent management platform (CMP) is.
CMPs. Many consent management platforms include detection features. In FlowConsent, compliance verification goes one step further: it loads your pages while refusing consent and lists everything that still runs, which is exactly what an inspector checks.
How to run a cookie audit: the complete method
Step 1: prepare a clean test environment
Work in a cookie-free environment: a private browsing window or a dedicated browser profile with no prior cookies. This simulates a first-time visitor. Auditing with a session that already holds cookies and consent choices distorts the results.
Step 2: scan the key pages
Not all pages set the same cookies. Cover at least the homepage, two or three content or category pages, a product or service page, the contact or form page and the cart or checkout page if you have one. Include your subdomains (app.example.com, blog.example.com): each can set its own cookies. Use a scanner for the bulk of the work and DevTools for targeted checks.
Step 3: document each cookie
For each cookie, record its name, issuing domain (first-party or third-party), retention period (session, 1 day, 13 months and so on), purpose, the service it belongs to and whether its presence is justified. Keep in mind that a first-party cookie can be set by a third-party script: the domain alone does not tell you who controls it. If a name means nothing to you, our explainers on the _ga, _gid and _gat cookies and the Meta _fbp and _fbc cookies cover the two families you will meet most often.
Step 4: classify according to the GDPR
Classification determines whether consent is required:
- Strictly necessary: session, cart, authentication, storage of the consent choice. Exempt from consent.
- Analytics: audience measurement (GA4, Hotjar, Matomo in standard mode). Consent required, unless a strictly configured tool qualifies for an exemption.
- Advertising and marketing: targeting, retargeting, conversion (Meta Pixel, Google Ads, TikTok). Consent required.
- Personalisation and social media: preferences, share buttons, widgets. Consent required.
Our guide to the four GDPR cookie categories gives examples for each group, and what cookies are and how they work is a good refresher on first-party, third-party, session and persistent cookies.
Step 5: check behaviour before consent and after refusal
This is the most critical step. Open the site in private browsing and, without touching the banner, watch the Network tab and the cookie list: if non-essential cookies or requests to tracker domains appear, script blocking is not working. That is a direct non-compliance.
Then click "Reject" and browse a few pages. Non-essential cookies must not appear, and must not reappear on the second page: a choice that is badly stored often leaks at that moment.
Step 6: produce the audit report
The report should include the audit date, the list of pages scanned, the cookie table (name, domain, duration, category, service, consent required), the non-compliances found (cookies loaded before consent, cookies missing from the policy, excessive lifespans) and the corrective actions. Keep every dated version: this history demonstrates your compliance effort.
How to interpret the results
The raw inventory only becomes useful once analysed.
Check lifespans. The CNIL recommends that trackers requiring consent last no longer than 13 months. Flag anything beyond that and reconfigure it where possible; our guide to cookie retention periods details the rules.
Hunt for undocumented cookies. Some cookies match no service you installed on purpose. They usually come from scripts loaded in a chain: a chat widget that loads an advertising pixel, a video player that sets its own trackers.
Compare with your documentation. Every active cookie must appear in your cookie policy and in your CMP configuration, in the right category.
Common audit findings and how to fix them
The same services come up in almost every audit. For each one, a dedicated guide explains the cookies involved and the compliant setup:
- Google Analytics 4: loaded before consent, or with Consent Mode misconfigured. See whether Google Analytics is GDPR compliant and our Google Tag Manager and Consent Mode guide.
- Meta Pixel, TikTok Pixel, LinkedIn Insight Tag: advertising trackers that must wait for consent. Read our guides to the Meta Pixel, the TikTok Pixel and the LinkedIn Pixel.
- Hotjar and session recording: often installed by a product team and forgotten. See Hotjar and GDPR.
- HubSpot and marketing tools: tracking code that sets cookies on every page. See HubSpot cookies and GDPR.
- Google Fonts and YouTube embeds: they do not always set cookies, but they send the visitor's IP address to Google on page load. See the Google Fonts risk and YouTube nocookie embeds.
- Matomo: can qualify for a consent exemption in France only with a strict configuration. See whether Matomo needs a banner.
Your site builder also adds its own cookies and integrations. Our platform guides cover the specifics for Webflow, WordPress, Shopify and Wix.
From audit to proof: documenting compliance
Article 5(2) GDPR makes you responsible for compliance and requires you to be able to demonstrate it (the accountability principle), and Article 7(1) puts the burden of proving consent on you. An audit is therefore not only a diagnosis: it is evidence. Three kinds of records work together:
- The audit report: the dated inventory, the pages tested, the findings and the fixes. It shows what your site did at a given date.
- Proof of each consent: a timestamp, a pseudonymous identifier, the choice per purpose and the banner version. Our guide to proof of cookie consent details what to store and for how long. The same logic applies to consent collected through newsletter, sign-up or marketing forms: our GDPR consent form examples show the wording and the records to keep.
- Proof that refusal is respected: a scan run with consent refused, with the requests and cookies observed and a screenshot. This is the piece most sites lack, and the one that answers the question regulators actually ask.
Keep each version. A history of audits, with problems found and corrected, carries more weight than a single clean report produced the day before an inspection. When regulators do act, the failures they cite are the ones an audit catches: cookies set before consent, refusal harder than acceptance, information that does not match reality. Our summary of real CNIL cookie sanctions shows how often those findings come back.
Common mistakes in cookie audits
- Only scanning the homepage. Many trackers only appear on product, article or checkout pages.
- Auditing with a session that already holds cookies. Always start from private browsing.
- Confusing first-party and third-party cookies. A third-party script can set first-party cookies.
- Ignoring subdomains. The audit must cover the whole domain.
- Not testing pre-consent and post-refusal behaviour. It is the most important compliance test.
- Auditing once and never again. A plugin update can add cookies without notice.
- Not documenting the results. An audit only has value if it is dated and archived.
From audit to compliance: next steps
- Update your cookie policy with the full inventory: name, provider, purpose and lifespan of each cookie. In FlowConsent, the cookie declaration is generated from your active services, and an alert lists any cookie observed by a scan that your banner does not declare.
- Configure your CMP to block non-essential scripts before consent, with categories matching those of your audit.
- Align Google Consent Mode v2. If you use Google tags, make sure the consent signals reflect your categories. See our Consent Mode v2 implementation guide and how FlowConsent handles Google Consent Mode.
- Remove or replace unjustified cookies. If a script sets cookies you do not need, remove it or switch to a compliant alternative.
- Monitor continuously. With continuous compliance monitoring, representative pages are re-verified automatically (every 7 days by default) and you are alerted the day a compliant page starts leaking.
Cookie audit checklist
- Prepare a clean environment: private browsing or a dedicated profile.
- List the pages to audit: home, content, product, form, checkout, subdomains.
- Scan each page with a dedicated tool, and confirm with DevTools.
- Document each cookie: name, domain, duration, category, service.
- Classify according to the GDPR: strictly necessary (exempt) or subject to consent.
- Check that no non-essential cookie or tracker fires before consent.
- Test behaviour after refusal, including on a second page.
- Check lifespans (13 months maximum for trackers).
- Compare with your cookie policy and CMP configuration.
- Identify undocumented third-party cookies.
- Produce and archive a dated audit report.
- Schedule the next audit (3 to 6 months, or after any site change).
A cookie audit takes from 30 minutes to a few hours depending on the size of the site. Without a reliable inventory, your cookie policy, banner and CMP configuration rest on assumptions; with a regular audit, you catch undocumented trackers, cookies that fire before consent and gaps between your documentation and reality. Run the free cookie scanner on your key pages to get your inventory in a few minutes.
How FlowConsent handles cookie audits
FlowConsent covers the three steps of the audit. Automatic cookie scanning pre-fills your services and cookie list when you install the banner, and the cookie declaration is generated from them. Compliance verification then loads up to five representative pages in a real browser from Europe while refusing consent, and gives a verdict per page: compliant, warnings or violations. Cookieless Consent Mode pings are recognised and not counted as leaks. Each check is archived with a screenshot and the request log, and can be printed as a proof report for your DPO or an auditor. With continuous monitoring, pages are re-verified every 7 days by default and you are alerted the day one regresses.