Your first cookie scan

What does the scanner do?

The scanner loads your site in a real Chromium browser and crawls up to 50 pages by default (you can raise this to 250, or lower it, in Scan settings, under Pages per scan). It does this twice, and each pass answers a different question. Across both passes, a site that fills the default 50 pages takes about 7 minutes, and a slow one takes about 11. At 250 pages, a large site takes roughly 35 minutes and a slow one up to about an hour. A scan waits its turn behind any scans already running.

The first pass gives no consent at any point. This answers the compliance question: what exactly fires before a visitor agrees to anything? That's the behavior your banner is there to control, and anything that reaches a visitor during this pass reached them without permission.

The second pass accepts, then crawls the same pages again. This answers the disclosure question: what does your site run once someone says yes? Your cookie policy has to disclose what the site uses, and that's more than what slips out early. On a site where prior blocking is working well, the first pass alone finds almost nothing, which would leave you disclosing almost nothing.

Every cookie in your inventory is marked with the pass that found it. A cookie seen in the first pass fired before consent, so it's something to fix. A cookie that appears only in the second pass was being held correctly, so it's something to disclose.

The scan uses a real browser and doesn't crawl source code, so it sees what a visitor's browser sees: headers, the cookie store, and the page as it runs.

Start a scan

To run a manual scan, open the Cookies page and click Run a scan. That's the whole procedure.

You can also put scans on a schedule: off, weekly or monthly. The default is monthly, because your generated cookie policy tells visitors the site is rescanned regularly, and the schedule keeps that statement true. Only turn scheduling off if you intend to rescan by hand.

What counts as a cookie?

Three kinds of evidence make a cookie, and nothing else does:

• a Set-Cookie response header,
• an HTTP-only record read from the browser's cookie store,
• a value present in document.cookie.

Any one of these proves a cookie exists, so it becomes a row in your inventory. There's one refinement. A Set-Cookie header with an expiry in the past removes a cookie instead of setting one. The scanner recognizes these deletion headers and doesn't count them.

Everything else is context

The scan also records scripts, pixels, iframes, localStorage and sessionStorage keys, and beacons. These are kept and labeled as context, and they're never counted as cookies.

This split is central to how UserGuard works. Most scanners promote every signal they see to "cookie" and over-report, which leaves you with an inventory padded with rows you can't verify and a cookie policy that discloses things that aren't cookies. UserGuard keeps the context visible, because it often explains why a cookie exists, but never counts it as a cookie.

So if your first scan reports fewer cookies than a previous tool did, that's expected. Check the context entries before assuming anything was missed.

Read the results

Open the scan detail to see the raw evidence stream. It lists every line the scanner recorded, marked as either verified cookie evidence or context, and none of it is summarized away. If you ever wonder why a cookie is in your inventory, look for its line in this stream, which shows which header, store record or document.cookie value put it there.

What the next scan does

Rescans reconcile the inventory instead of rebuilding it:

• New cookies appear as new rows.
• Cookies that no longer show up are marked gone, and they're never deleted. The audit trail stays, so you can still show what the site did and when.
• A scan never overwrites a category decision made by a person.

That last rule matters most. Once you've categorized a cookie, you can rescan safely, because the scanner updates the evidence and leaves your judgment alone.

If a scan fails

If a scan stops making progress, with no page finished for 10 minutes, the cleanup that runs once an hour marks it failed. The same goes for a scan still running well past its limit, which is about 37 minutes at the default 50 pages and longer if you raise Pages per scan. Until then the Scan card says the scan has stopped, and Run a scan comes back once it's marked failed. A scan waiting its turn in the queue doesn't time out, however long the line is. It's only marked failed if it drops out of the queue. On a very slow site, the scan stops reading at its own time limit and keeps what it found. It doesn't mark cookies on the pages it didn't reach as gone, and the Scan card says it ran out of time. Retry a failed scan. A failed scan writes nothing to your inventory, so retrying costs nothing.