How to Audit Your Website's Cookies: A Step-by-Step Guide

Why You Need a Cookie Audit

You cannot consent-gate, document, or comply with anything you have not measured. A cookie audit is the process of discovering every cookie, pixel, tag, and storage key your website sets — who sets it, why, and for how long. It is the foundation of a defensible cookie policy and a working consent banner, and it is the first thing a regulator or a privacy-conscious customer will effectively be checking when they open your site’s developer tools.

This guide is a practical, repeatable procedure. It starts with a manual pass anyone can do in a browser, then moves to automated scanning for coverage and scale, and finishes with how to keep the inventory accurate as your site changes. If you want the legal context for why these trackers need handling, read the GDPR cookie compliance checklist alongside this; here we focus on the how.

What an Audit Should Capture

Before you start clicking, know what you are collecting. For every item your site stores or reads on the user’s device, you want to record:

• Name — the cookie or storage key (e.g. _ga).
• Provider/domain — who set it, and whether it is first-party (your domain) or third-party (e.g. an ad network).
• Purpose — what it actually does, in plain language.
• Category — strictly necessary, functional/preferences, analytics, or marketing. See cookie types and categories explained.
• Duration — session, or a persistent expiry (e.g. 2 years).
• Type of storage — HTTP cookie, localStorage, sessionStorage, IndexedDB, or a tracking pixel that may not set a cookie at all.

That last point matters: a thorough audit looks beyond the cookie jar, because much modern tracking uses local storage or fires server-side beacons.

Method 1: The Manual DevTools Pass

Every modern browser ships with the tools to inspect storage. A manual pass is the best way to understand your site before you automate, and it costs nothing. In Chrome or Edge, open DevTools (F12) and use the Application panel; in Firefox use the Storage panel.

The Limits of Manual Auditing

A manual pass is invaluable for understanding, but it does not scale and it goes stale immediately. Three problems make manual-only auditing unreliable:

• Coverage. Real sites have hundreds of pages and many user paths. Trackers can be conditional — fired only on checkout, only for logged-in users, or only after a specific interaction.
• Third-party drift. A vendor can change what their script does without telling you. A tag that set one cookie last month may set five today.
• Time. Doing a thorough manual audit across templates, then repeating it regularly, is hours of work that almost never actually gets repeated.

This is exactly the gap automated scanning fills. For a deeper look at the trade-offs between snapshot and continuous approaches, see how cookie scanners work.

Method 2: Automated Scanning

An automated cookie scanner loads your site the way a real browser does, crawls multiple pages, and records every cookie, storage key, and outbound connection it observes. A good scanner does two things a manual pass cannot:

1. Breadth. It crawls many URLs and simulates both pre- and post-consent states, so conditional trackers are far more likely to be caught.
2. Classification. It matches discovered cookies against a known database to suggest a provider, purpose, and category — turning a raw list into a usable inventory.

Run a scan, then reconcile its output against your manual findings. The scanner will usually surface trackers you missed; your manual pass will sometimes catch context the scanner cannot (e.g. a tracker that only fires after a multi-step form). Together they give you confidence the inventory is complete.

Method 3: Continuous Monitoring

A cookie audit is not a project with an end date — it is a state you maintain. The moment marketing adds a new tag, a developer ships a new embed, or a third party updates its script, your inventory is out of date and your cookie policy is wrong.

Continuous monitoring runs scans on a schedule and watches live traffic for drift — new cookies or connections that were not in the approved inventory. When drift is detected, you are alerted (and ideally the new tracker is blocked until reviewed) rather than discovering the gap during an audit months later. This closes the loop between “we scanned once” and “we know what our site is doing right now.”

From Inventory to Action

An audit is only useful if it drives changes. Once you have a complete inventory:

• Categorise everything. Assign each tracker to a category so your banner can offer granular choices. Be honest — do not file analytics under “strictly necessary.”
• Gate the non-essential ones. Ensure analytics and marketing tags only fire after consent. See how to block scripts until consent.
• Update your cookie policy. The published policy should match the live inventory, including providers and retention periods.
• Remove what you do not need. Audits frequently surface zombie tags from old campaigns. Deleting an unused tracker is the cleanest possible compliance fix.

If you are setting up consent from scratch, the CookieBeam quickstart walks through wiring the banner to the categories you defined here.

Authoritative References

• Chrome DevTools: View, edit, and delete cookies
• MDN Web Docs: Document.cookie and client-side storage
• UK ICO: Cookies and similar technologies
• CNIL: Cookies and other trackers