Cookie scanner: know what your site really sets

Ask a website publisher how many cookies their site sets: the answer is almost always lower than reality. A theme, a few plugins, an embedded video, an analytics tool, a support chat, and the inventory becomes impossible to keep in your head. Yet this inventory conditions both compliance and the proper functioning of your banner.

Why the inventory is an obligation, not a good practice

The GDPR requires "specific" information: the visitor must know which trackers are set, by whom and for what purpose. The CNIL (the French data protection authority) regularly reminds publishers of this: a banner that lists three vague categories without detailing the actual trackers does not meet this requirement.

The inventory also feeds your record of processing activities and your privacy policy. Without it, you document intentions, not the reality of your site.

Finally, there is a purely technical issue: you cannot block what you have not identified. A third-party script missing from your configuration will slip through automatic blocking and set its cookies before any consent.

What a scanner does

A cookie scanner loads your pages in an automated browser, without interacting with the banner, and observes what happens. It records the cookies set, the domains contacted, the scripts loaded and the data stored in localStorage. It then matches these elements against a knowledge base to suggest a vendor, a purpose and a lifetime.

The result is a directly usable table: cookie name, issuing domain, suggested category, duration. It is the starting point for configuring your banner and the foundation of your cookie policy page.

Its limits, which you need to know

An automated scan is not exhaustive, and tools that claim otherwise are lying:

• It only sees the pages it visits. A checkout funnel page or a form page may load trackers absent from the home page.
• It does not see what is behind authentication, unless specifically configured, yet the customer area is often the most instrumented part of a site.
• It does not trigger conditional scripts tied to a scroll, a click or a delay.
• It cannot guess your real purpose. The suggested categorization remains a suggestion: you, as the controller, validate it.

The right way to use it is therefore to treat it as a revealer, not as a complete audit. It finds what you had forgotten; it does not certify that you have forgotten nothing else.

The real subject: drift over time

A scan at a single point in time has limited value, because a site changes. An updated plugin adds a pixel, a marketing team adds a tag for a campaign, a service provider changes subprocessor. Within a few months, the inventory validated during the compliance work no longer describes the site.

This is where the scheduled re-scan becomes useful: instead of repeating the audit by hand, the tool reruns the scan periodically and alerts you only on the difference: the cookie that appeared, the newly contacted domain. You do not reread a hundred lines, you handle a notification.

At Consenteer, the home page scan is available in all plans; the scheduled re-scan with change alerts is included from the Pro plan, and multi-page scanning followed by authenticated pages are being prepared.

A realistic routine

A rhythm that works for most sites:

1. A full scan at launch, then manual validation of each categorization.
2. An automatic monthly re-scan, with alerts on new items only.
3. A one-off scan after any significant production release or the installation of a marketing tool.
4. A half-yearly review of the cookie policy in light of the inventory.

Once the inventory is reliable, the rest follows: automatic blocking prevents the identified scripts from loading until consent is given, and the consent log documents the choices. The order is what matters: inventory, then block, then prove.