Switching off Cookiebot? Seven things to check before you do

Short answer: the CMP is the easy part of the swap. What breaks is everything downstream that was quietly depending on the old one — code reading a cookie that no longer exists, GTM triggers listening for events nobody fires any more, Consent Mode defaults that were configured inside the vendor's dashboard rather than in your container, and your record of who consented to what. Scan the live site before you touch anything, keep the scan, repeat it after the swap under the same conditions, and compare. If the two scans don't match, you didn't migrate a banner — you removed one.

We're not going to tell you which CMP to move to. The reason is in the disclosure below.

Cookiebot pricing is usually the trigger, and it scales by page count

The migration conversation almost always starts with an invoice rather than a technical complaint, so be precise about the shape of the pricing.

As of 29 July 2026, Cookiebot's own pricing page lists a free tier limited to one domain and up to 50 subpages, then Premium tiers billed per domain per month and stepped by how many subpages get scanned: up to 50, up to 350, up to 3,500, up to 7,000, and above that. In euros the published steps run from €7 to €90 per domain per month, and the page carries a currency selector, so the figure you see depends on which one you pick. Two things follow: a site grows into a higher tier without anyone deciding anything, and multi-domain estates multiply by domain.

That's a real reason to look around. It isn't a reason to treat the swap as a plugin change, because the price is the only part of your setup that's actually about the CMP.

1. What your current setup genuinely blocks, measured before you change it

Do this first, because after the swap you lose the ability to establish it.

Load the site in a fresh browser profile, accept nothing, and record every cookie set and every network request made before any interaction with the banner. Repeat for a rejection and an acceptance, and save the output. That baseline is the only thing that will let you answer "did the new CMP make this worse?" with evidence rather than memory.

Most people skip it and assume the current setup blocks correctly. It frequently doesn't — we've written up the reasons a Cookiebot install fires tags anyway, and none of them are the CMP's fault. Finding a pre-existing leak during a migration is good news, as long as you find it before the swap rather than inheriting the blame for it after.

2. Every line of code that reads a Cookiebot-shaped consent state

This is the failure that stays silent for months, because nothing errors — the checks just quietly return false.

Cookiebot's documented interface is specific to Cookiebot. Consent is stored in a first-party cookie named CookieConsent, holding the state across four categories: necessary, preferences, statistics and marketing. In the page it exposes a Cookiebot.consent object with a boolean per category, and it fires events named CookiebotOnConsentReady, CookiebotOnAccept, CookiebotOnDecline and CookiebotOnTagsExecuted.

None of those names are standard. A different CMP writes a different cookie with different category names and fires nothing called CookiebotOnAccept. So grep the whole estate — theme files, custom JavaScript, GTM custom HTML tags, server-side rendering that reads the cookie to decide what to embed — for Cookiebot, CookieConsent, and each of the four category names. Every hit is a decision you have to port by hand.

The dangerous ones read "fire this if consent is granted": after the swap the condition can't be satisfied, so the tag never fires and your analytics goes quiet with no error anywhere. The mirror image is worse — "block this if consent is denied", now unable to see a denial, firing for everyone.

3. GTM trigger wiring, including the trigger that runs before everything else

Your container almost certainly has consent logic in three places, and only one of them is obvious.

The obvious one is triggers listening for a CMP-specific dataLayer event. Those break by name.

The second is the Consent Initialization trigger. Google's documentation is direct about what it's for: it "is used for tags that set or update the user consent state for your site, such as a consent management platform tag or tags that set consent defaults", and it "will always fire before all other tags, including any Initialization triggers". If your old CMP tag sat there and the new one gets dropped onto All Pages instead, the ordering breaks and tags can run before any consent state exists.

The third is per-tag: GTM's built-in consent checks and the Additional Consent Checks setting, which offers "Not set", "No additional consent required", and "Require additional consent for tag to fire". These are configured tag by tag, they don't appear in any trigger list, and they survive a CMP swap untouched — which sounds good until you realise they were tuned against the old consent model. Audit them.

4. Consent Mode defaults, which may not live where you think

The seven consent types Google defines — ad_storage, ad_user_data, ad_personalization, analytics_storage, functionality_storage, personalization_storage and security_storage — are Google's, not any CMP's, so the vocabulary survives the migration. What doesn't survive is your configuration of it.

Google's position is that "by default, consent may be denied, unless you set your own defaults". Most CMPs let you set those defaults in their dashboard, often with different values by region, and that configuration lives in the vendor's system. It is not exported, and the new vendor will not read it. Screenshot every region rule before you cancel the account.

Then check the ordering, because that's where the swap actually bites. If the new CMP loads later than the old one did, there's a window on each page load where tags are live and no default has been set. If you want the difference between the two implementation models and what modelling does or doesn't recover afterwards, we've covered Basic versus Advanced Consent Mode separately.

5. TCF strings do not port, and the spec says why

If you're running IAB TCF — publishers and anyone selling programmatic inventory usually are — this is the item most migration checklists miss.

The TCF v2 specification leaves storage to the vendor: "the storage mechanism used for service-specific and group-specific TC Strings is up to a CMP, including any non-cookie storage mechanism." There is no mandated cookie name to hand over. On top of that, the consent string itself encodes a CmpId — the "Consent Management Platform ID that last updated the TC String" — along with the version of the Global Vendor List the choice was made against.

So a string written by your old CMP records your old CMP as its author, against a vendor list from that date. A new CMP that inherits it is presenting someone else's record as its own. In practice most CMPs re-prompt instead, which is the defensible outcome — just plan for it, because it means a fresh banner for your entire returning audience on day one, and a consent rate that dips while the base rebuilds. Don't read that dip as the new CMP underperforming.

6. The consent-record continuity problem, which is the one with legal teeth

Your proof of consent may not be yours to move.

The ICO's guidance, finalised on 29 April 2026, is short about the obligation: "You must be able to demonstrate that someone has provided consent." It notes that most providers use a CMP to store those records, and that you have to work out whether the provider is acting as your processor.

Look at how the proof mechanism actually works. Cookiebot's own documentation describes logging, for each consent, an anonymised IP, the date and time, the browser user agent, the URL it came from, an encrypted key, and the consent state — stored server-side by Cybot, the company behind Cookiebot, with the same key written into the visitor's CookieConsent cookie for up to 12 months. Demonstrating a specific person's consent means taking the key from their browser and looking it up in Cookiebot's log.

Both halves of that break in a migration. The new CMP overwrites or ignores the old cookie, so the key goes. And the lookup half sits in the account you're closing. Before you cancel: export the consent log — Cookiebot offers a CSV download from the User consents screen — and decide where it lives afterwards and for how long. Nobody has an obvious home for a CSV of consent records, which is exactly why it gets left behind. The Article 29 Working Party guidance that Cookiebot itself quotes is unambiguous that the obligation to demonstrate consent lasts as long as the processing does, and that it "would not be sufficient to merely refer to a correct configuration of the respective website".

7. The same scan, after, under the same conditions

Run the scan from item 1 again. Same tool, same pages, same fresh-profile conditions, same three states: no interaction, reject, accept.

Compare the two outputs rather than reading the second one on its own. What you're looking for is anything that fired pre-consent in the "after" run and didn't in the "before" run, any tag that stopped firing after acceptance, and any Consent Mode parameter missing from the requests reaching Google.

Do it from a device in the country your customers are in. Geo-gated CMP logic behaves differently depending on where the request appears to come from, and a scan run from the wrong region tests a banner your visitors will never see. That's a real trap — it's currently a known limitation in our own scanner's infrastructure, and we'd rather say so than let you draw a confident conclusion from it.

Why we refuse to hand you a ranked list

Certification doesn't settle it either, which we went through in why a Google-certified CMP still isn't a compliant one: certification tests whether a product can pass consent signals correctly, not whether your installation does.

So choose on integration fit — does it work with your CMS, your GTM setup, your TCF requirements, your budget — and then verify behaviour yourself, because no vendor's marketing and no comparison table can tell you what your site does at runtime. Anyone who skips that check is trusting a feature list.

Once you've picked, the migration risk sits in the seven items above rather than in the vendor choice. If you'd rather have the swap done with the tag wiring, the Consent Mode defaults and the before-and-after verification handled properly, that's what we do.

Sources

1. 1.Cookiebot — Pricing page (free tier limits and the per-domain Premium tiers) · Checked 2026-07-29
2. 2.Cookiebot — Developer resources: the CookieConsent cookie, the Cookiebot.consent object and the CookiebotOn* events · Checked 2026-07-29
3. 3.Cookiebot Support — Logging and demonstration of user consents (what is logged, and how proof of consent is looked up) · Checked 2026-07-29
4. 4.Google — Consent mode: the seven consent types and default consent states · Checked 2026-07-29
5. 5.Tag Manager Help — Consent Initialization trigger and Additional Consent Checks · Checked 2026-07-29
6. 6.IAB Tech Lab — Transparency & Consent String and Global Vendor List Format v2 (CmpId; storage mechanism left to the CMP) · Checked 2026-07-29
7. 7.ICO — Guidance on the use of storage and access technologies: 'How do we manage consent in practice?' (records of user preferences) · Finalised 29 April 2026, checked 2026-07-29