Cookie Policy Template: Sections to Include and Wording

If someone told you your site needs a cookie policy, you've probably gone looking for a cookie policy template and found ten versions of the same document: dense paragraphs with an empty bracket where your actual list of cookies should sit. That bracket never fills itself in, and it happens to be the one part a regulator actually checks. This guide gives you a cookie policy template you can finish this afternoon, but it works in a different order than most.

First we'll settle what is a cookie policy, because it isn't your banner and it isn't quite your privacy policy. Then we'll scan your real site before writing a single line of cookie policy wording.

What a Cookie Policy Actually Is (And Isn't)

Three documents get mixed up constantly, and the confusion makes sense because they overlap. Think of a restaurant.

The banner is the host who asks if you'd like the table by the window before you sit down, a request made at the door. The cookie policy is the itemised receipt: exactly what you were charged for, line by line, cookie by cookie. The privacy policy is the restaurant's entire operating manual, covering everything from how your reservation is stored to the footage from the kitchen camera.

Where the analogy stretches a bit: a restaurant receipt doesn't need updating once it's printed. Your cookie policy does. It should reflect the cookies actually running on your site today, not the ones you set up when you built it two years ago.

Whether the cookie policy lives as its own page or sits inside the privacy policy depends on where your audience is. Sites facing the UK and EU usually give it a separate page, because ePrivacy rules focus specifically on cookies and similar storage technologies. Sites governed mainly by California's CCPA often don't, since CCPA folds cookie disclosure into the general privacy policy.

If you're curious what a compliant consent banner looks like on its own, that's covered in our cookie consent banner examples article. This guide assumes the banner already exists and focuses on the page it links to.

Do the scan before you write a word

Generic templates all say the same thing at this point: "insert your list of cookies here." That's the part they can't do for you, and the only part a regulator will read closely. Two short checks get you real data instead of a guess.

1. Run your homepage through cookiecheck.tools. Open cookiecheck.tools, paste your site's URL into the "Check a URL" tab, and start the scan. You should see a report listing every cookie your server set, its lifetime, and the third-party hosts loaded on the page. If the report comes back nearly empty, that usually means your cookies are being written by JavaScript after the page loads rather than by the server itself, which is common with chat widgets, embedded video, and some consent tools.
2. Switch to the browser tab for the ones a server fetch can't see. Click "Your browser," copy the short console snippet, and paste it into your browser's developer console while you're on your own site with cookies already set. You should get back a list of everything sitting in your cookies, localStorage and sessionStorage. If nothing appears, open developer tools first (F12 in most browsers) and paste into the console panel, not the address bar; browsers deliberately block scripts typed into the URL bar.

Write down every name, expiry and category you find from both checks. That's the raw material for the table you'll build in a few minutes. And if you also want to see the exact Set-Cookie header your server sends, byte for byte, httpcheck.tools shows the raw response headers behind the same request.

One honest limit worth knowing before you rely on any scanner, including this one: a single page fetch can't see everything a tag manager might load conditionally, or cookies set only after a visitor clicks something. Scan your two or three busiest pages, not just the homepage, and check back after any change to your plugins or embeds. Our about page explains exactly what the report checks and where its blind spots are.

How to build your cookie policy, section by section

With your list in hand, work through these sections in order. The wording below is a starting point you can adapt, not a finished legal document; if your business handles anything sensitive, have someone who knows your jurisdiction glance over the final version.

1. Name yourself and give a way to reach you. Sample: "This cookie policy explains how [Business Name] ('we', 'us') uses cookies and similar technologies on [yourdomain.com]. Questions about this policy can be sent to [email address]." This answers the first thing any reader, and any regulator, wants to know: who is actually behind this site.
2. Explain what a cookie is, in one paragraph. Sample: "Cookies are small text files placed on your device when you visit a website. They let a site remember information about your visit, such as whether you're logged in or what's in your shopping basket." One paragraph is the target here; if you're writing three, save the detail for the table below instead.
3. State why you use them, by category. Most sites cover four: strictly necessary (the site can't function properly without these), preferences or appearance (remembering settings like language), analytics or statistics (understanding how the site is used), and advertising and social (tracking across sites or embedded content). Your categories here should match what your cookiecheck.tools report actually flagged. If the report shows a category you haven't mentioned, such as session replay tools, add it before you publish.
4. Build the cookie table. This is the section a template can't write for you and the one most compliance checks focus on first. Use five columns: name, who sets it, purpose, how long it lasts, and category. A worked example, using cookies a typical WordPress site with Google Analytics and a YouTube embed would find:

   Name	Set by	Purpose	Expires	Category
   _ga	Google Analytics	Distinguishes one visitor from another for reporting	2 years	Analytics
   _ga_XXXXXXX	Google Analytics 4	Stores session state for GA4 reporting	2 years	Analytics
   wordpress_logged_in_[hash]	WordPress core	Keeps an editor or admin signed in	Until logout	Strictly necessary
   cookie_consent_status	Our consent banner	Remembers the visitor's cookie choice	6 months	Strictly necessary
   VISITOR_INFO1_LIVE	YouTube (embedded video)	Estimates bandwidth for video playback	Around 6 months	Advertising and social

   Google publishes its own reference for the _ga family's lifetimes, worth checking against your scan since vendors do occasionally change these values (Google's cookies reference). Every row here should trace back to something your scan actually found. A row that doesn't match a real cookie is worse than no row at all, because it tells a visitor, and a regulator, something untrue.
5. Name your third parties and where their data goes. Sample: "We use Google Analytics to understand how visitors use our site; Google may process this data outside the UK/EEA. We embed videos from YouTube, which may set its own cookies when a video is played." The UK's Information Commissioner's Office is specific on this point: third parties should be named clearly and specifically, not lumped together under a vague label like "our advertising partners" (ICO guidance on cookies).
6. Explain how to accept, refuse or change the choice. Sample: "You can change your cookie choices at any time using the link in our footer, or through your browser's cookie settings. Because some cookies are essential to the site working, refusing them may affect how pages display." If you want the underlying consent mechanics explained in more depth, including how the UK's 2026 exemptions for some analytics cookies actually work, that's covered in our GDPR cookie consent rules article rather than repeated here.
7. Mention other storage briefly. Sample: "Some features use browser storage (localStorage) or tracking pixels instead of cookies. This policy covers those in the same way it covers cookies." One line is enough; most sites don't need more than that.
8. State how long you keep data, and the legal basis. Sample: "We retain analytics data for 26 months, or until you withdraw consent, whichever comes first. Our legal basis for strictly necessary cookies is legitimate interest; for everything else, it's your consent." If you don't have a precise figure for a given cookie, stating the criteria used to decide it is also acceptable and is what Article 13 of the GDPR actually asks for.
9. Add rights and how to complain. Sample: "You have the right to access, correct or delete personal data we hold about you, and to complain to your data protection authority; in the UK, that's the ICO." Adjust the named authority to wherever your visitors actually are.
10. Add a last updated date, and mean it. Sample: "This cookie policy was last updated on [date]." Pick the real date you finished this edit and change it next time you touch the page. A static "last updated: 2022" is worse than no date at all, because it tells anyone reading closely that nobody has looked at this in years.

What your cookie list actually needs to include

Strip away the surrounding paragraphs and the list itself needs six things per cookie: its name, who sets it, its purpose, how long it lasts, its category, and, if you're tracking it, its consent status. Miss any one of these and the list stops being useful to a reader trying to understand what's actually happening on your site.

If you can't answer "who sets it" for one of your own cookies, that's usually a sign worth investigating. A plugin, chat widget, or leftover embed script may have added it without anyone deliberately choosing to. Remove what you don't need, then re-scan to confirm it's gone.

Regional rules in brief: UK, EU and California

The rules aren't identical everywhere your visitors might be, and a template written for one region can quietly mislead readers in another.

How often to update a cookie policy

There's no fixed legal interval in the UK or EU for reviewing a cookie policy, though the ICO recommends organisations set an "appropriate review period" for their own cookie practices rather than leaving it indefinitely. California is more specific: CCPA requires the privacy policy, which is where cookie disclosure sits for most US-facing sites, to be updated at least every 12 months.

In practice, the calendar matters less than what actually changed on your site. Update the policy whenever you add a plugin, widget or embed, swap analytics tools, install a new consent platform, move to a new domain or host, or when the underlying law itself changes. Then schedule a quarterly re-scan regardless, because cookies drift quietly. A site owner on the WordPress support forums put the problem plainly while trying to build their own list:

"Should it have added a table / list of cookies? How can I get the list to manually add to my page or can this be automated?"

That question comes up constantly because a deactivated plugin's leftover script, or a chat widget nobody remembers installing, changes what a site runs without anyone touching the policy page. A quarterly re-scan through cookiecheck.tools catches that kind of drift, flagging cookies with lifetimes stretched past what you documented or trackers firing before consent.

Mistakes that make a template useless

Most cookie policies fail for the same handful of reasons, and none of them are complicated to fix once you can see them.

• Copying another site's table wholesale. Their cookies aren't your cookies, and a mismatched list is arguably worse than a missing one.
• Leaving old cookies listed long after you've stopped setting them, a policy should reflect what's live now, not what was live at launch.
• Writing "we may use cookies for various purposes" with no names attached, which is exactly the vague, non-specific wording the ICO says doesn't count as clear and comprehensive information.
• Burying the policy link somewhere a visitor has to hunt for it, or leaving it off the site entirely.
• Promising a lifetime, like two years, for a cookie that most modern browsers already cap at a shorter duration in practice. If your documented number and the browser's actual behaviour don't match, the mismatch is easy for anyone checking to spot.

Before you publish, run one more pass through cookiecheck.tools to confirm the live page matches what's actually in your table. It takes less time than writing the table did.

Frequently Asked Questions

What is a cookie policy?

A cookie policy is the page on a website that explains which cookies and similar technologies it uses, who sets them, how long they last, and why. It's a disclosure document, not a request for permission. The consent banner asks; the cookie policy explains what was being asked about in the first place.

Is a cookie policy the same as a privacy policy?

No. A privacy policy covers everything a business does with personal data, from order forms to security cameras. A cookie policy narrows in specifically on cookies and browser storage. Some GDPR-facing sites keep the two separate; CCPA doesn't require a standalone cookie policy at all, so many California-facing sites fold cookie disclosure into their existing privacy policy instead.

What must a cookie policy list?

At minimum, each cookie's name, who sets it (your site or a third party), its purpose, how long it lasts, and which category it falls into, strictly necessary, preferences, analytics, or advertising. The ICO's guidance is specific here: third parties should be named clearly and specifically, never grouped under a vague label like "our partners."

How often should a cookie policy be updated?

There's no fixed legal interval in the UK or EU, though the ICO recommends an "appropriate review period." California's CCPA requires the privacy policy, which covers cookies there, to be updated at least every 12 months. In practice, update it whenever you add a plugin, embed or analytics tool, and re-scan the live site every quarter to catch anything that changed quietly.