A cookie audit is a documented inventory of every cookie, tracking pixel and browser storage item that a website actually sets, recording who sets each one, what it is for, how long it lasts and which consent category it belongs to. It describes what the site does in practice, not what anyone believes it does.
How a cookie audit works
The audit starts in a clean browser with no stored data. You load the site, decline everything on the banner, and record what still appears. Then you accept everything and record again. The difference between the two lists shows whether the banner genuinely controls anything. Browser developer tools show cookies, local storage and session storage under the Application tab, and the Network tab shows every request sent to an outside domain, which is where most tracking pixels reveal themselves.
A single page is not enough. A thorough audit visits the homepage, a service or product page, a blog post, the contact page, a page with an embedded video or map, and any checkout or booking flow, because many tools only load where they are used. Automated scanners speed this up by crawling a few hundred URLs, but they miss items that only appear after a click or a form submission, so manual checks on the key journeys still matter.
Each item is then written into a table with these columns:
- Name and domain For example _ga on your own domain, or a cookie set by a video platform’s domain.
- Provider The company behind it.
- Purpose in plain English.
- Duration Session, or the expiry the browser shows.
- Category Strictly necessary, functional, analytics or marketing.
- Behaviour before consent Does it appear when the visitor has refused?
Why it matters
For a UK business, the audit is the factual base for three things. The cookie banner needs categories that match what the site really sets. The cookie policy has to list those items accurately. The privacy notice has to name the third parties who receive visitor data. If any of those documents is written from a template instead of an audit, it will almost certainly be wrong, and a wrong policy is worse than a vague one because it makes a specific claim the site breaks.
Under PECR, non-essential cookies need consent before they are set. Strictly necessary items, such as a session cookie that keeps a basket working, are exempt. The audit is how you prove which is which. It also turns up waste: tags from tools you stopped paying for years ago, duplicate analytics installs and old advertising pixels that still send data to platforms no one logs into.
I hold this site to the same rule: its cookie policy and other legal pages are written from an audit of what it actually sets and transmits.
Common mistakes
- Auditing with consent already given. A browser that accepted cookies last week hides the real pre-consent behaviour. Always start clean.
- Counting only cookies. Local storage, session storage and pixels that set nothing but still send data to a third party all count.
- Trusting the scanner’s categories. Automated tools guess. A cookie labelled “functional” may in fact feed an advertising platform.
- Auditing once. Every new plugin, chat widget or embedded video can add trackers. An audit from launch day is out of date within months.
- Ignoring tags fired through a tag manager. These load after the page and are easy to miss on a quick look.
How to act on it
Open a private browsing window and record what the homepage sets before you touch the banner. If anything beyond strictly necessary items appears, your consent set-up is not working and that is the first fix. Then decline, accept and repeat on your key templates, filling in the table as you go.
Keep the finished audit as a living spreadsheet with a date at the top, and make adding a row part of installing any new tool. Use it to rewrite the cookie policy, confirm the banner categories and check the privacy notice names every recipient. If the audit uncovers tags firing out of order, broken consent signals or slow third-party scripts, I check those as part of a technical SEO review.