Why reading the source does not work
A tag manager loads tags defined elsewhere. A platform app injects scripts at runtime. A plugin adds a snippet on some templates and not others. A third-party script loads a fourth-party script. None of that is visible in a repository, and all of it is visible in a browser.
A small result still needs coverage checks
A site can legitimately set few or no optional cookies, but a small result is not proof of completeness. Check rendered pages, delayed interactions, authenticated and checkout states, regional variants, storage APIs, network requests and server-side integrations before concluding that the inventory is complete.
A method that works
- 1
Start from a clean profile
A fresh browser profile with no extensions. Existing cookies and an ad blocker will both give you a result that is not what a real first-time visitor experiences.
- 2
Capture before touching anything
Load the page and record what happened before any consent choice. This pre-consent baseline is the list you actually have to bring under control.
- 3
Cover more than the homepage
A product page, an article, a page with a form, and the checkout or sign-up flow. Scripts are frequently route-scoped, and conversion tags fire on pages a homepage scan never reaches.
- 4
Look at requests, not just cookies
A blocked third-party cookie still leaves a request carrying an IP address and a referrer. Storage in localStorage and sessionStorage is inside the same rule and invisible to a cookie-only audit.
- 5
Name the parties
An inventory of hostnames is not an inventory. Classify each finding to a vendor and a purpose, because the purpose is what the category decision rests on.
- 6
Repeat after consent, and after refusal
Three states, three captures. The difference between them is the evidence that gating works.
Then stop doing it by hand
A manual audit is a snapshot, and sites change. A verification scan drives a real browser across a set of pages in each consent state and reports findings ranked by impact, on a schedule: weekly on Starter, daily on Growth and Agency.
For the cases a crawler cannot reach (behind a login, a specific checkout state, a customer’s own device), capture a HAR file and import it as an investigation instead.
Common questions
How often should a cookie audit be repeated?
Continuously, in the sense that a scheduled scan should be running. Manually, whenever something structural changes: a new marketing tool, a theme update, a platform app, a site rebuild.
Do I need to audit subdomains separately?
Yes. A subdomain often runs a different stack (a help centre, a status page, a landing-page builder) with its own trackers and frequently no consent implementation at all.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- ICO: guidance on storage and access technologies
Regulator guidance
Checked
- StrongPrivacy verification guide
Product documentation
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.