How often to rescan your site for new cookies

What actually changes between scans

A cookie inventory is a snapshot, not a fact. It describes what a site did on the day it was scanned. Sites change constantly, and most of the changes that add cookies are not made by the person who owns the banner. That is the whole problem in one sentence.

Marketing adds a tag through the tag manager on a Tuesday afternoon. A vendor ships a minor SDK update that starts writing an identifier it did not write last quarter. A seasonal campaign drops a retargeting pixel that stays live long after the campaign ends. A CMS plugin update introduces a session cookie nobody asked for.

None of these show up in a changelog you read. They show up in a browser, on a page, before or after a visitor makes a choice. The gap between when the change lands and when you notice it is the window you are trying to shrink.

How often should you rescan for new cookies?

Monthly is the right default for scheduled scans. It is frequent enough that drift stays measurable — a handful of changes, not a year of them, and infrequent enough that nobody starts ignoring the results. Weekly scanning on a site that ships twice a year produces noise. Quarterly scanning on a site with an active marketing team produces surprises.

Scheduled scans are the floor, not the plan. The scans that catch real problems are the ones triggered by a change you already know about. If something shipped, rescan — the cost is a few minutes, and the alternative is hearing about it from someone else. On a portfolio, the same discipline has to reach the small sites; the forgotten microsite is usually the one still running the oldest pixel.

Treat the triggers as a habit rather than a document. The teams that stay current are the ones where a rescan sits on the deploy checklist next to clearing the cache. Three events are worth a rescan every time, no matter how small the change looks:

• Any deploy, theme change, or plugin update
• New tags or vendors added in the tag manager
• Campaign launches, and the week a campaign ends

Reading the diff between two scans

A rescan is only useful if it produces a comparison. The number that matters is not how many cookies the site has. It is which ones are new since last time, which disappeared, and which changed behavior — a different domain, a longer expiry, a first-party record that quietly became a third-party call.

UserGuard is designed around an evidence gate for exactly this reason. A record is only labeled a cookie when there is proof: a Set-Cookie header, an HTTP-only record, or a document.cookie value. Everything else — storage entries, pixel requests, general network chatter — is kept and labeled as context. A diff full of maybes is a diff nobody reads twice.

The other half of a good diff is timing. A new cookie that fires only after a visitor accepts is a disclosure task. The same cookie firing before any choice is made is a different problem entirely, and it is the one regulators keep writing about. Your scan should tell you which of the two you are looking at.

The regulatory clock behind the cadence

Under GDPR and ePrivacy the rule is prior opt-in: nothing non-essential fires before consent, rejecting must be as easy as accepting (that equal-prominence expectation comes from regulator guidance and the EDPB rather than the GDPR text itself), and withdrawal must be as easy as giving. In the UK the stack is UK GDPR plus PECR, now diverging through the Data (Use and Access) Act 2025, which raised PECR fines to UK GDPR levels.

US rules run the other way. CCPA/CPRA is an opt-out regime — notice at collection, a Do Not Sell or Share My Personal Information mechanism, and mandatory honoring of Global Privacy Control. As of 2026, 19+ comprehensive state laws are in force, with Indiana, Kentucky, and Rhode Island among the recent additions; twelve states require honoring universal opt-out signals, and Maryland bans the sale of sensitive data outright. None of this is legal advice, and counsel should confirm what applies to you.

Enforcement has followed the drift. The clearest case for anyone thinking about cadence is Todd Snyder, which paid $345,178 in 2025 over a banner that was simply misconfigured. Nobody disputed the policy. The mechanism was broken, and it stayed broken long enough to be found, which is exactly the failure a routine rescan exists to catch first.

Making each rescan produce evidence

A rescan is also a chance to check the wiring, not just the inventory. Google has required Consent Mode v2 since March 2024 for advertising and measurement features covering EEA and UK users, and it carries four signals: ad_storage, analytics_storage, ad_user_data, and ad_personalization. A tag added last month is exactly the sort of thing that ends up outside that wiring. UserGuard is not a Google-certified CMP and is not IAB TCF validated; TCF support is roadmap only.

Article 7(1) expects you to be able to demonstrate consent, which means records rather than intentions. UserGuard is designed to log consent events against the site, the banner version, the region, and the timestamp, exportable as CSV. Paired with scan history, that is meant to give you a before and after: what the banner said, what the site did, and when the two diverged. UserGuard is newly launched, so that describes how it is built, not a track record.

Accessibility drifts for the same reasons and deserves the same rhythm. WCAG 2.1 AA is the working benchmark, the European Accessibility Act has applied since June 2025 with EN 301 549 as its yardstick, and no widget makes a site ADA compliant — the FTC's 2025 order against an overlay vendor settled that argument. Which of those apply to you depends on where you operate, and that is a question for counsel rather than a scanner.

The accessibility widget comes with every site rather than as an upsell. Pricing is $10 per site per month, dropping automatically as you add sites (current rates). Every feature sits on every tier, which is why GPC handling and geo-targeting are never paywalled.

Go deeper: scan scheduling in UserGuard