Setting up CookieOfficer with code in the head section

Setting up the CookieOfficer script directly in your page code ensures full, automatic blocking of all cookies and trackers before they are loaded on the page. With this method you have 100% control over exactly where it is placed.

The script must be placed at the beginning of the <head> section. In most CMSs (WordPress, Webflow, etc.) the place where you can add our code works on the same principle. Below you'll find detailed instructions: where to get the code, where to put it, what shouldn't be changed in it, and how to verify that the setup works.

Where do I find the CookieOfficer code?

1. Select your project and go to the Installation page.
2. In the “Deployment method” section, select the “Code on the site” option.
3. In the “Paste the code at the top of <head>” card, find the “CookieOfficer script” block and click “Copy”. The code already contains your project ID.

The code looks like this:

<!-- CookieOfficer -->
<script async src="https://cdn.cookieofficer.com/s/co-XXXXXXXXXXXXXXXXXXXX.js" data-co-id="co-XXXXXXXXXXXXXXXXXXXX"></script>

Where should I place the CookieOfficer code?

The place and the order in which you add the CookieOfficer code matter. It depends on whether you use the Google Consent Mode integration.

Without the Google Consent Mode integration. Place our script first in the <head> section, before Google Tag Manager, Google Analytics, chat and other tracking tools.

The order in which to place the scripts:

1. CookieOfficer code
2. Other tools

With the Google Consent Mode integration turned on. The default consent block “Google Consent Mode: default consent” should come first in the <head> section; place our script right after it.

The order in which to place the scripts:

1. Google Consent Mode: default consent code
2. CookieOfficer code
3. Other tools

What shouldn't I change in the code?

1. Don't remove the async attribute and don't replace it with defer. It's mandatory. Without it, any failure would stop your page from loading.
2. Don't remove the data-co-id attribute. The ID must be identical to the one in the script address. If they differ, the banner won't run at all, and a message about a mismatched installation code will appear in the browser console. This protects against showing someone else's banner and someone else's cookie declaration.
3. Don't change the script address. It contains the project ID, which we use to recognise which configuration to send.

How do I add the code under a restrictive CSP?

If your site uses a Content Security Policy with a nonce attribute or the strict-dynamic directive, add your own nonce to our script tag. We'll pass it on to all the elements we add to the page: unblocked scripts, provider libraries and banner styles.

How do I check the setup?

On the Installation page, run the test. If the setup succeeds, you'll see the message “The CookieOfficer banner is running on” followed by the domain name. Otherwise the panel will ask you to check that the code is in the <head> section and to refresh the page.

The test only confirms that the banner is running on the domain. You can verify cookie blocking with a scan of your site: when it finishes, go to the Cookies page and check that there is no message above the list about trackers running after the visitor has rejected consent.

Common mistakes to avoid

1. Don't let site optimisation plugins affect our script. WP Rocket, LiteSpeed Cache or Autoptimize can delay its execution, which will affect automatic cookie blocking. If you use such plugins, add scripts containing cookieofficer to the exclusions.
2. Don't leave other scripts before our code. In WordPress this applies to scripts written directly in the header.php file, before wp_head(). Move them below wp_head() or mark them with the data-co-cat attribute.
3. Don't set up the banner with two methods at the same time. The second copy of the code will switch itself off, but you'll be left with two places to update.
4. Don't copy the code from another project. The banner won't run, and the only information about the cause will be in the browser console.
5. Don't add the code to a site without an SSL certificate. The browser will block the script loaded from our address.