Cookiebot CMP doesn't actually block cookies, instead it prevents HTML elements from loading that can be the source of tracking.
These elements for the most part are scripts, iframes, or images.
The auto blocking feature works by comparing elements about to be injected into the DOM with a checklist containing the elements that must be blocked prior consent.
When the auto-blocker finds an element that will result in tracking prior consent, it modifies the element in such a way that it can't load and adds an attribute that can be used later to load element if/when consent has been given
There are a lot of rules the auto blocker uses that may sometimes result un unexpected behavior. Understanding these rules may help you fix issues, should they arise.
Before a first scan
Before a domain is scanned the auto-blocker doesn't have any instructions yet. To still offer some level of protection, the auto-blocker has a list of "known trackers". The auto-blocker will use this list as a fallback of sorts to ensure that well known services don't load prior consent.
Cookiebot must load first
This point can't be emphasized enough. Any element that loads before the Cookiebot script can set cookies without consent, after all nothing has loaded that can prevent it from doing so.
It will also affect the order in which things naturally load, so you also risk "breaking" the website by injecting the Cookiebot with auto blocking enabled in a semi-random place.
For the same reason you must not add
async attributes to the Cookiebot script. The former will delay the loading of the Cookiebot script, and the latter allows the rest of the website to continue to load while it loads.
You should also avoid using plugins that optimize performance, they will often do this by changing the loading order of scripts, including the Cookiebot script.
Cookiebot must be loaded from consent.cookiebot.com
If you attempt to self-host the Cookiebot script, many security checks will fail and the script will not load. Furthermore, our developers continuously add new features, update and improve code, and fix bugs without announcing this.
Avoid combining the use of the
document.write method with auto-blocking
document.write method injects content directly into the DOM at the exact moment when the command is issued. Furthermore, if the DOM is fully loaded this output will completely overwrite the DOM.
Auto-blocking is designed to handle this, but you will likely see visual elements appear at the bottom of the page, rather than their intended placement.
Frameworks that rely heavily on this method (for example require.js) will likely not work well with auto-blocking .
Forcing the auto-blocker to allow elements to load
You can force the auto blocker to disregard an element by adding the
Be sure not to apply mark up that disables the element, since that will essentially permanently disable the element.
Examples of this mark up is
type="text/plain" instead of
data-cookieblock-src instead of
Furthermore, there are only 4 recognized values for the
- preferences (cat 2)
- statistics (cat 3)
- marketing (cat 4)
- ignore (cat 5)
If you get reference errors after applying the
data-cookieconsent="ignore" attribute you have likely caused the resource to load before another resources it makes a reference to has loaded.
As a rule of thumb, if you need to ignore more elements than the auto-blocker intends to block, or if you need to ignore more than 3 elements, you should consider switching to manually marking up elements instead of using the auto-blocking feature.
The auto-blocking feature can only work if it knows what it needs to block prior consent.
During a scan of your domain a checklist is compiled. The link to this file will look similar to this:
The file will include entries similar to this:
This information tells the auto blocker how to identify the elements that require consent, and which categories are required for the element to be enabled.
Whenever you make changes to your website that can affect which trackers are present you should initiate a new scan at your earliest convenience to ensure that the auto-blocker's instructions are up to date.
I this error persists for more than 24 hours it could indicate that our scanner is unable to scan the domain.
How bundles are handled
For a file to be allowed to load that requires consent in multiple categories, all categories must be consented to, even if that includes necessary cookies!
For example if i have a file: bundle.js that requires consent for necessary, statistical, and marketing cookies, then this file will only be allowed to load if a visitor accepts statistical and marketing cookies.
It is not advisable to use auto-blocking if more or less all your scripts are loaded in a single bundle. In such cases you could consider moving any tracking services to a Tag Manager and configure tags to require consent before loading.
How the auto-blocker handles resources from a CDN
If a resource loaded from a third-party domain sets cookies, then every resources from that domain will require the same consent.
For example; Domain A loads a script from Domain B. This script requires consent for statistical trackers.
If Domain A also fetches images from Domain B, then these images will be blocked until statistical tracking is consented to.
If an image is 1x1 pixels in size and the source has query parameters, it is assumed to be a pixel tracker. As a result they can be blocked prior consent.
In such cases certain patterns can be whitelisted though, if they single pixels are used for rendering purposes.
Elements that set unclassified trackers will not be blocked prior consent, since the tracker may actually be necessary. The unclassified tracker will be removed on each page load though.
Elements that exclusively set necessary cookies (cat 1), or a combination of necessary and unclassified cookies, will not be blocked prior consent.
There is no need to apply mark up to these elements. You should however ensure that there are no unclassified cookies.