Adding cookies the scan can't see

Why some real cookies never show up in a scan

The crawler visits your site the way an anonymous visitor does: logged out. Anything on the other side of a login form, inside a checkout flow, or behind a paywall is outside its reach. A session cookie set after sign-in is real, it is set on real visitors, and it belongs in your cookie policy, but no scan will ever produce evidence for it, because the scanner is never in a position to observe it.

UserGuard's inventory is built on scan evidence, so these cookies need a separate way in. That is what manual cookies are for.

Adding a cookie by hand

On the Cookies tab, use Add a cookie. The form asks for:

• Name and domain — copy these exactly. The most reliable way to get them right is to log in yourself and read the cookie from your browser's developer tools.
• Category — required. For scanned cookies, categorization happens during review. Here there is no scan evidence to review against, and the person adding the cookie is the person who knows why it exists, so you state the category up front.
• Provider and purpose — who sets it and what it does.
• Retention — a stated lifetime, for example 30 days. A scan can measure a normal cookie's expiry; no scan will ever measure this one, so you declare it. The cookie policy prints the retention exactly as you stated it.

The cookie joins the inventory labeled By hand and passes the same approval gate as every scanned cookie. The label is deliberate: anyone reading the inventory can tell what a scan verified from what a person declared.

What rescans do with manual cookies

Nothing, usually, and that is by design. A rescan never marks a manual cookie as gone. "The scan didn't see it" is the normal condition of a manual cookie, so a scan that doesn't see it carries no information. Flagging it as missing would raise an alert you would learn to ignore.

If a scan later does observe the same cookie (say it starts being set before login) the row upgrades to scan evidence automatically and rejoins the normal lifecycle. From that point on it is a scanned cookie like any other, and its presence or absence in future scans means what it means for every scanned cookie.

Removing a manual cookie

Only manual cookies can be removed by hand. Scanned cookies leave the inventory the way they entered it: through scans. When a scanned cookie stops being set, the next scan records its absence and the lifecycle handles the rest. A manual cookie has no scan to speak for it. When it stops existing, you are the one who knows, so you remove it yourself.

Removal is soft. The audit trail keeps the row, so the history of your policy can still be reconstructed: what was disclosed, when, and on whose word. Nothing you added disappears from the record; it just stops being published.

The honest limit

A manual cookie is a declaration, not evidence. UserGuard prints the category and retention you stated, but nothing in the system can verify them. The row rests on the word of the person who added it. Treat that as a responsibility: when the feature that sets the cookie changes, the scan won't notice on your behalf. Review your By hand entries yourself, because for these cookies, you are the scanner.