Your first cookie scan

What the scanner actually does

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 that twice, and the two passes answer two different questions. Across both passes, a site that fills the default 50 pages takes about 7 minutes, and a slow one about 11. Raised to 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 already running.

The first pass gives no consent at any point. That is the compliance question: exactly what fires before a visitor agrees to anything, which is the behavior your banner exists to control. Anything that reaches a visitor during this pass reached them without permission.

The second pass accepts, then crawls the same pages again. That is the disclosure question: what your site actually runs once someone says yes. Your cookie policy has to disclose what the site uses, not only what slips out early, and 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 which pass found it. A cookie seen in the first pass fired before consent and is something to fix. A cookie that only appears in the second pass was being held correctly, and is something to disclose.

Because it is a real browser and not a source-code crawler, the scan sees what a visitor's browser sees: headers, the cookie store, and the page as it actually runs.

Start a scan

Open the Cookies page and click Run a scan. That is the whole procedure for a manual scan.

You can also put scans on a schedule: off, weekly, or monthly. The default is monthly. The reason for the default: your generated cookie policy tells visitors the site is rescanned regularly, and the schedule is what keeps that sentence true. Turn scheduling off only 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. One refinement: a Set-Cookie header with an expiry in the past removes a cookie rather than setting one. The scanner recognizes these deletion headers and does not count them.

Everything else is context

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

This split is the core of the product. Most scanners promote every signal they see to "cookie" and over-report. The result is an inventory padded with rows you cannot verify, and a cookie policy that discloses things that are not cookies. UserGuard keeps the context visible. It often explains why a cookie exists, but it never counts it.

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

Read the results

Open the scan detail to see the raw evidence stream: every line the scanner recorded, marked as either verified cookie evidence or context. Nothing is summarized away. If you ever wonder why a cookie is in your inventory, the answer is a specific line in this stream, which header, which store record, or which document.cookie value put it there.

What the next scan does

Rescans reconcile the inventory rather than rebuilding it:

• New cookies appear as new rows.
• Cookies that no longer show up are marked gone, never deleted. The audit trail survives, so you can still show what the site did and when.
• Category decisions made by a person are never overwritten by a scan.

That last rule matters most. Once you have categorized a cookie, rescanning is safe: the scanner updates the evidence, not your judgment.

If a scan fails

A scan that stops making progress, with no page finished for 10 minutes, is marked failed by the cleanup that runs once an hour, and so is one still running well past its limit (about 37 minutes at the default 50 pages, and longer if you raise Pages per scan). Until then the Scan card says it has stopped, and Run a scan comes back once it is marked failed. A scan waiting its turn in the queue is not timed out, however long the line; it is 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, without marking cookies on the pages it did not 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.