Ask visitors once across every subdomain of your site
Set cookie_domain to your parent domain, such as example.com, on every subdomain, and one answer covers www.example.com, shop.example.com, blog.example.com, and the bare domain. Without the option, TermsFeed Free Cookie Consent writes its 3 cookies for the exact page hostname only. A visitor who answers on www.example.com then sees the consent banner again on shop.example.com.
The setup takes 3 steps and about 15 minutes, plus the deploy on each subdomain.
What you need before sharing consent across subdomains
Every hostname must sit under one parent domain that you control, and you need access to the Cookie Consent snippet on each of them. www.example.com and shop.example.com share example.com. example.com and example.de share nothing, so they keep separate answers whatever you set.
Browsers refuse a cookie for a domain on the Public Suffix List, the list of domains under which unrelated owners register sites. A site at yourname.github.io therefore does not share cookies with othername.github.io, and cookie_domain set to github.io saves nothing.
Step 1: Set cookie_domain to the parent domain
Add "cookie_domain": "example.com" to the configuration object, with your own parent domain, no protocol, and no path. Cookie Consent writes the value into the domain= attribute of all 3 cookies as you give it, without checking it.
<script type="text/javascript" charset="UTF-8">
document.addEventListener('DOMContentLoaded', function () {
cookieconsent.run({
"notice_banner_type": "headline",
"consent_type": "express",
"language": "en",
"cookie_domain": "example.com",
"cookie_secure": true
});
});
</script>
A browser refuses a cookie for a domain the page hostname is not part of, so a typo such as exmaple.com saves nothing, and the consent banner shows on every page. Turn on cookie_secure only when every subdomain loads over HTTPS.
Step 2: Use the same cookie_domain on every subdomain
Put the identical cookie_domain value in the snippet of every subdomain and of the bare domain. Cookie Consent does not support a mix, such as cookie_domain on one subdomain and none on another. Each time Cookie Consent writes its cookies, it removes copies of the same cookies set for the current hostname or its parent domains, other than the copy cookie_domain names. That cleanup keeps one copy of each cookie, but it lets a single forgotten subdomain remove the shared cookies for all the others.
For example, a visitor answers on help.example.com, which has no cookie_domain. Cookie Consent there removes the shared example.com cookies and writes cookies for help.example.com only, so www.example.com and shop.example.com show the consent banner again.
Keep cookie_duration and cookie_secure the same on every subdomain too, because the last subdomain that writes the cookies sets their lifetime and their Secure flag for all of them. Fix a subdomain that asks again with Cookie Banner Reappears on Subdomains.
Step 3: Check that every subdomain shares one answer
Set aside about 10 minutes. Both subdomains need a cookie settings link, which reopens the Preferences Center to compare the switches. Add one with Add a Cookie Settings Link.
- Deploy the setup on every subdomain. Close every private window, open a new one, open Chrome DevTools, and load
www.example.com. The consent banner appears. - Click the "I agree" button, select the Application tab, open Cookies, select the site, and type
cookie_consentin the filter box. Confirm 1 cookie of each name, with.example.comin the Domain column. - Open
shop.example.comin the same private window, and confirm that the consent banner stays hidden. - Open the Preferences Center on
shop.example.comwith your cookie settings link. Select the tab of a category you use, such as "Tracking cookies", set its switch to Inactive, and click the "Save my preferences" button. Loadwww.example.comagain, open the Preferences Center, select the same tab, and confirm its switch reads Inactive there too.
Visitors who answered before you set cookie_domain
Visitors who answered before you set cookie_domain keep their old cookies for the hostname where they answered, and Cookie Consent goes on reading them there. The shared cookie appears the next time they answer, and that write removes the old copy on the hostname where it happens. While both copies exist on a hostname, the console there shows [Cookie Consent] cookie_consent_level is set more than once, probably by subdomains with different cookie_domain settings; use the same cookie_domain on every subdomain, with or without debug.
Expect such visitors to answer once more, on the first other subdomain they visit. Ask every visitor again at once with Consent Storage and Duration.
Leave cookie_domain empty on localhost and staging hostnames
Leave cookie_domain empty on localhost and on staging hostnames outside your domain, because a browser there refuses a cookie for example.com. An empty value gives cookies for the current hostname only, which works everywhere. Choose the value from the page hostname, so one snippet serves production and testing.
<script type="text/javascript" charset="UTF-8">
document.addEventListener('DOMContentLoaded', function () {
var host = window.location.hostname;
var onSiteDomain = host === 'example.com' || host.slice(-12) === '.example.com';
cookieconsent.run({
"notice_banner_type": "headline",
"consent_type": "express",
"language": "en",
"cookie_domain": onSiteDomain ? "example.com" : ""
});
});
</script>
Replace example.com with your domain, and 12 with the length of your domain plus 1 for the leading dot. On localhost and on IP addresses, Cookie Consent skips its search for copies on parent domains, so no cleanup runs against other hostnames during tests.