---
title: "Common mistakes"
description: "The installation mistakes that most often stop the banner from showing or let trackers run before consent, and how to fix each one."
url: "https://cookiebeam.com/docs/getting-started/common-mistakes"
lang: "en"
---

# Common mistakes

The installation mistakes that most often stop the banner from showing or let trackers run before consent, and how to fix each one.

Most problems after an installation come from a short list of causes. Check these before changing your banner configuration. To confirm a fix, run the [installation checks](https://cookiebeam.com/docs/getting-started/verify-installation) again.

## The banner does not appear

### The banner is not published, or the change is not

The site only receives published versions. A new banner has nothing to serve until its first publish, and edits in the dashboard stay drafts until you publish again.

**Fix:** select **Publish** and publish to production. Check **Deployment → Status** to see which version is live.

### The hostname is not on the banner

The loader only runs on hostnames listed under **Banner domains**. On any other hostname it stops and writes `[CookieBeam] Domain not authorized` to the console. The `www.` and bare versions of a domain are covered together, but subdomains and staging hostnames are not.

**Fix:** add the exact hostname under **Banner domains**. Scripts are rebuilt automatically when you add a domain.

### You already made a choice in this browser

A stored choice stops the banner from opening automatically, so a site can look broken when it is working.

**Fix:** test in a new private window, or run `CookieBeam.reset(true)` in the console and reload.

### A content security policy blocks the script

If your site sends a `Content-Security-Policy` header, it must allow scripts from `cdn.cookiebeam.com`.

**Fix:** look for a CSP error in the console, then add the blocked CookieBeam host to the policy.

### The banner is hidden by a regional rule

A regional rule can decide not to show the banner in some regions. That is intended behaviour, not a fault.

**Fix:** add `?cb_debug=1` to the page address to see which rule matched. See [Troubleshoot a missing banner](https://cookiebeam.com/docs/operations/troubleshoot-banner#check-regional-visibility).

## Trackers run before consent

### The loader is not first in the head

The banner can only hold back a script that loads after it. A tracker placed above the loader, or loaded by a tag manager that starts first, has already run.

**Fix:** place the loader near the start of `<head>`, above the Google Tag Manager snippet and every tracker. See [Install with a script tag](https://cookiebeam.com/docs/install/script-tag).

### The loader has `async` or `defer`

Both let the browser run other scripts first, which reopens the gap the loader is meant to close.

**Fix:** use a plain `<script>` tag with no `async` or `defer`.

### An optimisation plugin moves or delays the loader

Features such as "delay JavaScript", "defer JavaScript" and script combining change the order of scripts. Cloudflare Rocket Loader does the same.

**Fix:** exclude `cdn.cookiebeam.com` from these features. The [WordPress plugin](https://cookiebeam.com/docs/install/wordpress) does this for the most common optimisers.

### The enforcement mode is Observe

**Observe** records choices but does not block scripts automatically.

**Fix:** once your checks pass, switch to **Adaptive** or **Lockdown** under **Banner settings → Enforcement and data controls**, then publish. See [Script blocking](https://cookiebeam.com/docs/configure/blocking).

### A tracker is hardcoded in the page

The browser starts fetching a `<script src>` written into your HTML while it reads the page, before any JavaScript can intercept it. Automatic blocking covers tags added by JavaScript, such as a tag manager, a plugin or another script.

**Fix:** mark the script as inert with `type="text/plain"` and a `data-category` attribute, and use `data-src` instead of `src` for external files. See [Script blocking](https://cookiebeam.com/docs/configure/blocking).

### Google tags run without a consent default

With Google Tag Manager, a Custom HTML tag that only loads `loader-gtm.js` sends no Consent Mode default. Google tags then run with no consent state until the visitor chooses.

**Fix:** use the CookieBeam Consent Mode template from the gallery, which sets the default first. See [Install with Google Tag Manager](https://cookiebeam.com/docs/install/google-tag-manager).

### GTM tags have no consent settings

Consent Mode changes how Google tags behave. It does not stop non-Google tags, and a tag with no consent requirement fires on its trigger whatever the visitor chose.

**Fix:** give each advertising and analytics tag its consent settings in GTM, or fire it from the CookieBeam consent events. See [GTM data layer events](https://cookiebeam.com/docs/integrations/gtm-datalayer).

## Other problems

### Two installations on the same page

A loader in the theme plus the WordPress plugin, the Shopify app embed or a GTM tag loads CookieBeam twice.

**Fix:** keep one method and remove the others. Use one CookieBeam installation per page.

### The platform's own cookie banner is still on

Shopify, Wix and Squarespace have their own cookie banners. Visitors then see two prompts that can disagree.

**Fix:** turn off the platform banner. See [Shopify](https://cookiebeam.com/docs/install/shopify) and [Webflow, Wix and Squarespace](https://cookiebeam.com/docs/install/site-builders).

### The live site loads a staging environment

A loader URL that contains `/env/staging/` serves what you published to that environment, not to production.

**Fix:** on the live site, use the production loader from **Deployment → Install**, which uses the `default` path. See [Environments and publishing](https://cookiebeam.com/docs/operations/environments-and-publishing).

### Google Consent Mode is not turned on for the banner

When you use Google tags, the banner itself only sends Consent Mode signals if Google Consent Mode is enabled in its settings.

**Fix:** turn it on in the banner's **App Integrations** page under **Google Consent Mode**, then publish. See [Google Consent Mode](https://cookiebeam.com/docs/integrations/google-consent-mode).