To conduct a cookie audit, inventory every cookie and tracker your site sets. Record each one's source, purpose, and lifespan, categorize them, and confirm non-essential ones stay blocked until consent. Then reconcile that list against your cookie policy and banner, fix the gaps, and re-audit on a schedule.
You can run the discovery step with an automated scanner or manual browser tools. Either way, the judgment calls are yours, not a tool's: deciding what a cookie is actually for, and whether your policy matches reality.
What Is a Cookie Audit? (Quick Answer)
A cookie audit is a systematic review that finds every cookie and tracker a site sets. It records each one's source, purpose, and lifespan, then checks that record against the site's consent banner and cookie policy. A scan is the automated discovery step inside an audit; the audit is the full review, judgment, and fix that the scan alone cannot deliver. For the fuller breakdown of what a cookie audit is and why it matters, see what a cookie audit is.
What You Need Before You Start
Access to your live site as a real visitor, logged in and logged out, is the prerequisite most audits skip. Your current published cookie policy is the second: without it, you have nothing to reconcile the scan against.
Gather these before you start:
- Site access. The live production URL, tested as both a logged-in and a logged-out visitor, since some cookies only fire after login.
- A discovery method. An automated cookie scanner or CMP, browser developer tools, or both. Automated tools cover more ground fast; manual tools catch what automation misses.
- A place to record findings. A spreadsheet or a cookie register, with columns for name, domain, category, purpose, and lifespan.
- Your published cookie policy. The document you will reconcile the scan against. If it does not exist yet, note that as gap zero.
How to Conduct a Cookie Audit: Step by Step
A real audit runs in seven steps, from raw discovery through a scheduled re-audit. Skipping the reconciliation and judgment steps and stopping at a scan is the most common way audits fail.
Step 1: Inventory Every Cookie and Tracker Your Site Sets
This step builds the raw list every later step depends on: every cookie, tracker, script, and iframe your site loads, from any domain.
Run two discovery paths, not one. An automated full-site scan crawls every page fast and catches third-party scripts and iframes a manual pass tends to miss. Manual browser inspection is slower. It catches cookies tied to a specific action, a login, a cart add, a form submit, that a crawler never triggers.
Visit the site as a real user would, not just the homepage. Check logged-in and logged-out states separately: a login-gated area can set cookies a public crawl never reaches. Run through every form, every embedded video, and any "optional" flow like a chat widget. Adding an item to a cart can set cookies that never fire on a page load alone. A one-pass scan misses all of these.
With Consently, an automated full-site scan detects cookies, trackers, scripts, and iframes across every page it can reach. You can also add a manual URL list for funnel pages that are not linked from your main navigation or sitemap. That way a checkout flow or a landing page still gets scanned, even if a crawler would never find it on its own.
Done: you have a raw list of every cookie, tracker, script, and iframe your site sets, tagged with the domain that set it.
Step 2: Check What Fires Before Consent
This step catches the single issue regulators check first: anything non-essential that fires before a visitor makes a consent choice.
Load the site fresh, with cookies cleared and nothing accepted. Watch the Network tab or your scan report for anything that sets before you click. A banner can look fully compliant on the surface while analytics, ad pixels, or embedded tools still fire before consent underneath it. That gap, between what the banner promises and what the page actually loads, is the most common finding in a real audit.
With Consently, auto-blocking holds non-essential cookies, scripts, and iframes until a visitor consents. That lets you confirm directly that nothing fires early, instead of trusting the banner's front-end behavior alone.
Done: you have a list of everything that fired before consent, which is your list of pre-consent violations to fix in Step 6.
Step 3: Record Each Cookie's Source, Purpose, and Lifespan
The register is the audit's tangible output: a structured record of every cookie, not just a list of names.
For each entry, record the domain, the vendor that set it, its purpose, and its lifespan. Note whether it is first-party or third-party, and whether it is a session cookie or persistent for a set duration. A table is the natural format for this:
| Field | What it captures |
|---|---|
| Name | The cookie's identifier |
| Domain | First-party or third-party, and which vendor |
| Purpose | What the cookie actually does |
| Category | Its consent category (covered in Step 4) |
| Lifespan | Session, or persistent with an expiry date |
With Consently, a scan report pre-fills the domain, name, and detected category for you. Scan history keeps a timestamped record of every past scan. You still add the purpose yourself: a scan can tell you a cookie exists, but not why your site is using it. Note the current gap honestly. The scan report and consent logs export, but a raw scan-result list export is not yet available. Build the register from the dashboard's scan data plus your own notes.
Done: you have a structured cookie register with source, purpose, category, and lifespan for every entry from Step 1.
Step 4: Categorize Each Cookie and Decide What Needs Consent
Categorization is where an audit stops being a list and becomes a compliance decision.
Sort every cookie into a cookie category: essential, functional, analytics, or advertising. Only cookies that qualify as strictly necessary are exempt from consent. Under GDPR and the ePrivacy Directive, a cookie qualifies as strictly necessary only when it is essential to a feature the visitor explicitly requested. The site must also fail to work without it, not merely work less well.
This is the step a scanner cannot finish for you. A scanner reads a cookie's name, domain, and expiry against a database of known configurations, then suggests a category from that pattern match. It cannot read your code to know what the cookie is actually doing. The exact same session cookie could hold a visitor's shopping cart, which is strictly necessary. Or it could track their behavior for a marketing pixel, which is not. Same technical signature, different legal answer. Only you know which one your site is doing.
With Consently, auto-categorization gives you a starting split across essential, analytics, advertising, and other categories the moment a scan completes. You confirm each strictly-necessary tag yourself, because that call depends on what the cookie is actually for, not on a scanner's pattern match.
Done: every cookie in your register is tagged with a category and a consent decision, needing consent or exempt as strictly necessary.
Step 5: Reconcile the List Against Your Cookie Policy and Banner
This reconciliation, not the scan, is the audit's actual deliverable. A list of cookies with no comparison against what you have publicly disclosed is not an audit. It is inventory.
Check two things side by side. First, does your published cookie policy list every cookie category your site actually sets, and does it omit any that no longer run? Second, do your banner's category toggles match your register: does rejecting analytics in the banner actually stop analytics cookies from loading?
Flag every mismatch you find. Look for a cookie firing that your policy never discloses, or a category listed in your policy that the banner does not let visitors decline. A pre-ticked consent box presented as an active choice is a mismatch too. A banner that looks compliant and a policy that reads well can both still fail this check. The underlying code has to match both documents, not just one.
For the broader multi-region compliance picture this reconciliation feeds into, see how to comply with cookie laws.
Done: you have a gap list of every mismatch between what your site actually does and what your policy and banner claim it does.
Step 6: Fix the Gaps (Block, Disclose, Re-Consent)
Every gap from Step 5 gets a specific fix, not a general cleanup pass.
Block any offender that fired before consent in Step 2. Disclose any cookie your policy omitted, updating the policy text to match reality. If a cookie's scope or purpose changed since visitors last consented, re-prompt for consent. Do not assume the old choice still covers it.
If the audit turns up a missing or broken banner entirely, that is a separate build, not a quick fix. See how to add a cookie banner. Platform-specific gaps route to their own guides: how to make a Shopify store GDPR compliant or how to make a WordPress site GDPR compliant.
With Consently, blocking non-essential offenders is a category toggle, not custom code. The built-in cookie policy generator regenerates your public policy once the register is accurate, so the two stay in sync. These are compliance-assistance tools, not a substitute for legal advice on a specific gap.
Done: every gap from Step 5 is closed and re-verified with a fresh check of what fires before consent.
Step 7: Schedule the Next Audit
An audit is a recurring process, not a one-time project. New plugins, ad pixels, and embedded widgets add cookies to a site continuously, with no announcement.
Run a full manual or deep-dive audit at least quarterly, and immediately after deploying any new code, ad pixel, or third-party integration. That is exactly when new trackers slip in unnoticed. Between deep-dives, an automated recurring scan catches drift before it becomes a quarter's worth of undisclosed cookies.
With Consently, weekly scheduled scans plus on-demand scans keep the discovery step current between your quarterly deep-dives. An exportable consent log gives you a timestamped audit trail of what visitors actually consented to, and when.
Done: a recurring cadence is set, combining scheduled automated scans with a periodic full manual reconciliation.
How to Find Cookies Manually With Browser DevTools
Every browser's developer tools show you exactly what cookies a page sets, no extra software required. Open DevTools with F12, or right-click the page and choose Inspect. Then go to Application (Chrome and Edge) or Storage (Firefox), then Cookies, and select the site's domain. You will see every cookie set for it, including name, domain, expiry, and its Secure, HttpOnly, and SameSite flags.
Third-party cookies show up in the same Cookies pane with a warning icon next to them. You can also confirm them directly in the Network tab. Click any request and open its Cookies section to see exactly what that request set or sent. Sort by the SameSite column to spot cross-site cookies set to SameSite=None. Those are usually the third-party trackers most likely to need consent and disclosure.
Modern browsers support the cookieStore API from the console for a quick programmatic dump instead of clicking through the panel. Run cookieStore.getAll().then(console.table) and the browser prints every accessible cookie as a table. It only shows cookies your JavaScript context can read, so HttpOnly cookies will not appear there, even though they are present.
For anything a browser check will not surface, search your site's code directly for where cookies get set. Look in scripts, tag manager containers, and third-party embeds. This catches cookies tied to a conditional flow, like one that only fires after a visitor adds an item to a cart. No static page load will trigger that on its own.
Every one of these methods is imperfect on its own. DevTools only shows what fired during your session. The console API misses HttpOnly cookies. A code search misses anything loaded from a third-party script you cannot read. That is exactly why you combine manual inspection with an automated scan and your own judgment, not why you pick one method and stop.
Why a Scanner Alone Cannot Finish the Audit
A scanner discovers cookies and can block them, but it cannot decide whether a cookie is strictly necessary or lawful. That depends on what your site is actually using it for, not on the cookie's technical signature.
Most scanning tools match a cookie's name and domain against a database of known configurations from common CMSs and third-party tools. They then suggest a category from that pattern. That works well for standard, widely-used cookies. It works less well the more custom your setup is: a homegrown script or an unusual integration will not match any known pattern. The scanner's suggested category is a starting guess then, not a verdict.
The strictly-necessary judgment is the clearest example. The legal test asks whether a cookie is essential to a feature the visitor explicitly requested, not whether it is helpful or improves the experience. A scanner cannot read your code to know that a session cookie holds a shopping cart rather than a tracking ID. Both look identical from the outside. Only the person who understands the site's actual behavior can make that call.
Consently's scanner is strong at the mechanical side of this. It handles full-site discovery, categorization suggestions, pre-consent blocking, and a timestamped record of every scan and consent event. It is not, and does not claim to be, the tool that decides your legal purpose for you. That judgment stays with whoever runs the audit.
Cookie Audit Checklist
Run through this list every time you audit. Keep it as your standing quarterly checklist:
- [ ] Site checked as both a logged-in and logged-out visitor
- [ ] Every form, embed, and "optional" flow (chat, video) manually tested
- [ ] Automated full-site scan run, including any unlinked funnel or landing pages
- [ ] Site loaded fresh with nothing accepted, and nothing non-essential fired before consent
- [ ] Every cookie recorded with source, purpose, category, and lifespan
- [ ] Only cookies essential to a requested feature marked strictly necessary
- [ ] Rejecting a category in the banner actually stops those cookies from loading
- [ ] Cookie policy lists every category the site actually sets, with nothing stale left in
- [ ] No pre-ticked consent boxes presented as an active choice
- [ ] Every gap from this audit fixed and re-verified before closing it out
- [ ] Next audit date scheduled
Common Cookie Audit Mistakes to Avoid
The mistakes below account for most audits that pass a scan and still fail a real compliance check.
| Mistake | Consequence | Remedy |
|---|---|---|
| Trusting a single scan pass | Conditional cookies from logged-in flows, cart adds, forms, and chat widgets never fire during a shallow crawl, so they never appear | Test logged-in and logged-out separately, and manually trigger forms, carts, and embeds during the audit |
| Treating the scanner's category as final | A cookie gets marked strictly necessary when it is actually a tracking cookie with the same technical signature | Review every strictly-necessary tag yourself against what the cookie is actually used for |
| Auditing the site but never the policy | The site can be technically clean while the public cookie policy misrepresents what it does, which is the actual violation regulators find | Reconcile the register against the published policy every time, not just against the banner |
| Auditing once and never again | New plugins, pixels, and embeds add undisclosed cookies within weeks of the last audit | Schedule recurring automated scans plus a quarterly full reconciliation |
| Checking only that a banner exists | A banner can display correctly while analytics or ad pixels still fire before any consent choice is made | Load the site fresh with nothing accepted and confirm nothing non-essential fires early |
How Consently Automates the Repeatable Parts of a Cookie Audit
Consently handles the mechanical, recurring side of an audit so you spend your time on the judgment calls a tool cannot make.
An automated cookie scan covers full-site discovery of cookies, trackers, scripts, and iframes. It also takes a manual URL list for pages a crawler would not otherwise reach. Auto-categorization sorts what it finds into essential, analytics, advertising, and other categories as a starting point. Auto-blocking holds non-essential cookies, scripts, and iframes until a visitor consents, so you can verify nothing fires early instead of guessing. Weekly scheduled scans plus on-demand scans keep that discovery current. An exportable consent log gives you a timestamped record of what each visitor actually agreed to.
What it does not do: decide whether a specific cookie is strictly necessary, or reconcile your register against your published policy. It also will not give you legal advice on a specific gap. Those stay yours. Consently removes the repetitive discovery, blocking-verification, and record-keeping work, so the recurring side of the audit runs on a schedule instead of your memory.
FAQs
What is a cookie audit?
A cookie audit is a systematic review that finds every cookie and tracker a site sets. It records each one's source, purpose, and lifespan, then checks that record against the site's consent banner and cookie policy.
How do I audit the cookies on my website?
Inventory every cookie with an automated scan and manual browser checks, record each one's source and purpose, and categorize it. Confirm non-essential cookies stay blocked before consent, reconcile the list against your policy and banner, fix any gaps, and schedule a recurring re-audit.
How often should I audit my website's cookies?
Run a full audit at least quarterly, and immediately after deploying any new code, ad pixel, or third-party integration. Automated scheduled scans in between catch drift before the next full audit.
How do I find every cookie my site uses?
Combine an automated full-site scan with manual checks in both logged-in and logged-out states. Test every form, cart flow, and embedded widget, since a single-pass scan misses cookies tied to a specific action rather than a page load.
What is the difference between a cookie audit and a cookie scan?
A cookie scan is the automated step that crawls a site and identifies its active cookies and trackers. A cookie audit is the full review that takes that scan's output and evaluates it against your legal obligations, policy, and consent settings.
Can a cookie scanner do the whole audit for me?
No. A scanner detects cookies and suggests categories from pattern matching. It cannot determine whether a specific cookie is strictly necessary, since that depends on what the cookie is actually used for, not its technical signature.
Do I need a cookie audit if I already have a consent banner?
Yes. A banner controls what visitors see and choose; it does not confirm what your site's code actually loads underneath it. Only an audit checks that the two match.
How long does a cookie audit take?
A focused audit of a small site typically takes a few hours. It runs shorter if an automated scan already covers most of the discovery. It runs longer if the policy reconciliation turns up several gaps to research and fix.
What should a cookie audit report include?
A complete audit report includes the full cookie register (source, purpose, category, lifespan) and a list of anything that fired before consent. It also includes the gap list from your policy reconciliation, the fixes applied, and the date of the next scheduled audit.
Ready to cut the manual side of this down? Consently scans your whole site on a schedule, sorts what it finds into categories, and blocks non-essential cookies until visitors consent. It also keeps an exportable consent log as your audit trail. Start your free trial and run your next audit with the repetitive discovery work already done.
