Migrating from Cookiebot to CookieScript: A Step-by-Step Guide

When replacing Cookiebot with CookieScript, start with the setup you already have. Document the cookie classifications, scripts, tags, consent settings, domains, languages, and any other configuration details you may need later.

That gives you the reference point for rebuilding the consent and tag logic in CookieScript.

Do the migration in staging first. Removing Cookiebot before the replacement is ready can disrupt tracking, blocking, or consent signals, while letting both platforms control consent at the same time can create a different set of conflicts. Keep a rollback copy until CookieScript has been tested in production across the pages, regions, browsers, and devices you support.

Can You Migrate from Cookiebot to CookieScript Automatically?

CookieScript does not offer a general Cookiebot importer.

You should expect to rebuild the setup manually:

• Cookie Banner settings
• Domains and cookie categories
• Blocking rules
• GTM configuration
• Google Consent Mode settings

Historical consent records, consent identifiers, and saved visitor preferences should not be expected to transfer.

Cookiebot consent logs can still be exported for record keeping. There is no documented process for uploading them into CookieScript’s consent records, so keep those exports as a separate historical archive.

After that, create the CookieScript configuration, remap the cookie categories, and rebuild the consent and tag controls. If your plan supports consent recording and you enable it, CookieScript can begin recording new choices after the migration.

Will Existing Cookiebot Preferences Transfer to CookieScript?

No—do not assume that a visitor’s Cookiebot choice will transfer automatically.

Cookiebot and CookieScript store and interpret consent differently. CookieScript does not document a process for converting existing Cookiebot preferences.

If you want to preserve an earlier choice, you need a reliable technical mapping that keeps the meaning of the original consent intact. If you cannot demonstrate that, asking the visitor to choose again may be the cautious option.

A platform change by itself does not automatically mean renewed consent is required in every case.

At the same time, you should not treat the old preference as valid in CookieScript unless you have evidence that it covers the same processing.

Step 1: Audit and Document Your Cookiebot Setup

Before removing anything, find every place Cookiebot is running.

A script in the page header may be only one part of the installation. Cookiebot can also come from a plugin, a GTM tag, a regional template, or a cached version of a page. As you work through the site, note which scripts, tags, and settings depend on it.

Find Cookiebot Across Your Website

The most likely places to contain installation code are:

• Page source and rendered HTML
• Global headers and footers
• Themes and custom templates
• CMS plugins
• Google Tag Manager containers
• Regional or language-specific pages
• Other domains and subdomains
• Server-rendered and CDN-cached HTML

Search for Cookiebot URLs and attributes such as data-cbid, data-blockingmode, and data-cookieconsent.

Custom code and GTM need another pass. Look there for Cookiebot JavaScript references, callbacks, events, variables, triggers, and tags. Browser network requests can expose an installation that is easy to miss in the source.

Don’t stop after the first match.

Cookiebot may have been installed through both a plugin and direct code, through GTM and the website header, or in more than one GTM container. Older regional templates are another place where old code can survive.

Record Domains, Blocking Rules, and Tag Dependencies

For each Cookiebot domain group, record:

• Its single CBID
• Domains and subdomains
• Shared settings
• Configured languages
• Any data-culture language overrides
• Regional rules
• Cross-domain consent settings

Also record whether Cookiebot uses automatic or manual blocking and whether GTM is involved.

Then trace the dependencies. Any Cookiebot-specific attributes, callbacks, events, variables, and triggers used by analytics, advertising, remarketing, embedded media, chat, heatmaps, or personalization tools need to be accounted for.

Server-set cookies are different. Check them—and server-side tracking—separately, because browser-side blocking cannot stop a cookie that has already been created in an HTTP response.

Before you change anything, make sure you have administrator access, a staging site, a recent backup, a rollback plan, and a saved GTM container version.

Step 2: Preserve Records and Map the Replacement

Deleting the old setup comes later. First decide what you may need if you have to audit the migration, troubleshoot a problem, or reconstruct the previous configuration.

Keep historical Cookiebot records separately from the new CookieScript implementation unless CookieScript supports a process for importing them.

Export the Information You May Need

Export what Cookiebot makes available. For anything it does not, keep a manual record.

At minimum, preserve:

• Consent logs, scan reports, and cookie inventories
• Available cookie-information exports
• Cookie Banner screenshots and wording
• Category definitions
• Vendor and service descriptions
• Language and regional settings
• GTM container versions
• Consent Mode defaults and updates

Some settings do not have an export option. In those cases, screenshots, configuration notes, and saved copies of GTM tags may be the best record you have.

How long should those records stay on file? That depends on your organisation's policies. The privacy or records manager should decide what needs to be retained and where it should be stored.

Map Cookiebot Settings to CookieScript

Now go through the existing setup one part at a time: domains and domain groups, languages, regions, categories, vendors, blocking rules, preference controls, GTM dependencies, and Consent Mode settings.

Do not rely on matching names alone. A Cookiebot category and a CookieScript category can sound similar while covering different technologies or purposes.

Domain groups need the same treatment. A Cookiebot domain group will not automatically become an equivalent CookieScript configuration.

Step 3: Configure and Install CookieScript in Staging

Set up CookieScript on the staging site using the information you collected from Cookiebot.

The old configuration tells you what needs to be recreated. It is not something you can copy mechanically into CookieScript.

Choose one CookieScript banner installation method:

• Add the CookieScript code directly to the website <head>
• Use the CookieScript GTM Community Template
• Use a CMS integration supported by CookieScript

A Custom HTML tag in GTM is not equivalent to the Community Template for Google Consent Mode.

If Consent Mode is managed through GTM, use the CookieScript Community Template. Direct CookieScript installations can use Consent Mode too, but in a manual setup the default consent state must be set before the Google tag or GTM loads.

For CookieScript’s direct gtag.js installation, follow the required code order in the website <head>.

Once CookieScript is loading, configure the cookie banner for the domains it covers. Set the design and wording, add the supported languages, link your privacy and cookie policies, and configure the controls for accepting, rejecting, or opening the settings.

Visitors also need a visible way to return later and change or withdraw their choice.

Next, run a CookieScript scan on the staging site.

Compare the scan with the services you know are installed instead of accepting every classification automatically. CookieScript uses five underlying categories:

• Strictly Necessary
• Functionality
• Performance
• Marketing (targeting in CookieScript attributes and events)
• Unclassified

Classify each technology according to what it actually does and when it runs. A similar category name in Cookiebot is not enough on its own.

Anything still marked Unclassified needs to be investigated before launch.

For regional setups: configure regional settings if the site changes consent behaviour by location. Geo-targeted CookieScript code must be placed directly in the website <head>, not through GTM. Test the Cookie Banner from inside and outside the regions you target.

For cross-domain consent: use it when a visitor’s choice needs to carry between related domains. Availability depends on the plan. Safari, Firefox, iOS, or browser privacy settings may prevent that choice from being shared.

Consent recording is another separate setting. Enable it when the selected plan supports it and the records are needed.

Before testing, verify that CookieScript loads from one source and that Cookiebot is no longer controlling consent. Duplicate installations can produce two cookie banners, repeated events, or conflicting consent signals.

Step 4: Rebuild Script Blocking, GTM, and Google Consent Mode

Open the staging site with GTM Preview and browser developer tools.

A visible Cookie Banner confirms that the front end loaded. It does not show whether a pixel fired on the first page load, and it does not tell you which consent state Google received.

Replace Cookiebot-Specific Controls

Return to the dependencies you recorded in Step 1. Each Cookiebot-specific control needs a replacement:

• A page script using data-cookieconsent needs a CookieScript rule. Depending on how it loads, use automatic blocking or manual blocking with data-cookiescript and data-cookiecategory.
• A GTM tag waiting for a Cookiebot event needs a CookieScript event or the CookieScript Consent State variable.
• A compatible Google tag can use Google Consent Mode instead of a Cookiebot-specific trigger.

Each script should have one consent-control path.

If CookieScript blocks a script on the page while GTM is also waiting for consent, the tag can remain blocked after acceptance or fire later than intended.

Some services deserve separate testing because a failure may not be obvious from the cookie banner alone:

• Analytics, advertising, and remarketing
• Video embeds, chat, heatmaps, and third-party forms
• Custom trackers or code outside the normal tag setup

Test the first visit, acceptance, rejection, and withdrawal for each one.

Then repeat those checks in a clean browser session. A saved preference can hide a problem on the initial load.

Server-side tracking belongs on a separate review list. Browser-side controls do not govern cookies set in the HTTP response.

Update GTM and Consent Mode

Start by removing the Cookiebot CMP tag, its variables and events, and any triggers built around them.

When Consent Mode is managed in GTM, add the CookieScript Community Template and fire it on Consent Initialization – All Pages. Ordinary analytics and advertising tags should not use that trigger.

The default and updated consent values also need checking:

• ad_storage
• analytics_storage
• ad_user_data
• ad_personalization

Some containers additionally use functionality_storage, personalization_storage, or security_storage.

Basic Consent Mode keeps Google tags blocked before consent.

Advanced Consent Mode behaves differently. It can load Google tags with denied defaults and send cookieless measurements.

After a visitor responds, the values need to match the choice made in the cookie banner.

Different tools answer different questions during testing:

• GTM Preview — firing order and consent values
• Tag Assistant — what Google receives
• Browser developer tools — requests, cookies, and storage entries

Use the debugger for the analytics or advertising platform as a final check.

Additional Consent Checks require some care. CookieScript’s Basic implementation may use them to keep a tag blocked, while Advanced Consent Mode normally relies on the tag’s built-in consent checks.

Managing the Rest of the Consent Setup

Before testing the migration as a whole, review the remaining Cookie Consent configuration that applies to the site.

Depending on your setup, this can include tracking pixels, third-party scripts, blocking rules, consent records, and connected integrations.

CookieScript is a Google-certified Consent Management Platform with Gold tier status. This is particularly relevant when the website uses Google advertising, analytics, or measurement products.

CookieScript CMP Features

Feature availability depends on the CookieScript plan and the options enabled for the cookie banner.

Use the requirements you documented during the audit as the checklist. CookieScript features include:

• customizable cookie banner;
• tools that support compliance efforts under global privacy regulations, including GDPR, CCPA, PIPEDA, PIPL, and others;
• automatic third-party script and cookie blocking;
• cookie scanning;
• visitor consent recording;
• Google Consent Mode v2 integration;
• Google Tag Manager integration;
• Global Privacy Control support;
• IAB TCF 2.3 integration;
• cross-domain and subdomain consent sharing;
• integrations for Wix, Shopify, Webflow, and other website platforms;
• CookieScript API;
• cookie banner sharing;
• Cookie Policy generator;
• Privacy Policy Generator.

CookieScript also provides a 14-day free trial of its Plus plan without requiring a credit card.

Step 5: Test the Migration Before Launch

Test the full visitor journey. A cookie banner appearing correctly is only one part of that test.

Start with consent choices:

• First visit with no saved preference
• Accept all and reject all
• Select individual categories
• Reopen the settings and change the choice
• Withdraw consent
• Return with a saved preference
• Repeat the test in private browsing

Watch the site as those choices change. Scripts should follow the blocking or Consent Mode behaviour configured in Step 4.

If a visitor changes a preference, the related tag behaviour should change too. Forms, navigation, video, and other essential parts of the site should continue to work.

Then widen the test to the environments your visitors actually use:

• Desktop and mobile
• Chrome, Safari, Firefox, and Edge
• Every supported language
• Visitors inside and outside targeted regions
• Each domain and subdomain
• Cross-domain consent where configured

Use browser developer tools, GTM Preview, Tag Assistant, and the relevant analytics or advertising debugger during these tests.

Inspect cookies and local storage. Check network requests. Look for console errors.

Consent Mode timing matters as well. Defaults and updates need to appear at the correct stage for the setup you chose.

Also check for duplicate events and make sure rejected traffic is not being recorded as accepted traffic.

Any browser, regional, or cross-domain limitation you find should be documented. Base the launch decision on the full set of test results, not one successful browser session.

Step 6: Remove Cookiebot and Complete the Production Cutover

Remove Cookiebot only after the staging checks have passed.

For production, use a controlled cutover:

1. Back up the production site and save the current production GTM container version.
2. In the same deployment, activate the tested CookieScript setup and disable or remove the active Cookiebot CMP installation.
3. Remove Cookiebot GTM tags, including any Consent Initialization tag.
4. Remove direct scripts, the Cookie Declaration script where present, CMS plugins, theme or template code, Cookiebot attributes, event listeners, and old preference links.
5. Check language and regional templates, then clear the CMS, application, server, and CDN caches.
6. Run a production smoke test covering the cookie banner, blocking, consent updates, and key tags.

Once the caches have cleared, inspect the page source and network activity.

No Cookiebot script or request should remain. Check that no plugin or template is adding the code back.

For the first production sessions, focus on:

• Analytics and conversion activity
• Advertising tags and Consent Mode signals
• Duplicate events
• Regional cookie banner behaviour
• JavaScript errors

Removing Cookiebot from the website does not cancel the subscription. Billing continues until the billed domain is removed or the account subscription is cancelled.

Keep the account available while you still need its records or the option to roll back. Once production testing is complete and the records you need have been preserved, you can make the final account changes.

Deleting a domain group permanently removes its consent logs, statistics, scan reports, styling, and configuration. Deleting the account also irretrievably removes account content and records.

Common Cookiebot-to-CookieScript Migration Problems

Most migration failures show up as a few recognisable symptoms. Old Cookiebot code may still be active, CookieScript may be installed twice, or GTM may be using the wrong consent setup.

Use the symptom to decide where to look.

1. Cookiebot still appears, or two cookie banners load. Old code is probably still being added somewhere. Look in CMS plugins, GTM tags, theme files, regional templates, cached HTML, and the CDN. Also make sure CookieScript is not installed in more than one place.
2. Tags fire too early or stay blocked after the visitor accepts. Start with Consent Initialization timing and the default consent state. Then check that the tag uses the right CookieScript category. Old Cookiebot variables or triggers may still be active. The tag may also be blocked through both GTM and CookieScript, or stopped by an extra consent check.
3. Analytics or advertising data looks wrong. Check that consent updates reach GTM and that triggers use the right state. Someone may also have changed the tag’s built-in consent checks. Make sure the site shows the Basic or Advanced Consent Mode behaviour you expect. Then look for duplicate events or old Cookiebot rules.
4. The wrong cookie banner appears, or consent does not carry between domains. For regional issues, check that the latest geo-targeted code is in the website <head> and that geo-targeting is included in your plan. For cross-domain consent, check plan access, browser privacy settings, and known limits in Safari, Firefox, and iOS.

Conclusion

Do not delete the old setup as soon as CookieScript goes live.

Watch real traffic for a while. Pay attention to conversions, tag activity, consent updates, and regional behaviour. If something looks wrong, compare it with what you saw in staging.

Keep the Cookiebot records, migration notes, and rollback copy while they are still useful.

When the site has stayed stable long enough that you no longer need them, the migration is complete.

Frequently Asked Questions

Can Cookiebot settings be imported into CookieScript?

Plan to recreate the setup manually. CookieScript’s setup process centres on creating its own cookie banner, scanning the website, reviewing categories, and installing new code rather than importing a Cookiebot configuration.

Can Cookiebot consent records be transferred?

Cookiebot consent logs can be downloaded and kept as a historical archive. Exporting them does not add those records to CookieScript’s consent log. If consent recording is enabled on a supported plan, CookieScript can record new choices collected through its own cookie banner after the migration.

Will visitors need to give consent again?

Possibly. Cookiebot preferences should not be expected to transfer automatically. If you cannot show that the old choice still covers the same purposes, vendors, and processing, asking the visitor to choose again may be appropriate. A CMP change alone does not always make renewed consent necessary.

Can Cookiebot and CookieScript run at the same time?

Avoid having both platforms control consent in production. Each CMP can affect cookie blocking, GTM timing, and Consent Mode. If both are active, you may see two cookie banners, conflicting signals, or tags firing at the wrong time.

How can I confirm that Cookiebot has been fully removed?

Check the page source, GTM container, CMS plugins, themes, templates, regional pages, and cached HTML. Then inspect network activity. No Cookiebot script, CBID, attribute, event, or request should remain.

Will the migration affect Google Analytics or advertising?

It can. Analytics and advertising tags may depend on Cookiebot variables, events, blocking rules, triggers, or Consent Mode settings. Test those tags before launch. After the production cutover, monitor traffic, conversions, consent signals, and duplicate events.

How should Cookiebot domain groups be handled?

Record each group’s CBID, domains, languages, regional settings, and shared configuration. Domains in one Cookiebot domain group share a CBID and configuration. That structure still needs to be reviewed and recreated manually in CookieScript.

Can geo-targeted CookieScript code be installed through GTM?

No. Geo-targeted CookieScript code must be installed directly in the website <head>. After changing the geo-targeting settings, copy and publish the newly generated code. Global code without geo-targeting can still be installed through GTM.

Should the migration be tested in staging?

Yes. Before changing production, test cookie blocking, GTM, Consent Mode, supported languages, regional behaviour, analytics, and advertising. Use GTM Preview, Tag Assistant, and browser developer tools to check tag order, consent values, requests, cookies, and storage.