Cookiebot + GTM4WP – How to setup?

Cookiebot has a feature called automatic cookie blocking. It scans the page as it loads and holds back every script it does not recognize as necessary until the visitor has agreed to the matching category. That is a useful default, and it is also the reason GTM4WP has a Cookiebot option: without it, Cookiebot holds back the plugin’s own script blocks along with everything else.

This page describes GTM4WP 2.0.0 and newer. Where the legacy 1.x versions of the plugin behaved differently, the older behavior is marked with a bold GTM4WP 1.x: lead-in.

What the option does

The option adds one attribute, data-cookieconsent="ignore", to every script block GTM4WP writes into your pages. This is the attribute Cookiebot documents for exempting a script from automatic blocking, and Cookiebot’s own guide asks you to put it on the Google Tag Manager snippet.

The attribute reaches every block, not only the container snippet: the data layer initialization, the consent mode default, the container loader itself and the blocks the individual tracking features add. That matters, because holding back the data layer while letting the container through would leave you with a container that runs against an empty data layer.

What the option does not do

It is worth being equally clear about the other side, because the name of the setting suggests more than it delivers.

• It does not install Cookiebot and it does not display a consent banner. You install Cookiebot yourself, either through their WordPress plugin, through a script in your theme, or through your Google Tag Manager container.
• It does not read the consent state and it pushes nothing into the data layer. Unlike the CookieYes bridge, there is no cookie_consent_update event here.
• It does not send any consent mode command. The default command is a separate option, and the update comes from Cookiebot.

In other words, the option keeps GTM4WP out of Cookiebot’s way. Everything else is set up between Cookiebot and your container.

Turning it on

Open the plugin settings, go to the Consent mode & consent tools section and the Cookiebot group, then enable Cookiebot auto blocking.

Only enable it if you actually run Cookiebot with automatic cookie blocking. On a site without Cookiebot the attribute is harmless but meaningless, and on a site where Cookiebot runs in manual mode it changes nothing, since nothing was being blocked automatically in the first place.

GTM4WP 1.x: the same option is on the Integration tab and behaves identically.

Which consent mode settings to combine it with

Cookiebot sends the consent mode update signals to Google by itself once the visitor submits a choice. What it does not do for you, when it is installed directly on your site, is set the default state. Cookiebot’s own documentation is explicit about this: the default has to be in place before the Google tags load, and putting it there is your job.

That is exactly what the plugin’s consent mode default does, so the usual combination on a Cookiebot site is:

• Cookiebot auto blocking: on.
• Google Consent Mode: on, with all seven signal checkboxes left off so that everything starts denied. See how to set up Google consent mode.

There is one case where you should leave the consent mode default off. If you deploy Cookiebot through your Google Tag Manager container using their tag template, and you enable consent mode inside that template, the template defines the default states itself. Sending a second default from the plugin then only creates ambiguity about which one wins.

Load order

Cookiebot asks for a specific order at the top of the page: the consent mode default first, then Google Tag Manager, then the Cookiebot script.

GTM4WP takes care of the first two. It prints the consent default immediately before the container code, in the same pass over the page head, so those two are always in the right order relative to each other. The third one is the one to check, since something other than GTM4WP loads Cookiebot.

View the source of a page and look at the order in which the three appear inside the head element. If Cookiebot comes first, there is a setting that helps: Load GTM container as early as possible, in the Advanced group of the Google Tag Manager container section. It moves the consent default and the container code near the top of the head, ahead of most other plugins. Read its description before you enable it, because it also affects custom HTML tags that rely on jQuery being ready.

Reading the consent state in Google Tag Manager

If you need the consent state inside your container for something beyond consent mode, Cookiebot exposes it directly and you do not need anything from GTM4WP to reach it.

Cookiebot dispatches events on the window object, the two most useful being CookiebotOnConsentReady, which fires once the state is known whether it was just submitted or restored from a previous visit, and CookiebotOnAccept. The state itself lives in window.Cookiebot.consent with one boolean per category:

window.Cookiebot.consent = {
  necessary: true,
  preferences: false,
  statistics: false,
  marketing: false
};

A Custom HTML tag that listens for CookiebotOnConsentReady and pushes those four values into the data layer gives you the same kind of signal the CookieYes bridge produces, and Cookiebot recommends replacing page load triggers with a custom event trigger of that sort.

Troubleshooting

The data layer is empty and no GTM4WP event arrives. This is the symptom the option exists for. Check the page source for data-cookieconsent="ignore" on the GTM4WP script blocks. If it is missing, the option is off or the page was served from a cache created before you saved the setting.

The attribute is there and the scripts still do not run. Automatic blocking is not the only thing that can hold a script back. A caching or optimization plugin that combines or defers scripts can move the plugin’s inline blocks out of the head, and any script that Cookiebot rewrote earlier stays rewritten in a cached page. Clear the page cache after changing either setting.

Google Tag Manager reports no consent default. The Cookiebot option does not send one. Enable the Google Consent Mode option as described above.

Everything works while you are logged in and nothing works for visitors. That is almost always a page cache. It is worth testing consent behavior in a private browser window on a page you have loaded at least twice.

Further reading

• Google Tag Manager and automatic cookie blocking, the Cookiebot guide the plugin option is built around
• Disable automatic cookie blocking for a specific script, which describes the attribute in general
• Implementing Google consent mode in Cookiebot