The TermsFeed Free Cookie Consent banner most often stays hidden because your own browser already answered it. Cookie Consent shows the consent banner on every page load until the visitor answers, then hides it for 365 days by default. On a page where nobody answered, the consent banner is missing because Cookie Consent did not start or started late, or a blocker in the browser hides it. Cookie Consent does not release any tagged script when it does not start.

Check for a saved answer and for an ad blocker in the window that does not show the consent banner. That window holds your saved answer and your extensions. A new private window does not hold an answer once every other private window is closed, and by default it does not run extensions.

For the other causes, close every private window, then test them in order in a new one with DevTools open. Add "debug": true to the configuration object and publish the change first: in a window with no saved answer, a working installation prints Notice Banner shown afterbegin (or beforeend) in the Console tab.

Cookie Consent hides the consent banner for a browser that answered it, so your own test browser often shows nothing. Every answer, through the "I agree" (or "OK"), "I decline", or "Save my preferences" button, writes cookie_consent_user_accepted=true.

Open the Application tab, select your site under Cookies, and read cookie_consent_user_accepted. A value of true means your own answer hides the consent banner. The cookie cookie_consent_level alone does not hide the consent banner, because Cookie Consent writes it on the first page load, before any answer.

Test without the saved answer to see the consent banner again. Close every private window, open a new one, and open the page there. In your normal window, delete the 3 cookies whose names start with cookie_consent_ and reload. To change an answer as a visitor does, click the "Update cookies preferences" link, which opens the Preferences Center.

The consent banner needs 2 files from www.termsfeed.com, and a wrong address, an ad blocker, or a Content Security Policy (CSP) stops them. The address in your page loads a small loader, cookie-consent.js, which loads the script itself, cookie-consent-code.js.

Open the Network tab, type termsfeed in the filter, and reload. On a working page, the loader and the script both return status 200, beside a third row for the ping to /public-ping/. The Network tab, the Console tab, and the address bar tell you which case applies.

  • A wrong address. The loader returns an error status in the Network tab, such as 404 or 502. Copy the address exactly: https://www.termsfeed.com/public/cookie-consent/4.2.0/cookie-consent.js.
  • A page opened from your disk. The address bar starts with file://. The generator writes the address without https:, which a file:// page resolves to a file on your computer. Write https: in front of the address, or test on a web server.
  • An ad blocker. The request shows net::ERR_BLOCKED_BY_CLIENT. Test in a window without extensions, and read what happens for your visitors in Ad Blockers and CSP Hide the Cookie Banner.
  • A Content Security Policy. The console shows the address of the loader or the script with violates the following Content Security Policy directive. Add https://www.termsfeed.com to your policy with The minimum Content Security Policy for Cookie Consent.

Cause 3: The configuration object has a syntax error

A typing mistake in the configuration object of cookieconsent.run() stops the inline script, so run() never starts and no consent banner appears. The Console tab shows a red Uncaught SyntaxError, such as Unexpected string or Unexpected identifier, and its link points to the line of the inline script.

The usual mistakes are a missing comma between 2 options and a missing quote or brace. Curly quotes (“ ”) that a word processor or a page builder put in place of straight quotes cause the same error.

An unknown option or an invalid value does not cause this error. Cookie Consent ignores an unknown key and uses the default for most invalid values. An invalid open_preferences_center_selector does not make any element open the Preferences Center. Cookie Consent uses English for an unsupported language. An unknown value of an option with a fixed list of values, such as palette, logs a yellow Invalid <option> warning in debug mode.

Go to the broken line from the error and correct it.

  1. Click the link next to the error to open the line in the Sources tab.
  2. Correct the punctuation in your page or template, or create the code again in the TermsFeed generator and paste it in plain text.
  3. Save and publish the change, then clear any page cache.
  4. Reload and confirm that the red error is gone.

Cause 4: The code is on one page only

The consent banner appears only on pages that carry the Cookie Consent block, so code pasted into one page leaves every other page without it. Site builders offer code slots per page and per site, and a theme file often covers one template only.

Open a page without the consent banner, view the source with Ctrl+U, and search for cookie-consent.js. No match, with no block on that page in your editor either, means the block is missing from that page. Move the block into the site-wide slot of your platform, before the closing </body> tag, with Install a Cookie Banner on Any Website.

Cause 5: A cache serves an old copy of the page

A page cache, a host cache, or a content delivery network (CDN) keeps serving the page as it was before you added the code. The source in your editor holds the block, but visitors receive the stored copy.

View the live source with Ctrl+U and search for cookie-consent.js. Then load the page again with ?nocache=1 at the end of the address. A block that shows up only in the second copy points to a cache. A cache that ignores query strings serves the stored copy both times, so a block missing from both copies does not rule out a cache.

Clear every cache between your server and the visitor, then check the page fresh.

  1. Clear the cache of your caching plugin and of your host.
  2. Purge the cache of your CDN, such as Cloudflare.
  3. Close every private window, then open the page in a new one.

Cause 6: A page speed plugin delays the scripts

A page speed plugin that delays JavaScript until the visitor moves the mouse, scrolls, touches the screen, or presses a key holds the consent banner back until that interaction. The block is in the page source, but Cookie Consent starts only after the delay ends.

Load the page and wait without moving the mouse, scrolling, touching the screen, or pressing a key. A consent banner that appears only after one of those interactions shows that a plugin delays Cookie Consent. Exclude the 2 Cookie Consent script tags from that delay with Common mistakes with Cookie Consent on WordPress.

Cause 7: Another script uses the name cookieconsent

Cookie Consent declares the global name cookieconsent, and a site script that declares it first stops Cookie Consent from running. A let, const, or class named cookieconsent in the global scope of the page has this effect.

The Console tab shows Uncaught SyntaxError: Identifier 'cookieconsent' has already been declared. Search your own scripts and theme files for the name. Rename the variable in your code, and reload.

Cause 8: The page loads 2 copies of Cookie Consent

2 copies of the Cookie Consent 4.2.0 block on one page show the consent banner of the first run() call, so the one you configured in a later block never appears. A theme or plugin that adds the block a second time, such as the Cookie Consent kit of TermsFeed AutoTerms or another WordPress plugin, causes this. A self-hosted copy of version 4.1.0 or older, added after 4.2.0, replaces the cookieconsent global instead, and the run() calls that follow it reach that old copy.

View the source with Ctrl+U and count the matches for cookie-consent.js. More than one match means 2 copies load. The Cookie Consent kit from TermsFeed AutoTerms WordPress plugin prints its copy with the id wpautoterms_js_cookie_consent-js. Choose which block to keep with 2 copies of Cookie Consent on one page.

A consent banner that shows as plain text at the top or the bottom of the page, with unstyled buttons, means a Content Security Policy blocked its styles. Cookie Consent adds its styles as one <style> element in <head>, and a policy without 'unsafe-inline' for styles blocks it unless the element carries a nonce.

The Console tab shows an inline style line with violates the following Content Security Policy directive. Cookie Consent copies the nonce from the script tag that loaded it onto its <style> element. Put your nonce on the loader script tag with Content Security Policy (CSP).

Collect the console lines, the Network requests, and the cookies from the window that shows the problem, with debug on, then ask for help with them. A page that does not print a Cookie Consent line at all, with "debug": true in the configuration, never ran run(). Gather the details TermsFeed needs with What to collect before asking for help with Cookie Consent.

A working installation shows the consent banner in a new private window and prints its debug lines in the Console tab. Run the check again after each fix.

  1. Add "debug": true to the configuration object, publish your change, clear any page cache, then close every private window, open a new one, and open DevTools with F12.
  2. Open the Network tab, type termsfeed in the filter, and load your page.
  3. Confirm that cookie-consent.js and cookie-consent-code.js both return status 200.
  4. Confirm that the consent banner shows with its buttons, such as "I agree" ("OK" in implied mode) and "Change my preferences".
  5. Open the Console tab and confirm the line Notice Banner shown afterbegin (or beforeend) and no red error that points to cookie-consent-code.js or to the inline script that calls run().