PROVIDER Β· Automatic scanning plus consent
Cookiebot
Cookiebot started in Denmark in 2012 and joined Usercentrics in 2021, scanning the third-party cookies a site actually loads and generating a four-category consent banner with geographic modes, Google Consent Mode, and TCF v2.2 support.
Pros
Cons
Product Information
Detailed Notes
Overview
Cookiebot started in Denmark in 2012 and became Usercentrics' brand for smaller sites after the 2021 acquisition. Its order of operations is scan first, control second: a scanner captures the third-party scripts a site actually loads, sorts cookies into necessary, preferences, statistics, and marketing, and generates a matching consent banner.
That discover-then-declare sequence is the point. Most compliance incidents are not broken banners but policies that declare a different cookie set from what the page loads, and scanning surfaces that gap while producing an audit-ready consent log.
As a Compliance & Legal tool it also switches consent mode by geography, defaulting to opt-in in Europe and allowing opt-out in parts of the US, and supports Google Consent Mode plus TCF v2.2. Those determine whether ads and analytics still run after consent.
Core Strengths
- Scans the third-party cookies a site actually loads and sorts them into four categories, closing the policy-versus-reality gap
- Switches consent mode by visitor geography, covering GDPR opt-in and opt-out requirements in parts of the US
- Consent logs and exportable proof records that stand up in audits and client questionnaires
- Google Consent Mode and IAB TCF v2.2 support so ads and analytics keep working after consent
Product Ecosystem
Automatic scanning and cookie inventory
The scanner rescans monthly and flags newly added third-party scripts for declaration. Results still need human confirmation, since dynamically injected, lazily loaded, and iframe-embedded scripts are regularly missed.
Consent banner and signal output
Banners allow per-category and per-vendor consent and write results into Consent Mode and TCF signals. The commercial difference shows up in consent rate, where copy, button hierarchy, and rejection symmetry all move both consent and ad revenue.
Drawbacks
- The free tier is single-domain with branding, so multi-site operators hit the ceiling quickly
- The scanner misreads dynamically injected and iframe scripts, so human verification cannot be dropped
- Brand and plan structure have been in flux since the Usercentrics acquisition, leaving older docs stale
- Chinese UI and support are limited, leaving mainland China compliance scenarios to in-house work
Use Cases
- Sites serving European users (β β β β β ) - Automatic scanning plus geographic consent mode is the low-effort GDPR path
- AdSense-monetized sites (β β β β β) - TCF v2.2 and Consent Mode wiring decides European eCPM
- Multilingual cross-border stores (β β β β β) - Region-based consent modes avoid forcing one banner everywhere
- Mainland-China-only businesses (β β ) - Missing local templates and Chinese support limit the value
Pricing
| Plan | Price | Scope |
|---|---|---|
| Free | $0 | Single domain, basic scanning and banner, branded |
| Premium | Monthly | Multiple domains, Consent Mode, log export |
| Enterprise | Custom quote | Multi-site, custom terms, and support SLA |
Tiers differ mainly in domain count, scan frequency, and log export, with current prices on the official site. Do not judge on subscription cost alone, since a few points of consent rate can cost more ad revenue than the subscription itself, which makes banner A/B testing worthwhile.
FAQ
-
Do scan results need manual work? Yes. Scanning covers most statically loaded scripts but regularly misses dynamically injected, lazily loaded, and iframe-embedded ones, so compare the inventory against real browser requests before launch.
-
What happens without Consent Mode? Google treats traffic without signals as unconsented, degrading personalisation and conversion modelling, which shows up as lower eCPM and missing attribution. Sites monetizing with ads should treat it as mandatory.
-
Can it coexist with an existing policy? Yes, but the cookie inventory in both documents must match or audits expose the mismatch. Correcting policy text from scan results is the usual pattern rather than maintaining two lists.