The TermsFeed Free Cookie Consent banner returns on the next page when no consent cookie from an answer reaches that page. Cookie Consent stores each answer in 3 first-party cookies and hides the consent banner while cookie_consent_user_accepted holds true.

Add "debug": true to the configuration object and publish the change. Then close every private window and run the checks in a new one with DevTools open, except where a cause says otherwise. Answer the consent banner, open the Application tab, select your site under Cookies, and look for the 3 cookies whose names start with cookie_consent_.

Cause 1: Demo mode is on

Demo mode does not write cookies, and it shows the consent banner on every page load, by design. The demo option exists to try the consent banner on a live site without leaving an answer behind.

Search the configuration object for "demo": true or "demo": "true". After an answer, the Application tab shows none of the 3 cookies, and the Console tab does not show a Saved cookie with user consent level line. Remove the demo option, or set it to false, publish the change, clear any page cache, and reload.

Cause 2: cookie_secure is on for a page without HTTPS

The browser rejects a cookie with the Secure attribute on a page served over http://, so "cookie_secure": true on such a page does not store an answer. Cookie Consent adds Secure to all 3 cookies when the option is on. Browsers lift this rule for localhost, according to MDN, so the problem appears only on the real hostname.

The address bar shows http://, the configuration holds cookie_secure, and the Application tab does not show a Cookie Consent cookie after an answer. Serve the site over HTTPS, or remove cookie_secure from the configuration of any page that still loads over http://.

Cause 3: cookie_domain names a domain the page does not belong to

The browser ignores a cookie whose domain= attribute does not match the page hostname, so a wrong cookie_domain does not store an answer. Cookie Consent writes cookie_domain exactly as you set it, without checking it.

After a deploy that changes cookie_domain to a wrong value, new visitors see the consent banner on every page from the deploy on. Visitors who answered before the deploy keep their old cookies, which Cookie Consent still reads, so they do not see a change until those cookies expire. Answer the consent banner in the private window. No cookie_consent_ cookie appears in the Application tab while cookie_domain names a domain the page does not belong to.

Compare cookie_domain with the address bar. The page shop.example.com accepts "cookie_domain": "example.com" and rejects "example.org", "www.example.com", or a staging domain copied from another configuration. Set cookie_domain to the page hostname or to one of its parent domains, or remove the option, with Share Consent Across Subdomains.

Cause 4: The visitor moves between the bare and the www hostname

Without cookie_domain, the cookies belong to the exact hostname, so an answer on example.com does not count on www.example.com. A site that serves both hostnames, or links between them, asks the visitor again after each switch.

Watch the address bar while you click through the site. A hostname that changes between pages, such as from example.com to www.example.com, is the cause.

Send every visitor to one hostname with a permanent 301 redirect on your server. Where both hostnames stay, set "cookie_domain": "example.com" on every page of both, so one answer covers them.

Cause 5: The browser or an extension clears cookies

A browser set to delete cookies on exit, a privacy extension, or a cookie cleaner removes the consent cookies, so Cookie Consent sees a new visitor. Cookie Consent stores the answer only in cookies and uses no localStorage, so nothing else keeps it.

Run this check in a normal window, because a private window keeps its cookies only until every private window is closed. Delete the 3 cookie_consent_ cookies in the Application tab, reload, answer the consent banner, close the browser, and open the site again. Cookies missing from the Application tab after the restart point to a cleaner. The visitor controls cookie clearing in the browser, so no change on your site stops it. Test your own site in a browser profile without these extensions.

Cause 6: Safari keeps the cookies for 7 days

Safari caps cookies written by JavaScript at 7 days, so a Safari visitor sees the consent banner again about a week after answering. WebKit applies the cap to "persistent cookies created through document.cookie", according to its announcement of Intelligent Tracking Prevention (ITP) 2.1. Cookie Consent writes its 3 cookies from JavaScript, so its 365-day default does not apply in Safari.

Open the site in Safari, answer the consent banner, and read the expiry of cookie_consent_user_accepted in the Storage tab of Web Inspector. Expect an expiry no more than 7 days ahead. No Cookie Consent option lengthens that expiry, cookie_duration included, so no change to your configuration fixes this cause. Read the WebKit announcement in Intelligent Tracking Prevention 2.1.

Cookie Consent asks again when cookie_consent_user_accepted is true but cookie_consent_level is missing or unreadable. Your own cookie cleanup code, a server that rewrites cookie values, or an extension that deletes one cookie causes this. Cookie Consent then removes the cookie_consent_user_accepted cookie it wrote, so the consent banner keeps asking on every page until the visitor answers.

Debug mode prints The consent levels cookie is missing or invalid, the Notice Banner is shown again in the Console tab. Find the code that deletes or changes cookie_consent_level, and exclude the 3 Cookie Consent cookies from any cleanup.

Cookie Consent asks a visitor again 365 days after the last answer, by default, because the cookies expire then. The cookie_duration option sets that lifetime in whole days. Page loads of a visitor who answered leave the answer cookies as they are, so browsing does not extend the lifetime.

In a browser that still holds an earlier answer, read the Expires column of cookie_consent_user_accepted in the Application tab. A date of that answer plus your cookie_duration, 365 days by default, means the consent banner returns on that date by design. A consent banner that returns earlier, with cookie_consent_user_accepted missing from the Application tab, comes from the 7-day Safari cap, a hostname move outside cookie_domain, cleared cookies, or a lost cookie_consent_level cookie. Change the cookie_duration value for a shorter or longer lifetime.

No change to an option other than demo, and no change to the texts of a self-hosted copy, shows the consent banner again to visitors who answered. Read why in consent storage and duration.

A working installation keeps the 3 cookies after an answer and does not show the consent banner on the next page. Answer once, then follow the cookies to a second page. Publish your change and clear any page cache first.

  1. Close every private window, open a new one, open DevTools with F12, and load your page.
  2. Click the "I agree" button ("OK" in implied mode), then open the Application tab and select your site under Cookies.
  3. Confirm cookie_consent_user_accepted with the value true, and cookie_consent_level with an expiry 365 days ahead, or your cookie_duration (at most 7 days in Safari).
  4. Open a second page of the site and confirm that no consent banner appears.