Cookies are set even though the visitor rejected consent

As a rule, once a visitor rejects consent, no tracking tool should run and no cookies should be set on that visitor's device. Sometimes, though, it turns out differently.

Most often the cause is a configuration error: a missing marking on a tool in the page code, the wrong order in which scripts load, or a plugin that changed that order. There are also two cases in which the CookieOfficer script lets cookies through on purpose.

Where to look for the cause and how to check it depends on how CookieOfficer is set up.

Start by checking the setup method and the blocking mode

Check two settings in the panel. You'll find both on the “Installation” page: the setup method in the “Deployment method” section, and the cookie blocking mode in the “Deployment settings” card.

The setup method decides whether the CookieOfficer script can stop tracking tools. The cookie blocking mode decides exactly what it holds back: all detected tracking tools, or only those you mark yourself in the page code.

Combining the two settings gives three cases:

Also check the number you're starting from. In the CookieOfficer panel, go to the “Cookies” section. Above the list of detected items you'll see a sentence along the lines of “After consent is rejected, 7 trackers are still running”. You'll come back to this number after making your fixes.

The message refers to the latest scan of the website, so check its date in the “Scan history” tab. If you've changed anything on the website or in the configuration since then, run a new scan.

Setup through Google Tag Manager

When you choose this setup method, the CookieOfficer script loads from the container. Tools added directly in the page code may run earlier, so blocking can't cover them. Automatic blocking doesn't work with this method, even if you have it selected in the panel. So a number above zero in the message doesn't mean there's a fault.

Tags fired from the container. You hold them back in Google Tag Manager itself, through Consent Mode or through data layer events. This is described in the article on setting up through Google Tag Manager.

Tools added directly in the page code. Mark them yourself, using the data-co-cat attribute together with type="text/plain".

If automatic blocking matters to you, move your setup to code in the <head> section and choose automatic mode in the panel.

Code on the site and manual mode

In this mode, the CookieOfficer script holds back only the tools that you mark with the right attribute in the page code. A tool without such a marking will run before the visitor makes a decision. So look for the cause in the markings.

The tool hasn't been marked

How to check. Compare the list of tools detected on the “Cookies” page with what you've marked in the page code.

Solution. Mark the missing tools with the data-co-cat attribute together with type="text/plain".

The marking is incomplete

How to check. Open the browser console on your website. There you'll find a list of tools that have the data-co-cat attribute but don't have type="text/plain".

Solution. The attribute alone isn't enough. Without changing type to text/plain, the browser will run the script before the CookieOfficer script can stop it, and the website will look protected.

Category entered in Polish or with a typo

The data-co-cat attribute accepts only four English keys. Any other value, that is, a Polish category name or a typo such as analitycs, blocks the tool permanently, even after the visitor has given consent. The panel won't flag this.

How to check. Open the browser console on your website. The CookieOfficer script will print the incorrect value there, together with a list of the correct keys.

Solution. Enter the key that matches the category in the panel:

Pay attention to the last row, because the key isn't a translation of the name in the panel.

Code on the site and automatic mode

In this mode, the CookieOfficer script holds back all detected tracking tools, but only if it runs before them. So the causes come down to the loading order.

The CookieOfficer script isn't first in the <head> section

How to check. Open the page's source code and, in the <head> section, find the script containing the address cookieofficer. Check whether any other scripts come before it, for example Google Tag Manager or Google Analytics.

Solution. Move the installation code to the very start of the <head> section, before the other tracking tools.

A plugin that speeds up the website has changed how the script loads

The problem appears on WordPress-based websites that have a plugin installed to speed up loading. The most popular ones are WP Rocket, LiteSpeed Cache and Autoptimize.

Such plugins combine scripts into one file, move them to the end of the page, or delay loading them until the visitor's first interaction. They treat the CookieOfficer script like all the others, so it runs too late to stop anything.

How to check. In the page's source code, the CookieOfficer script is at the end of the document, is combined with other files, or has an attribute that delays loading.

Solution. Add cookieofficer to the plugin's exclusions, in all the fields it provides, and clear the cache. The details are in the article on excluding the code from WordPress cache plugins.

Two cases in which the CookieOfficer script doesn't block

The two cases below occur with every setup method and aren't a fault. The CookieOfficer script lets them through on purpose, so before you start looking for an error, check whether it's actually one of them.

Cookies with no assigned category

The CookieOfficer script doesn't block cookies that the website scan hasn't assigned to any category. The point isn't to stop a cookie that your website needs in order to work.

Solution. Go to the “Cookies” page, open the “Unclassified” filter and assign categories. From then on, those cookies are included in blocking.

Tools from your own domain

The CookieOfficer script never blocks scripts that come from your domain and its subdomains. This safeguard protects the cart, login and search from being stopped by accident.

Solution. If any of these scripts tracks the visitor, mark it yourself with the data-co-cat attribute together with type="text/plain".

Check whether it helped

Wait a few minutes, because configuration changes reach browsers with a delay. Then run the scan again.

The message above the list of items on the “Cookies” page should disappear. If the number has only gone down, go back to the section describing your setup method and check the other causes.