Cookie scanner: running a scan and reading results

Prior blocking only stops trackers it knows about, and your cookie declaration (the public list of what your site sets and why) is only useful if it's accurate. The cookie scanner is what keeps both true: it crawls your site with a real headless browser, records every cookie and storage item it finds, classifies each one against a curated provider database, and feeds the results into both the declaration table and the prior-blocking checklist. This guide covers running a scan from the dashboard, what the results mean, and how re-scans and live observation keep things current between scans.

What it's for

Without a scan, prior blocking falls back to a bundled list of common trackers (Google Analytics, Meta Pixel, DoubleClick, and similar), and your declaration table has nothing to show. A scan tells Cookie Munch exactly what your site actually sets — including cookies from vendors that aren't on any generic list — so blocking and disclosure are both grounded in reality rather than guesswork.

Running a scan

1. Open Dashboard → Cookies and make sure the right property is selected in the site switcher (top of the page, if your org has more than one).

2. Click Scan now. The button switches to a Scanning… state.

3. The scan runs asynchronously in the background — Cookie Munch launches a headless Chromium instance, loads your site's homepage, and captures every cookie, localStorage/sessionStorage key, and IndexedDB database it observes during that visit, then crawls same-origin links it finds up to a page limit.

4. The dashboard polls scan status automatically; once the crawl finishes, the table refreshes on its own and a Scanned on badge appears showing the last-crawl date. You'll also see a toast confirming the scan started and completed.

5. If you click Scan now again while a crawl for that property is already running, it's treated as a no-op rather than starting a second concurrent crawl — you'll just see an error toast rather than a duplicate scan.

A scan is safe to re-run as often as you like: each completed crawl fully replaces the previous snapshot, so a scan always reflects the site as it is right now, not an accumulation of every cookie ever seen.

Reading the results

Each row in the table is one detected cookie (or storage item), with:

Use the search box to filter by name, domain, provider, or purpose, and the category and provider dropdowns above the table to narrow the list further — handy on a site with dozens of cookies. The header also shows a running total (N cookies detected · auto-categorized) and, when applicable, a Needs review badge counting how many are still Unclassified.

How classification works

Every detected cookie is matched against a curated database in three tiers, tried in order of confidence:

A match resolves a category, a provider, a purpose string, and (where known) an expected expiry. Cookies that don't match anything land in Unclassified — still reported, but flagged so a human confirms the right category rather than the system guessing. Re-classification happens live: if a future database update recognizes a previously-unclassified cookie, the declaration feed picks that up immediately without a fresh scan (an existing classification is never downgraded this way — only upgraded).

Only third-party cookies (not your own first-party ones, and never Necessary) turn into prior-blocking rules — one rule per distinct tracker domain, mapped to whichever category that provider's cookies fall under.

What a scan can miss

The crawler only sees what fires during an automated visit to the pages it reaches — same-origin links from the homepage, up to a page-count limit. Two kinds of cookies can be invisible to a single scan:

• Interaction-gated trackers — a cookie that only fires after a visitor clicks something specific (a video embed, an "accept" button on a third-party widget) may not appear from a passive crawl.

• Pages the crawl doesn't reach — anything behind a login, or not linked from the homepage within the crawl depth.

That's what live observation is for: when Observe cookies is on (Banner Studio → Settings → Behaviour tab, on by default), the embed reports the cookie names it sees on real visitor page loads back to the API — never values, throttled to once per browser session. Those observations merge into the latest snapshot: cookies the scan already classified keep their classification, and newly-seen names get categorized and added — so cookies that only appear under real traffic end up in your declaration without you having to notice them yourself.

Re-scans and scheduling

• Manual: click Scan now any time — after adding a new analytics/marketing script, swapping ad vendors, or just periodically to keep the declaration honest.

• Scheduled: operators can enable an automatic daily crawl across every verified property, plus a periodic diff report that emails a summary of cookies newly added or disappeared since the last report — useful for catching a marketing team quietly dropping in a new ad pixel without anyone updating the declaration by hand. Ask your admin if this is something you'd like turned on for your organization.

Tips

• Only verified sites can be crawled — a scan targeting a domain that resolves to a private, loopback, or internal address is refused outright as a safety measure, so make sure DNS for the property actually points at your live site before scanning.

• Work through Unclassified cookies promptly: they're the ones your declaration and your compliance posture can't yet fully account for. Filter the table by the Unclassified category to find them quickly.

• If you rely heavily on click-triggered embeds (video players, chat widgets), don't assume one scan caught everything — leave live observation on and give it real traffic before treating the declaration as complete.

• After a scan, it's worth spot-checking prior blocking again: newly discovered third-party domains become new auto-block rules, which is the main way auto mode gets more accurate for your specific site over time.