Adding cookies the scan can't see

A cookie that's set after login belongs in your policy even though no logged-out scan will ever see it. Here's how to add it by hand and what happens to it afterward.

Why do some real cookies never show up in a scan?

Because the crawler visits your site the way an anonymous visitor does, logged out. It can't reach anything behind a login form, inside a checkout flow or behind a paywall. A session cookie set after sign-in is a real cookie, set on real visitors, and it belongs in your cookie policy. But the scanner never gets to a point where it can observe that cookie, so no scan will ever produce evidence for it.

UserGuard builds its inventory from scan evidence, so you add these cookies separately, as manual cookies.

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

  • Cookie 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. Scanned cookies get categorized during review. A manual cookie has no scan evidence to review against, and the person adding it is the one 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, but it can't 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 goes through the same approval gate as every scanned cookie. The label lets anyone reading the inventory tell what a scan verified from what a person declared.

What do rescans do with manual cookies?

Usually nothing. A rescan never marks a manual cookie as gone. Scans aren't expected to see manual cookies, so a scan that misses one tells you nothing. Flagging it as missing would only raise an alert you'd 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 then on it's a scanned cookie like any other, and its presence or absence in future scans means the same thing it means for every scanned cookie.

Manual cookies are the only ones you can remove by hand. Scanned cookies leave the inventory the same 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. No scan tracks a manual cookie, so when one stops existing, you're the one who knows, and you remove it yourself.

Removal is soft. The audit trail keeps the row, so you can still reconstruct the history of your policy: what was disclosed, when, and on whose word. A removed cookie stops being published, but it stays in the record.

The limits of manual cookies

A manual cookie is something a person declared, with no scan evidence behind it. UserGuard prints the category and retention you stated, but nothing in the system can verify them, so the row rests on the word of the person who added it. When the feature that sets the cookie changes, a scan won't pick that up, so review your By hand entries yourself.