The Cookie Consent kit in TermsFeed AutoTerms hides the cookie banner from a browser that already answered, which is the kit working as designed. A script that never loads or never runs leaves a trace in the page source or in Chrome DevTools.

The kit loads TermsFeed Free Cookie Consent 4.2.0 from www.termsfeed.com in the <head> of every page of your WordPress website, and prints the scripts that start it in the footer. Keep Chrome DevTools open (F12) while you test. Compare what you find with the markup in Cookie Banner Code on WordPress Pages.

The Cookie Consent script shows the consent banner only to a browser with no saved answer, so your own answer in this browser hides it on later visits. Visitors who have not answered still see the consent banner, so nothing on your WordPress website needs a change.

Close every private window, then compare your normal window with a new private window, which then starts with no cookies. A consent banner in the private window and none in your normal window points to your own saved answer. Confirm it in the Application tab of the normal window, which then lists the cookie that marks the answer, cookie_consent_user_accepted with the value true, under Cookies for your WordPress website. With no such cookie, an ad blocker in the normal window hides the consent banner, either by blocking the script request or by hiding the consent banner element.

Run each later test in a new private window opened after you close the others, because private windows share their cookies while any of them is open. Open your saved choice from the "Update cookies preferences" link at the end of the page. Check the consent cookie and the other causes inside the script with Cookie Banner Not Appearing With Free Cookie Consent.

The plugin prints nothing for the Cookie Consent kit while the kit is off, which is its state after install. No consent banner appears, and no vendor script prints, blocked or unblocked. The kit turns off with the "Disable" button on the Compliance Kits screen, or with the Enabled checkbox on its Customization tab.

The Compliance Kits screen and the page source both show a kit that is off. Open TermsFeed > Compliance Kits and read the status of the Cookie Consent box, which says "Disabled". On the website, open the page source with Ctrl+U (Cmd+Option+U on a Mac) and search for cookie-consent.js, which does not find a match.

Turn the kit on, then load a fresh copy of the page. Check every setting of a first setup with Add a Cookie Banner to WordPress.

  1. Click the "Enable" button in the Cookie Consent box, which saves the setting with no "Save Changes" click and shows "Cookie Consent enabled." at the top of the screen.
  2. Clear the page cache.
  3. Close every private window, open a new one, and load the page.

Cause 3: The "Configuration Parameters" hold invalid JSON

The Cookie Consent script starts only from a valid Configuration Parameters JSON object, so with invalid JSON, the plugin prints the script and the script never starts. The consent banner stays hidden, the "Update cookies preferences" link disappears, and every vendor script stays blocked. The plugin refuses invalid JSON on every save in the WordPress admin, the Configuration Parameters tab included. Invalid text comes from a write outside the admin, such as wp option update or a database import.

The Customization tab warns about invalid JSON. Open it from "Configure" in the Cookie Consent box on TermsFeed > Compliance Kits. Look for the notice "The Configuration Parameters are not valid JSON, so changes made here are not applied. Please correct them on the Configuration Parameters tab." In the page source of the website, the script with the id termsfeed-autoterms-cookie-consent-script is present and does not hold a cookieconsent.run call.

Correct the JSON by hand on the Configuration Parameters tab and save it until the error clears. Check each key and its accepted values in Cookie Banner JSON Settings in WordPress.

  1. Open the Configuration Parameters tab and correct the JSON: double quotation marks around every key and every text value, a comma between entries, and a closing }.
  2. Click the "Save Changes" button, and correct the text again while the tab shows an error.
  3. Open the Customization tab and confirm that the notice is gone, then clear the page cache.

A faster fix rebuilds the JSON from the Customization tab, but the rebuild drops the keys you added by hand.

  1. Copy the keys you added by hand out of the Configuration Parameters field.
  2. Empty the field and click the "Save Changes" button. The plugin writes the JSON again from the Customization settings.
  3. Add the copied keys back into the field, click the "Save Changes" button, and clear the page cache.

Cause 4: A page speed plugin delays the Cookie Consent script

A page speed plugin that delays JavaScript until the visitor scrolls or clicks holds back the Cookie Consent kit, so the consent banner appears late or not at all. The kit needs 3 scripts to run in order. The Cookie Consent script from www.termsfeed.com runs first. The AutoTerms plugin then prints the Callbacks script, when the Callbacks are an object, and the run script at the bottom of the page. WP Rocket "Delay JavaScript execution" and the LiteSpeed Cache "Delayed" option hold scripts back this way.

With all 3 scripts delayed, the consent banner waits for the first scroll or click. With only the Cookie Consent script delayed, the run script runs first, calls cookieconsent before it exists, stops with an error, and the page does not get the consent banner. Combining script files or deferring scripts causes neither problem.

Watch the requests in the Network tab. Type cookie-consent in the filter and reload without moving the mouse over the page. A working page lists 3 requests with status 200 at once: the loader cookie-consent.js, the code file cookie-consent-code.js, and a ping request. Requests that appear only after you move the mouse, scroll, or click confirm a delay, and Uncaught ReferenceError: cookieconsent is not defined in the Console tab shows that only the Cookie Consent script is delayed.

Exclude the Cookie Consent script and the 2 inline scripts from delay. Find where each page speed plugin keeps its exclusion list in WordPress Caching Plugins.

  1. Add www.termsfeed.com/public/cookie-consent/, wpautotermsCookieConsentCallbacks, and wpautotermsRunCookieConsent to the list of scripts your page speed plugin never delays.
  2. Clear the cache of the page speed plugin.
  3. Close every private window, open a new one, open DevTools on the Network tab filtered on cookie-consent, and load the page. The consent banner appears before you scroll.

Cause 5: A page cache serves a page from before the change

A page cache serves logged-out visitors the HTML stored before you turned the kit on or changed it, while you see the current page logged in. The Cookie Consent kit prints the same output for every visitor, so a cache stores it unchanged. A page stored before the change does not show the consent banner, or shows the old settings, until you clear the cache.

Load a copy of the page that no cache holds yet, in a browser with no saved answer. Close every private window, open a new one, and load the address with an unused query string such as ?nocache=1 added. A page cache that skips an address with a query string, or stores it separately, serves a fresh copy there. A cache or content delivery network (CDN) that ignores query strings serves the stored page at the address with ?nocache=1 too, so clear that cache instead. Then load the plain address in the same window, without answering the consent banner. A consent banner on the new address and none on the plain address means the cache serves an old page.

Purge every cache between your WordPress website and the visitor, then test the plain address. Find the clearing step for each kind of cache in WordPress Caching Plugins.

  1. Purge the caching plugin.
  2. Purge the server cache of your host and the cache of your CDN.
  3. Close every private window, open a new one, and load the plain address. Clear the cache again after every later change to the kit.

Cause 6: An ad blocker or a Content Security Policy blocks www.termsfeed.com

The consent banner needs the script from www.termsfeed.com, so an ad blocker, a DNS blocklist, or a Content Security Policy (CSP) that leaves out that host hides it. Keep 'unsafe-inline' in script-src and style-src of your CSP, because the kit prints inline scripts and styles.

The Network tab shows whether the script reaches the page. Use the normal window that does not show the consent banner for this check, because Chrome and Firefox turn extensions off in private windows unless you allow them. Filter the Network tab for termsfeed and reload the page. A cookie-consent.js request that fails or never appears points to this cause, and the Console tab tells a blocker apart from a policy. Read each trace in Ad Blockers and CSP Hide the Cookie Banner in Free Cookie Consent.

Let the script from www.termsfeed.com through the blocker or the policy. The kit prints its inline scripts with no nonce attribute, so copy the policy that keeps 'unsafe-inline' from The minimum Content Security Policy for Cookie Consent.

  1. Pause the ad blocker or the DNS blocklist for your WordPress website, and reload to confirm that the consent banner appears.
  2. Add https://www.termsfeed.com to script-src in your Content Security Policy.
  3. In the window that did not show the consent banner, open DevTools on the Network tab filtered on termsfeed, and reload the page. The cookie-consent.js request returns status 200.

A working kit shows the consent banner in a new private window, the Cookie Consent requests return status 200, and no red Console line names cookie-consent.js, cookieconsent, or termsfeed. Start from a browser that does not hold a saved answer.

  1. Clear the page cache, close every private window, open a new one, and open DevTools with F12.
  2. Open the Network tab, type cookie-consent in the filter, and load your page. The loader, the code file, and the ping request return status 200.
  3. Open the Console tab and confirm that no red line names cookie-consent.js, cookieconsent, or termsfeed.
  4. Look at the page. With the GDPR preference, the consent banner shows "I agree", "I decline", and "Change my preferences". The ePrivacy preference shows the "OK" and "Change my preferences" buttons. Under the GDPR preference, "notice_banner_reject_button_hide": true in the Configuration Parameters removes the "I decline" button.
  5. Scroll to the end of the page and confirm the "Update cookies preferences" link, which the kit adds while "Insert link for users to open Preferences Center" is on.

A consent banner that appears proves only that the script runs. Check that your vendor scripts wait for consent with WordPress Script Runs Before Consent.