On this page
Cookie banner problems are frustrating out of proportion to their difficulty, because the symptom rarely points at the cause. A banner that appears twice and a banner that never appears can come from the same misconfiguration. This is a diagnostic list, ordered roughly by how often each one turns out to be the answer.
Work top to bottom. Most sites stop at three or four.
1. You are testing with a consent decision already stored
By far the most common. You accepted cookies on your own site last week, the decision was stored, and now the banner correctly declines to show itself.
Check: open the site in a private window, or clear site data from DevTools → Application → Storage → Clear site data.
Every other test in this article assumes a clean state. Getting this wrong sends people chasing bugs that do not exist.
2. The script is in the wrong Webflow code field
Webflow has a head field and a footer field in Project settings → Custom code, and page-level equivalents under each page's settings. A consent script placed in the footer initialises after the page has rendered, which produces a visible flash — or, if other scripts have already fired, no protection at all.
Check: consent code belongs in head. Tracking code, if you are gating it by rewriting script tags, also belongs in head so the consent layer can find it.
3. You published to staging and tested there
A .webflow.io subdomain is not your site. It carries Webflow's own analytics, and cookies set on it belong to a different origin than your custom domain.
Check: always verify on the domain real visitors use. A clean result on staging tells you very little.
4. Two consent tools are installed at once
Common on sites that changed vendors, or where an agency installed one and the client installed another. Two banners fight over the same cookie name, and the second one to load overwrites the first one's decision — so the banner reappears on every page.
Check: search your published page source for consent, and look through Project settings for leftover snippets. Remove the loser completely rather than commenting it out.
5. The template markup was edited
Consent templates rely on specific attributes, IDs and classes to bind behaviour to elements. Renaming a div, deleting a wrapper, or moving an element out of its parent silently breaks the binding. The banner still looks right in the Designer, and does nothing on the published site.
Check: if you have restyled the banner, confirm you added classes rather than replacing existing ones. This is the single most common cause of a banner that renders but whose buttons do nothing.
6. Scripts are not actually gated
Covered at length in why your tracking scripts fire before consent, but it belongs on this list because it is invisible. The banner works. The buttons work. The decision is stored. And Google Analytics loaded anyway, because nothing ever told it not to.
Check: incognito window, DevTools Network tab, filter for google-analytics.com, reload, do not touch the banner. Any request is a failure.
7. The consent duration expired
If visitors report the banner "keeps coming back", it may be working exactly as designed. Consent has to be renewed periodically, and a short duration means more frequent prompts.
Check: the duration setting — typically 1, 3, 6 or 12 months. Shorter is stricter and more annoying; longer reduces prompts while staying within normal practice. The duration setting is documented here.
8. Region rules are hiding it from you
If your banner is configured to appear only for EEA visitors and you are testing from outside the EEA, the correct behaviour is for nothing to appear.
Check: your region configuration, and where you are testing from. This one wastes a lot of time because the site looks broken and is not. See showing your banner only to EU visitors.
9. Something else on the page threw first
A JavaScript error earlier in the page can prevent later scripts from running at all, including the consent layer. The banner never initialises, and the console explains why to anyone who opens it.
Check: DevTools → Console, reload, read the first error rather than the last. Errors cascade, so the earliest one is usually the real cause.
A note on the license tab
One cause that does not fit the pattern above: some banner templates require an activated license to function, and an unactivated or mistyped key produces a banner that renders without behaviour. If you have worked through this list and everything looks correct, check the key for missing digits and stray whitespace — copying from an email frequently adds one.
The order that saves time
If you take nothing else from this list, take the sequence:
- Clear site data and retest — eliminates half of all reports
- Check the console for the first error — eliminates most of the rest
- Check the Network tab for ungated scripts — finds the problem people did not know they had
Three steps, under five minutes, before changing a single setting.
