What it is
Cookiebot scans a site, generates a declaration and renders a banner, storing the decision in `CookieConsent`. Storage limited to remembering and enforcing the choice may be necessary, but the exact payload and surrounding services still need review.
`CookieScriptConsent` is not a Cookiebot cookie; it belongs to CookieScript and the scanner classifies it separately.
It appears in scans of sites that have long since moved on, because a leftover script tag in a theme keeps loading it. That is worth catching: two consent systems on one page is worse than one.
What a scan matches
A verification scan drives a real browser and records the outbound requests observed during its configured journeys, so Cookiebot is identified by request hosts and paths rather than by source-code claims. Requests on unvisited paths, after unperformed interactions or solely on the server remain outside that observation.
- cookiebot.com
- cookiebot.eu
Cookies are classified by name before domain because many analytics and advertising tags write first-party cookies through the page, which places a vendor-related identifier on your domain. Matching known names helps attribute those values without assuming that every first-party cookie came from your own application.
| Cookie | What it is for |
|---|---|
| CookieConsent | The visitor’s recorded decision, encoded per category |
Controlling it with consent
Nothing to gate. On a migration, confirm that the Cookiebot script is removed from the theme, from any tag manager, and from any plugin that injected it.
No named adapter: choose the appropriate control
The product ships named adapters for Google Tag Manager, Google Analytics, the Meta and TikTok pixels, and Klaviyo. Choose the control route that fits this technology: a custom HTTPS script declaration for a browser loader, an individual consent condition inside a tag manager, a platform or app setting, or a click-to-load placeholder for a frame. Server-side integrations need their own enforcement because a browser runtime cannot stop them.
What breaks if it is refused: the previous consent implementation, which is the point.
Verifying it
If a fresh profile receives `CookieConsent` alongside another platform’s cookie, investigate an overlapping implementation. A value found only in an existing profile may be stale. Check new Set-Cookie activity, requests, rendered HTML and runtime DOM changes.
- Before a choice: optional tracking endpoints and optional identifiers are absent; any intentionally loaded necessary or functional surface matches the control model described above
- After rejecting optional categories: optional activity remains absent and the refusal persists across a reload
- After granting the relevant category: the expected loader or embed appears and the feature behaves normally
- After withdrawing: new optional activity stops; where the vendor supports a consent signal, verify that the signal is sent as well as checking network behavior
Common questions
Can I run two consent platforms during a migration?
Briefly, and only with care. They will disagree, and the records will not explain themselves afterwards. Plan a cutover rather than an overlap.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- Cookiebot: logging and demonstrating user consent
Vendor documentation
Checked
- Cookiebot: manual cookie blocking
Vendor documentation
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.