You want to see what a real, compliant cookie policy looks like, not another generic template. Below are 10 live, published cookie policies. Each gets dissected against six criteria that separate a real policy from a boilerplate one. The criteria come first. Then the examples, grouped by site type. Then the anti-patterns to avoid, then how to apply all of it to your own site.
What Makes a Good Cookie Policy? The 6 Things to Look For
A good cookie policy names every cookie in a real table, discloses every third party, and reads in plain language. It gives visitors working controls, matches the right legal model for its audience, and carries a visible last-updated date. Miss any of these and the policy reads as a legal formality, not a real disclosure. Each example below gets graded against these six things.
A Real Cookie Table, Not Vague Prose
The signal: the policy lists each cookie's name, purpose, and duration in a table. It does not settle for a vague paragraph about improving the visitor's experience. The European Commission's policy lists each cookie by name alongside its service, purpose, and retention period on its own row. A line like "analytics cookies help us understand usage" names no cookie, provider, or duration. That line discloses nothing a regulator or a curious visitor can verify.
Honest Third-Party Disclosure
The signal: every third-party tracker that actually fires on the site gets named. It never gets lumped into a generic "our partners" line. The European Commission's policy names 13 external providers by name, including YouTube, Google Maps, and Twitter. Staying silent on the Google Analytics or Meta Pixel scripts actually running is the single most common compliance gap.
Plain Language and a Layered Structure
The signal: a non-lawyer reads the first two sentences and understands what the site does with cookies. Legal depth stays available a click below for readers who want it. The BBC's policy hub opens in plain, friendly language, then layers into detail through linked questions.
Real User Control and Withdrawal
The signal: a working link lets a visitor reopen their consent choice at any time, not just at first visit. IKEA repeats its "cookie settings" link at the bottom of every page. It never buries that control once in the footer and stops there.
The Right Legal Scope for Your Audience
The signal: the policy applies GDPR-style opt-in consent where the audience is in the EU. It applies a CCPA-style "Do Not Sell or Share" opt-out where the audience is in California, and says so explicitly. USA Today runs both models in one document, addressed in separate labeled sections.
A Visible Last-Updated Date
The signal: a human-readable date sits near the top of the page, not buried in a CMS timestamp. The Guardian goes further and keeps a dated change history. A policy with no visible date gives a reader no way to judge whether it still reflects the site's current tracking.
Each example below is graded against these six things.
Enterprise and Government Cookie Policy Examples
Large organizations set the ceiling for how thorough a cookie policy can get. They run the most third-party scripts and answer to the most regulators at once.
European Commission
The European Commission's cookie policy discloses cookies in full tables organized by service. Each row names a cookie, its purpose, and its duration. It names 13 third-party providers individually, including YouTube, Google Maps, Twitter, and LinkedIn, instead of grouping them under a generic "partners" label. The policy states plainly that its analytics cookies gather data as an anonymous user. It adds that this data is not shared with any third parties, a specific, checkable claim, not a vague privacy assurance. Naming every provider and stating the anonymization scope explicitly is the transferable move. Readers and regulators can verify the claim instead of taking it on faith. One honest gap: the tables run to hundreds of rows across the Commission's many sub-sites. That is more disclosure than a typical business site needs to copy at that scale. This example demonstrates criteria 1 (table), 2 (third-party), and 6 (freshness, though weakly, since no update date is visible).
PayPal
PayPal's cookie statement sorts its cookies into four plain-language categories: Essential, Performance, Functionality, and Marketing. Each category gets a one-sentence description of what it does and why consent applies to categories 2 through 4. It includes a dedicated "Do Not Track" section explaining that PayPal does not currently respond to browser DNT signals. That is a specific, honest answer, not silence on the topic. The transferable principle: explain why each category needs consent, in plain words, instead of listing legal jargon. One gap worth noting: the policy is dated November 7, 2022, well past the freshness window a policy like this should hold. It also describes cookies in prose categories rather than a per-cookie table, so a visitor cannot see exactly which cookies run on the site today. This example demonstrates criterion 3 (plain-language categories) and criterion 5 (legal scope by region). It fails criteria 1 and 6.
IKEA
IKEA's combined privacy and cookie statement folds cookie disclosure into a drop-down, chapter-based document rather than a standalone page. It groups cookies into functional, preference, analytical, and marketing categories, each with a purpose and legal basis. It also names which IKEA entity is responsible for the data. The policy carries a clear date, updated 19 September 2025. It also states that a cookie settings link appears at the bottom of every page on the site. That gives visitors a constant path back to their preferences. Repeating the settings link on every page, not just once in the footer, is the transferable principle. User control should be reachable from wherever the visitor happens to be. The honest gap: cookie information lives inside a large combined privacy statement. A reader who wants only the cookie section has to open a chapter menu to find it. This example demonstrates criteria 3 (layered structure), 4 (control), and 5 (legal basis).
Publisher and Media Cookie Policy Examples
Ad-funded publishers run the widest range of third-party trackers of any site type. That makes them the clearest test case for honest third-party disclosure.
The Guardian
The Guardian's cookie policy is the freshness and jurisdiction standard in this set. It runs an 11-section jump-link table of contents. It also publishes a dated change history directly on the page. That history lists four separate dates: 1 July 2025, 5 March 2025, 9 February 2024, and 13 July 2023. It states a concrete duration ceiling: persistent cookies last no longer than 13 months. It names its ad partners individually, Ozone Project, Microsoft, Google Ad Manager, Criteo, and Teads, each with a direct opt-out link. It also handles three separate jurisdictions in three separate sections. A general privacy settings control covers most of the world. A California flow covers "Do Not Sell," and an Australia-specific disclosure covers device fingerprinting through its Ipsos Iris partnership. Publishing a dated change history, not just a single "last updated" line, is the transferable move. It lets a reader or a regulator see the policy is actively maintained. One gap: the individual cookie inventory lives behind the privacy settings tool. It is not on the page itself, so there is no per-cookie table to scan directly. This example demonstrates criterion 6 (freshness, the strongest in this set), criterion 2 (named partners), and criterion 5 (multi-jurisdiction handling).
USA Today
USA Today's cookie policy handles GDPR and CCPA in one standalone document instead of two separate pages. It runs a 7-section jump-link table of contents and states "Last Updated: March 4, 2026" at the top. It defines five categories, Functional, Performance, Social Media, Strictly Necessary, and Targeting, each with a plain description of what the category does. It routes EEA visitors to consent controls and California visitors to a "Do Not Sell My Info" link within the same policy. It closes with a mailing address for privacy contact: 175 Sully's Trail, Pittsford, NY 14534. Addressing two different legal regimes in clearly labeled sections of one document is the transferable principle. A reader never has to hunt for the right policy for their region. The gap: the concrete per-cookie list sits behind a preference-center tool rather than appearing on the page. This example demonstrates criterion 5 (dual-law handling), criterion 3 (structure), and criterion 6 (a fresh date).
BBC
The BBC's cookie hub leads with plain language for a mass, non-technical audience. It promises to help visitors understand and control what it remembers about them. Instead of one long document, it links out to short, question-framed pages. Topics include what visitors need to know about cookies and how the BBC uses them. Other pages cover what happens when third-party cookies are disabled and how the BBC uses cookies for commercial purposes outside the UK. A separate link to the full BBC Privacy and Cookies Policy sits at the bottom for readers who want the complete legal text. Leading with the plain-language questions a visitor actually has, then linking the legal detail one click below, is the transferable principle. It suits a policy serving a broad, non-expert audience. The gap: the top layer is so simplified that the actual cookie inventory sits a click or two deeper, not on the landing hub itself. This example demonstrates criterion 3 (plain-language and layered structure, the best in this set) and criterion 4 (control).
SaaS and Software Platform Cookie Policy Examples
SaaS platforms are the most realistic model for most site owners to copy. Their scale and structure are achievable, not aspirational. These examples are the policy document itself, not the on-site consent prompt; see cookie consent banner examples for how that separate piece looks.
Automattic (WordPress.com)
Automattic's cookie policy lists cookies in full tables broken out by category: Required, Analytics and Performance, and Advertising. A category-level summary table explains why each group exists. It names its advertising partners individually, Criteo, Google (through AdSense and DoubleClick), InMobi, SmartAdserver, and TripleLift, each linked to that partner's own privacy policy. It also discloses IAB TCF vendor participation directly, citing its transition to the IAB Europe Transparency and Consent Framework under a specific vendor ID. The transferable principle: structure cookies by category with a real table, then name every ad partner with a link to that partner's own policy. This is the most copyable structure in the set for a normal business site. A per-category table with named providers scales down cleanly to a site running only a handful of tools. The honest gap: the page carries no human-readable last-updated date. It only changes silently in the CMS. This example demonstrates criterion 1 (a clean per-category table) and criterion 2 (named partners).
Spotify
Spotify's cookie policy is effective as of 29 May 2023. It organizes cookies into four categories, Strictly Necessary, Performance, Functional, and Targeting or Advertising, inside a numbered, five-section jump-link document. It links out to a separate, dedicated vendor-list page rather than cramming every vendor into the main policy. Its opt-out guidance spans every surface a user might touch. That list starts with browser settings and iOS's "Allow Apps to Request to Track" prompt. It continues through Android's interest-based ad opt-out, an in-app "Tailored ads" toggle, and the AdChoices and DAA industry opt-out tools. Covering every surface, not just the browser, is the principle other multi-platform products should copy. The gap: the policy uses broad categories, not a per-cookie table, so a reader cannot see individual cookie names. Its effective date is also now three years old. This example demonstrates criterion 4 (control, the best in this set) and criterion 3 (structure).
Mailchimp
Mailchimp's cookie policy was updated August 1, 2023. It separates two audiences in one document: cookies on Mailchimp's own marketing site, and cookies the Mailchimp product deploys onto customers' own connected sites. That second category runs through a JavaScript snippet, a Meta Pixel, or Google remarketing tags. It states outright that it does not respond to Do Not Track signals, rather than staying silent on the question. It also links multiple named opt-outs, including Google's remarketing opt-out and the industry-wide aboutads.info and youronlinechoices.com tools. If your product deploys tracking code onto other people's sites, disclose that separately from your own marketing-site cookies, the way Mailchimp does. Its preference-center link routes to a TRUSTe consent tool. That shows how the actual cookie inventory can sit inside a third-party widget rather than on the page. The gap: there is no per-cookie table. The inventory lives behind that external preference tool, and the section on cookies served through the Service runs as a dense block of prose. This example demonstrates criterion 2 (third-party and deployed-cookie disclosure) and criterion 5 (DNT honesty).
Zoom
Zoom's cookie statement groups its cookies into a single labeled table by type: Strictly Necessary, Functional, Performance, Targeting, and Social Media. Each row states plainly what that category does and why. It discloses that performance cookies include session-recording and replay technology that captures mouse movements and clicks, a specific admission most policies omit. It honors the Global Privacy Control signal for California and Connecticut residents. It also states plainly that it does not respond to browser Do Not Track signals. Naming session-replay tracking outright, instead of hiding it under a generic "analytics" label, is the transferable principle. Readers see exactly what the performance category captures. One honest gap: the table groups cookies by category rather than naming each individual cookie with its own duration. The statement is also dated 30 June 2023, past the freshness window a policy like this should hold. This example demonstrates criterion 2 (specific tracker disclosure) and criterion 5 (Global Privacy Control and DNT honesty).
No genuinely small-business or solo-site cookie policy turned up as a live, verifiable example this session. For a site with a handful of pages and tools, the realistic target is the Automattic structure above. Name each cookie with its provider, group them into a short category table, and add a working preferences link. Scale it down to the tools that site actually runs, rather than copying the European Commission's exhaustive tables.
What a Weak Cookie Policy Looks Like (Patterns to Avoid)
A weak cookie policy shares one or more of six recognizable patterns, each traceable to a specific criterion above.
- Undisclosed third-party trackers: the policy stays silent on analytics or ad pixels that actually fire on the site, violating honest disclosure.
- An uncustomized generic template: the policy was pasted from a generator and never updated to reflect the site's real cookies, violating the real-table requirement.
- No visible last-updated date: the policy never states when it was last revised, even as the site's tracking changes underneath it, violating freshness.
- A wall of legal prose: the policy opens with dense legal language and no plain-language summary or table, violating clarity and structure.
- Cookie information buried inside a giant privacy policy: the cookie section has no clear heading or self-contained structure a reader can find, also violating clarity and structure.
- A lopsided consent control: the "Accept" button is highlighted while "Reject" is small or hidden, violating real user control, since the control exists on paper but not in practice.
How to Apply These Cookie Policy Principles to Your Own Site
Three moves separate a real cookie policy from a template. Scan your site first, name every third party with a duration, and keep a visible update date.
Start from your site's actual cookies, not a blank template. Scan the site to see which tools genuinely set cookies today. A policy built from a real scan produces a real table. One built from a generic template produces the vague prose pattern above.
Name every third party and give each cookie a purpose and a duration in a table. A vague "we use cookies to improve your experience" line discloses nothing a visitor or a regulator can verify. A row naming Google Analytics, its purpose, and its 13-month duration does.
Put a visible last-updated date on the page, and regenerate the policy whenever your tracking changes. A stale date, like the multi-year gaps in a few examples above, is a warning sign. It tells a careful reader the policy no longer reflects what the site actually runs.
If you would rather not build and maintain that table by hand, Consently scans your site for the cookies it actually runs. It generates a categorized, regulation-ready cookie policy you can publish in minutes, then keeps it updated as your cookies change. Try Consently free to see what your own site's cookie table looks like.
FAQs
What makes a good cookie policy?
A good cookie policy names every cookie in a real table and discloses every third party by name. It reads in plain language and gives visitors a working way to change their consent. It also matches the right legal model for its audience and carries a visible last-updated date.
How do I create a cookie policy for my website?
Three routes work. Generate one from a real scan of your site's cookies, write one from scratch, or adapt an existing template to your own tools. For the step-by-step version, see how to write a cookie policy, or start from our cookie policy template. Consently's cookie policy generator builds the table for you from an actual scan of your site.
Can I copy another website's cookie policy?
No. A cookie policy has to reflect your site's actual cookies, not another site's. Copying one is non-compliant, since the disclosures will not match what your site runs. It is also risky, since you would be publishing false claims about your own tracking. Scan your own site instead of copying someone else's table.
What should a cookie policy include?
A complete cookie policy explains what cookies are and lists the types your site uses. It names each cookie's purpose and duration, discloses every third party involved, and gives visitors a way to control or withdraw consent. It also lists contact information and shows a last-updated date. See what a cookie policy is for the full breakdown.
Where should I put my cookie policy?
Link it from your site's footer on every page, and link it again from inside your cookie consent banner itself. That way a visitor can reach it from wherever they land.
Do I need a separate cookie policy or can I use my privacy policy?
Either works, as long as the cookie section is clearly labeled and self-contained. IKEA and BBC both fold cookie disclosure into a larger privacy document. Each still gives cookies their own clearly marked section instead of scattering the detail through the page. See what a privacy policy is for how the two documents relate.
How often should a cookie policy be updated?
Update it whenever the cookies or trackers on your site change, plus a periodic review even if nothing has changed. The Guardian's dated change history, with four separate revision dates over two years, is the pattern to copy.
Do small websites need a cookie policy?
Yes, if the site sets any non-essential cookie, including analytics tools like Google Analytics or ad pixels. A site running only strictly necessary cookies, like a shopping cart or a login session, has a lighter legal bar. It should still document those cookies for transparency. See whether your site needs a cookie policy for the full breakdown by cookie type.
