Why Do Cookie Scanners Give Different Results? (And What to Actually Put on Your Cookie Page)

It happens more often than people expect: someone needs a cookie list for their site's cookie policy page, runs three different free scanners, and gets three different answers. Not slightly different — sometimes one tool reports 6 cookies and another reports 40. Neither tool is necessarily wrong. They're usually just measuring different things.

It's Not a Bug, It's a Methodology Difference

A cookie scanner's result depends entirely on what it did before it looked: what consent state it was in, how many pages it visited, how long it waited, and what it counts as "belonging" to your site. Change any one of those and the list changes, even on an identical site, even run five minutes apart.

Six Real Reasons Scanners Disagree

1. Consent state at scan time. A scan that never accepts anything sees whatever loads before consent, which on a well-configured site is almost nothing. A scan that auto-accepts everything sees the full set — analytics, ad platforms, chat widgets, embedded video players, all of it. Two completely different, both accurate, numbers depending on this one variable alone.
2. Page and session depth. A single-page scan misses whatever only gets set on checkout, a specific blog post, or a page with an embedded video. Tools vary wildly in how many pages they actually crawl by default — some check one page, some check five, some check none beyond the homepage unless you configure otherwise.
3. Delayed and conditional scripts. A/B testing tools, chat widgets, and anything that loads after a delay or a user interaction won't show up in a quick single-pass scan. If the tool doesn't wait, or doesn't interact with the page the way a real visitor would, it simply never sees those cookies.
4. Categorisation is a judgement call, not a fact. "Necessary" vs "functional" vs "preferences" isn't standardised across the industry. Each scanner applies its own internal classification, often against its own database of known trackers. The same cookie can legitimately end up in different categories on different tools — not because one got it wrong, but because there's no single agreed answer to classify against.
5. CNAME cloaking and server-side proxying. Some setups route third-party cookies through a subdomain of the site itself, making them look first-party to a tool that isn't specifically checking for this. Whether a scanner unmasks that or takes it at face value changes the count and the classification.
6. Silent scanner blocks. This one's rarer, and it's the one we only found by hitting it ourselves: a scanner whose requests get blocked by the target site's WAF or bot protection can come back with an empty or partial cookie list and give no indication anything went wrong. It just looks like a quiet site with fewer cookies than expected. We built explicit detection for this into our own scanner after finding a real client site returning a hard 403 to our scanning origin while working perfectly for real visitors — the scan wasn't measuring "no cookies," it was measuring "blocked," and those look identical unless you're specifically checking for the difference.

So What Should Actually Go on the Cookie Page?

A defensible cookie list needs to reflect what a real visitor's browser actually experiences, not what one scan under one set of conditions happened to catch. In practice, that means:

• Scan in all three consent states — pre-consent, post-accept, and post-reject — and record what's different between them. The pre-consent list is what needs to be near-empty; the post-accept list is what needs disclosing.
• Crawl more than the homepage. Checkout pages, contact forms, embedded video, and any page with a chat widget are common sources of cookies the homepage never sets.
• Wait, and interact. Load the page, wait a realistic amount of time, scroll, and if there's a chat widget or similar, let it actually load before checking again.
• Use a consistent, documented categorisation rather than switching between tools with different taxonomies. Google's own Consent Mode categories (ad_storage, analytics_storage, ad_user_data, ad_personalization, functionality_storage, personalization_storage, security_storage) are a reasonable, widely-understood anchor.
• Re-check periodically, not once. A cookie page written at launch and never revisited drifts out of date the first time a new ad platform or embed gets added to the site.

None of this is exotic. It's the same discipline as verifying tracking actually fires — test every consent state, cover more than one page, and don't trust a single quick pass to be the whole picture. The tools that only ever show one number aren't lying to you. They're just showing you one slice, and calling it done.