A one-time scan goes stale fast

You scanned your site the week you installed a consent banner, mapped every cookie to a category, and wrote a cookie policy that matched. Then you shipped a new landing page, marketing added a LinkedIn tag through Google Tag Manager, and a plugin update quietly pulled in a new third-party font. None of that showed up in your original scan. Your inventory is now wrong, and so is the disclosure you show visitors.

Cookie inventories drift because websites change constantly and the people changing them rarely think about consent. The question isn't whether new trackers will appear. It's how quickly you'll catch them. That's a cadence decision, and most teams never actually make it. They scan once, feel compliant, and never look again.

Why stale inventories are a real risk, not a theoretical one

Regulators treat undisclosed and pre-consent trackers as live violations. In 2025 alone, France's CNIL issued 83 sanctions totalling roughly 486.8 million euros, with trackers a dominant theme, including fines of 325 million and 150 million euros on two major players. The recurring finding: cookies dropped before the visitor made a choice, or trackers that kept firing after a decline.

The scale of the problem is well documented. A 2024 study by researchers at the University of Amsterdam and ETH Zurich, analysing around 100,000 European websites, found that 65% ignored users' rejection choices and kept tracking. A lot of that isn't malice. It's drift. A tag got added, nobody re-checked the consent gate, and the inventory silently fell out of sync with reality.

A baseline cadence that works for most sites

There's no legal number for scan frequency, so anchor it to how often your site actually changes and how much tracking you run. A sensible default for most small-to-mid businesses:

Monthly automated scan for the whole site. This is the floor. It catches slow drift from plugin updates, new embeds, and marketing tags without anyone having to remember.
Quarterly deep review where a human reads the scan output, reconciles it against your cookie policy, and checks that categories still map correctly. The scan finds cookies; a person decides what they mean. Pair this with your consent audit.
Off-cycle scan on every material change (more on triggers below). Don't wait for the monthly job if you just launched a campaign microsite.

High-change sites need more. If you deploy weekly, run marketing experiments constantly, or operate an ad-funded publisher property where new vendors appear through header bidding, move to weekly automated scans. The cost of scanning is low; the cost of a stale inventory is a fine and a broken cookie policy.

Scan the whole site, not the homepage alone

Trackers hide on the pages you scan least. Checkout flows, gated content, campaign landing pages, and blog posts with embedded videos often carry cookies the homepage never sets. A scan that only hits your root URL will miss them. Configure your scanner to crawl your sitemap plus any important URLs that sit behind noindex or on subdomains, so the pages most likely to leak trackers actually get checked.

Events that should trigger an immediate scan

Time-based cadence catches slow drift. Event-based scanning catches the fast kind, the changes that introduce trackers overnight. Run an off-cycle scan whenever:

You add or change a marketing tool

New analytics, a new pixel, a chat widget, an A/B testing tool, a heatmap script. Each one can set cookies and open connections you haven't categorized. This is the single most common source of drift.

You install or update a plugin or theme

On WordPress, Shopify, and similar platforms, plugins bundle their own trackers and update without warning. A plugin that was cookie-free last month can start loading a third-party script after an update.

You embed third-party content

YouTube videos, Google Maps, social media widgets, and embedded forms all pull in external cookies. One embedded video on a single blog post can add tracking to that page.

You launch a new site section or campaign

New landing pages, subdomains, and microsites often start life outside your consent setup entirely. Scan them before they go live, not after.

You migrate platforms or redesign

A rebuild reshuffles everything. Treat the post-launch scan as mandatory, the same way you'd treat testing the checkout.

Between scans, drift is invisible unless you monitor for it

A monthly scan leaves up to 30 days where a newly added tracker fires unblocked and undisclosed. That gap matters most on fast-moving sites. Runtime drift detection closes it: instead of waiting for the next scheduled scan, it watches for trackers and network connections that fire in real time and flags anything new. Scanning and drift monitoring solve the same problem on different clocks. Run both.

Consent expiry is a separate clock

Re-scanning tells you what cookies exist. It doesn't refresh the consent behind them. Those are two different maintenance jobs. France's CNIL recommends limiting analytics cookie lifespans to 13 months and re-asking for consent at appropriate intervals (commonly cited around six months), and the UK's ICO points to a similar six-month interval for re-prompting, especially after a decline. So your calendar has two recurring items: scan for new cookies, and refresh consent that's gone stale. For the second, see our guide on consent expiry and re-consent intervals.

Your re-scan cadence checklist

Monthly automated full-site scan
The floor for any site. Catches slow drift without relying on memory.
Weekly scans for high-change or ad-funded sites
If you deploy often or run header bidding, monthly is too slow.
Off-cycle scan on every material change
New tool, plugin update, embed, or campaign launch triggers a scan now.
Quarterly human review of scan output
A person reconciles findings against your cookie policy and categories.
Whole-site crawl, never the homepage alone
Include checkout, gated pages, campaign URLs, and subdomains.
Runtime drift detection between scans
Closes the gap where new trackers fire before the next scheduled scan.
Separate reminder for consent expiry
Scanning finds cookies; it doesn't refresh stale consent. Track both.

Make re-scanning automatic

CookieBeam runs an automatic monthly re-scan of your domain and configured URLs, so drift gets caught without anyone remembering to press a button, and you can run manual scans anytime you ship a change. Its drift detection watches the running page for new trackers and connections between scans, flagging anything that appears so your inventory and your cookie policy stay in sync. To understand what a modern scanner actually inspects, read how cookie scanners work and our breakdown of automated scanning versus manual audits.