Introduction
Explain what a Cookiebot scan can discover, what an inventory crawl cannot prove, and how to verify consent behavior independently on a live website.
This guide is written for website owners, privacy teams, marketers, and developers reviewing Cookiebot scan results.
What it means
Quick answer: a Cookiebot scan crawls reachable HTML pages and looks for detectable cookies and tracking technologies. Its official documentation lists HTTP and JavaScript cookies, local storage, IndexedDB, pixel tags, and other tracker types. The report can include category, provider, type, first-found URL, initiator, source, and tag-manager path where available.
Cookiebot says its scanner follows navigable content such as static and dynamic pages, links, embedded videos, pop-ups, and other interactive elements. Review the discovered URL list because sitemap quality, duplicate URLs, regional delivery, login barriers, and unlinked journeys can change coverage.
Coverage depends on the pages reached, regional delivery, authentication, delayed interactions, tag-manager rules, and whether a technology appears only after a user action.
An inventory result does not by itself prove that every non-essential request is blocked before consent or that Reject, granular choices, withdrawal, and repeat visits work correctly.
Validate the live consent flow in separate clean sessions and inspect network requests, cookies, local storage, pixels, iframes, and consent signals in every important state.
Reconcile the observed inventory with banner categories, the cookie declaration, privacy disclosures, vendors, purposes, retention, and the team's tag register.
Repeat both inventory and runtime tests after CMP, tag-manager, CMS, plugin, campaign, or application releases because scan findings are a time-specific snapshot.
Teams evaluating a replacement can use the Iubenda vs Cookiebot comparison to separate scanner coverage from consent enforcement, policy tooling, pricing, and migration effort.
Why it matters
Cookie discovery and consent enforcement answer different questions. Discovery asks what technology exists; runtime verification asks whether the website respects a visitor's choice before and after interaction.
Using both layers helps teams avoid a common false positive: a complete-looking cookie declaration paired with scripts that still initialize too early or remain active after rejection or withdrawal.
Common mistakes
- Treating a successful inventory crawl as a GDPR certificate or legal conclusion.
- Scanning only the home page while ignoring checkout, account, blog, campaign, embedded-media, and authenticated templates.
- Testing only after Accept and never testing untouched, Reject, granular choice, withdrawal, expiry, or returning-visitor states.
- Reviewing cookies but ignoring requests, local and session storage, pixels, iframes, SDKs, and server-side destinations.
- Assuming an unknown item is harmless instead of identifying its owner, purpose, trigger, legal basis, and retention.
- Failing to rescan after a tag, plugin, CMP, CMS, or marketing release changes production behavior.
What a Cookiebot scan checks—and what needs separate verification
| Area | What the scan can show | What to verify separately |
|---|---|---|
| Cookies and storage | Detected HTTP/JavaScript cookies, local storage, IndexedDB, and other supported tracker types | Items triggered only in unreached regions, sessions, forms, accounts, or journeys |
| Pixels and embedded technology | Detected pixels, scripts, iframes, images, videos, initiators, and sources | Whether every custom integration stays blocked in each consent state |
| Pages and discovery | Reachable HTML pages and a discovered URL list | Authenticated areas, unlinked routes, campaign variants, checkout completion, and application states |
| Classification | Necessary, preferences, statistics, marketing, or unclassified inventory entries | Whether each purpose, provider, category, retention period, and legal basis is correct |
| Prior-consent findings | Potential cookies or trackers observed before consent during the crawl | Untouched, Reject, granular choice, Accept, withdrawal, expiry, and repeat visits in clean sessions |
| Compliance conclusion | Technical evidence from a time-specific automated crawl | Legal sufficiency, contracts, rights handling, security, governance, and future regressions |
Practical checklist
- List representative URLs for every template, market, language, authenticated state, and high-risk user journey.
- Run the Cookiebot inventory scan and export or record each detected technology, provider, category, page, and unknown item.
- Open a clean browser session and capture requests, cookies, storage, pixels, and consent signals before touching the banner.
- Repeat the capture after Reject, granular choices, Accept, withdrawal, consent expiry, and a returning visit.
- Compare observed behavior with CMP configuration, tag-manager triggers, cookie declarations, privacy policy, vendor list, purposes, and retention periods.
- Assign every mismatch to an owner, fix high-risk pre-consent activity first, and preserve timestamped evidence of the retest.
- Schedule rescans after relevant releases and at a recurring cadence to catch configuration drift.
How GDPRChecker helps
Use the GDPR compliance checker as an independent technical check alongside Cookiebot to observe production requests, storage, trackers, and consent-state behavior rather than relying only on CMP configuration.
Scanner findings are technical evidence, not legal certification. Legal bases, contracts, rights handling, retention, security, and policy wording still require accountable review.