What a cookie declaration is — and why yours goes stale

Of all the privacy documents on a website, the cookie declaration is the one most likely to be lying to visitors — not out of dishonesty, but out of neglect. A privacy policy can be broadly worded and stay roughly true for a year. A cookie declaration names specific trackers, and specifics rot. The tool you removed in March is still listed; the pixel your marketing team added in May isn't. Nobody decided to publish inaccurate information — the declaration just quietly stopped matching the site while everyone assumed it still did. Understanding why that happens, and what to do about it, is the difference between a declaration that protects your credibility and one that undermines it.

What a cookie declaration actually is

A cookie declaration is the itemised inventory of the specific cookies and tracking technologies running on your site. It's not an explanation of how you use cookies in general — that's the cookie policy. The declaration is the actual list, and it typically records, for each tracker:

• Name — the specific cookie or tracker identifier (e.g. _ga).
• Provider / domain — who sets it (your own domain, or a third party like Google or Meta).
• Category — strictly necessary, analytics, advertising, or functional.
• Purpose — what it's actually for, in plain language.
• Duration & type — how long it persists, and whether it's first- or third-party.

That precision is exactly why it's useful to visitors — they can see, item by item, what's tracking them — and exactly why it's fragile. Every row is a factual assertion that has to keep being true.

It's not just "cookies" anymore

One reason declarations are more often wrong than owners realise: the word "cookie" has quietly stopped covering the whole job. Regulators have caught up with how tracking actually works. The European Data Protection Board has confirmed that the rules apply well beyond traditional HTTP cookies — tracking pixels, localStorage, sessionStorage, and fingerprinting techniques all fall within the same scope. Advertising and analytics tools increasingly use these as alternatives to classic cookies.

So a declaration that lists only the cookies your site sets — and ignores the pixels and storage mechanisms doing the same tracking job — is already incomplete on the day it's written, before any drift even begins. An accurate declaration has to reflect all the tracking technologies detected, not just the ones with "cookie" in the name.

Why your declaration goes stale

Here's the mechanism, and it's almost never a single dramatic event — it's accumulation. A modern site is a moving target: typical sites run anywhere from 50 to 300-plus cookies, and the set changes every time anyone touches the marketing stack. Three forces drive the drift:

1. Tag managers add trackers without anyone telling you

This is the big one. Google Tag Manager and similar tools let marketing teams deploy new tags without involving a developer — which is convenient, and also exactly how declarations silently fall out of date. Someone adds a new ad tag on Tuesday; the tracker starts firing immediately; your declaration, written months ago, never hears about it. There's no code review, no release note, no trigger to update the list. The tracker is live and undeclared.

2. Third-party scripts bring their own uninvited cookies

When you add one third-party script, you often get more trackers than you bargained for, because scripts load other scripts. This is called piggybacking, and it's not a rare edge case: in routine monthly audits, piggybacking scripts account for roughly 64% of the unauthorised cookies found. You approved one tool; it quietly brought friends. None of them are in your declaration.

3. Ordinary site changes introduce trackers too

Plugin updates, theme changes, a new reviews widget, a swapped analytics tool, an embedded video — each can add or change cookies. Every routine release is a potential change to your real tracker list, and almost none of them prompt anyone to re-check the declaration.

How to tell if yours is already stale

You don't need a tool to get a rough sense of whether your declaration has drifted — a five-minute manual check will usually tell you. Open your site in a private/incognito window (so past consent doesn't interfere), open your browser's developer tools, and look at the Application or Storage tab to see the cookies and storage actually being set on page load. Then compare that to what your published declaration lists. A few things to look for:

• Trackers on the site but not in the declaration — the classic drift. Anything firing that your list doesn't mention is an undeclared tracker.
• Trackers in the declaration but not on the site — the reverse: tools you removed but never delisted. Less risky, but it signals the list isn't being maintained.
• Only "cookies," no pixels or storage — if your list is all classic cookies and mentions no pixels, localStorage, or similar, it's probably missing the non-cookie trackers that now count too.
• A "last updated" date months old — if the declaration hasn't been refreshed since before your last few marketing changes, assume it's behind.

This manual check is genuinely useful for a spot inspection, but it has the same limits any human review does: it's a single page, a single moment, and it's easy to miss trackers that load a few seconds late or only on certain routes. It tells you whether you have a drift problem; it doesn't keep the declaration current for you.

How often should it be updated?

There's no single frequency written into law — and that's actually the key insight. What the law asks for is accuracy, not a schedule. The right cadence is simply whatever keeps your declaration matching your live site. That said, the practical guidance from the field is fairly consistent:

• Monthly is a common minimum for any live site.
• Weekly is recommended for active sites — e-commerce, publishers, or anyone running frequent marketing campaigns where tags change often.
• After every significant change — a new marketing tool, a plugin update, a site release — re-scan, because that's precisely when new cookies appear.

The trap with a fixed monthly scan is the gap it leaves. If you scan on the 1st and marketing adds a pixel on the 3rd, that tracker is undeclared for 28 days until the next scan catches it. For a low-change brochure site that's a manageable risk; for an active store it's a recurring exposure. The frequency should track how fast your site actually changes, not a calendar convenience.

Why accuracy is getting harder to let slide

It's worth being clear-eyed about why this matters more now than it did a few years ago — not as a scare tactic, but as context. Enforcement of cookie rules has intensified sharply: France's data protection authority, the CNIL, imposed around €55 million in fines in 2024, and that figure rose to roughly €487 million in 2025 — driven largely by cookie-related penalties. Whatever the exact figures turn out to be next year, the direction is unmistakable.

More telling than the size of the fines is how regulators now check. Data protection authorities increasingly rely on automated crawlers rather than manual review — bots that load your pages from different locations and record which trackers fire, and when. That changes the nature of a stale declaration. It's no longer a discrepancy that only surfaces if someone complains; it's something a crawler can detect directly, by comparing what your site actually does against what you've declared. An out-of-date declaration is exactly the kind of gap automated enforcement is built to find — which is another way of saying accuracy is no longer something you can quietly let drift.

The honest catch: not every scan sees everything

Here's something most tools won't tell you, and it matters for whether your declaration is actually complete. A shallow scan can miss the very trackers most likely to be undeclared. Simple scanners that only read a page's initial HTML don't see trackers injected at runtime by a tag manager — which, as we just covered, is the single biggest source of drift. So a declaration built from a shallow scan can look complete while missing exactly the trackers that a plaintiff's or regulator's deeper tool would find.

How to keep a declaration that stays true

If the problem is that a declaration is a snapshot of a moving target, the fix is to stop treating it as a document you write and start treating it as data you keep synced. Three things make that work:

• Generate it from a real, deep scan — so it reflects what's actually running, including runtime-injected and non-cookie trackers, from day one. A scan-synced declaration does this by construction.
• Re-sync on a cadence that matches your change rate — weekly for active sites, monthly at minimum, and after any significant change.
• Get told what changed. The most useful thing a system can do is flag the drift explicitly — "new trackers found since last sync" — so you're not trusting a list you haven't looked at in months. Silent updates keep the list current but leave you unaware; surfaced drift keeps you informed about your own site.

Disclaimer: This article is general information, not legal advice, and does not create an attorney–client relationship. Requirements for cookie disclosures and consent vary by jurisdiction and change over time. ConsentPixel — Privacy · Verified is not a law firm, and generating or syncing a cookie declaration does not by itself make a website compliant with any law. Consult qualified counsel for your specific situation.