Why our cookie scanner clicks "Accept" before it counts
Published on
A scanner that never gets past the banner only sees the cookies set before consent — usually the smallest and least interesting set. Here's how we scan, how each cookie gets classified, and the one setting that decides whether any of it gates anything.
A cookie scan answers one question for your cookie policy: what does this site store in a visitor's browser? The catch is that the answer depends on what the visitor chose. Before anyone clicks, a well-behaved site sets almost nothing. After "Accept all", analytics, advertising and embedded third parties all write their own. A scanner that stops at the banner documents the first set and misses the one your policy is actually about.
Scan the page a consenting visitor sees
Croombit's crawler is a headless Chromium. It visits your pages, accepts the cookie banner, and records every cookie and web-storage key it observes afterwards — first- and third-party, with domain and expiry. The result lands in the inventory already classified. You can run it from the console on demand or on a schedule; if you run your own scanner, Import scan takes its JSON instead. Details in Console: Cookies.
Three tiers of classification
- Reference database. A curated set of well-known cookies (
_ga,_fbp,IDE…), plus classifications promoted from real reviews. An exact match is final. - Heuristics. Name patterns and party/expiry rules for the cookies the database doesn't know.
- A language model for what's left. Anything it isn't confident about goes to the review queue instead of being guessed into a category.
A human decision in the review queue is authoritative for that site. When two or more independent organizations confirm the same classification, it can be promoted into the shared database, so the next site that meets that cookie gets it right at tier one.
The setting that decides whether any of it matters
Classifying a cookie as MARKETING documents it. It doesn't, by itself, block anything. What actually gates scripts is a published purpose in the banner with category MARKETING: that's what releases <script type="text/plain" data-tc-consent="marketing"> tags and the automatic blocking of known trackers once the visitor accepts. If the scan finds marketing cookies and there's no marketing purpose, nothing tagged as marketing will ever run — there's nothing for the visitor to accept.
From inventory to policy
The same inventory feeds the cookie declaration table the banner embeds, so the list visitors read is the list the scanner found — not a document someone last updated a year ago. Re-scan after every release that adds a tag, or put it on a schedule and let the review queue tell you when something new turns up.