A cookie policy for a WordPress site has to account for something most templates ignore: most of the cookies on a WordPress install don't come from anything you wrote. They come from whichever caching plugin speeds up your pages, whichever security plugin watches your login form, whichever page builder rendered your layout, and whichever video or share button you dropped into a post. A policy copied from a generic template describes none of that, because it has no idea what's actually installed on your site.
Here's how to write one that actually matches a real WordPress install: the cookies your plugin stack tends to set without anyone noticing, what embedded content adds on top, and where the finished policy needs to appear in your theme's footer.
Why a WordPress site's cookie footprint is different
A hand-coded site has one codebase and one team who knows exactly what scripts run on it. A WordPress site is a stack of independently maintained plugins, each free to enqueue its own scripts and cookies on its own update schedule, plus a theme layer: page builders like Elementor and Divi ship their own front-end assets, and many themes bundle demo importers, caching helpers, or analytics hooks by default.
The honest starting point for a WordPress cookie policy isn't your own code, it's your plugin list. Open the Plugins screen and go down it one by one, checking whether each plugin's documentation mentions cookies, local storage, or tracking. Most changelogs say so directly if you look; most site owners never look, and end up with a policy describing a site simpler than the one they're actually running.
Cookies set by caching, security, and page builder plugins
These three plugin categories are common on nearly every WordPress site and are also the ones most often left out of a cookie policy, because none of them look like "tracking" software:
- Caching plugins (WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache) generally set a cookie flagging whether a visitor is logged in or has items in a cart, so the cache serves the right variant instead of a stale one. Usually strictly necessary, but check your specific plugin, since some bundle an optional analytics or heatmap add-on that isn't necessary at all.
- Security plugins (Wordfence, Sucuri, iThemes Security) commonly set a short-lived cookie during login attempts or firewall checks, telling a real visitor from a bot. Also usually strictly necessary, but still needs naming in your policy rather than skipped for not looking like "tracking."
- Page builders (Elementor, Divi, Beaver Builder, WPBakery) mostly affect logged-in editors, but add-ons that include pop-ups, countdown timers, or their own form modules frequently add cookies for visitors, separate from the builder's editing tools.
Common WordPress Plugin Categories and Their Cookies
| Example Plugins | Typical Cookie Purpose | |
|---|---|---|
| Caching | WP Rocket, WP Super Cache | Cache variant, session state |
| Security | Wordfence, Sucuri, iThemes | Login and firewall verification |
| Page builders | Elementor, Divi, Beaver Builder | Editor session, add-on pop-ups |
| Forms and marketing | WPForms, OptinMonster | Form session, list tracking |
If you run WooCommerce, add its cart and session cookies to the list too: they're strictly necessary for checkout, but a policy that doesn't mention them at all reads as incomplete to anyone who checks their browser's storage tab against what you've published.
Cookies from embedded and third-party content
The second major source, separate from your plugin stack, is content embedded into posts and pages. This is where most WordPress cookie policies fall short, because the cookie comes from a script the embed itself loads, not from anything installed on the Plugins screen:
- YouTube embeds. A standard YouTube embed loads scripts from google.com and doubleclick.net that set cookies before playback starts, tied to ad personalization rather than the video itself. YouTube's privacy-enhanced domain reduces this but doesn't eliminate it, so it still needs disclosing.
- Social share buttons. A native "Like" or "Follow" button, as opposed to a plain link styled to look like one, typically pulls in a script that sets its own cookie. Jetpack's sharing module and plugins like AddToAny offer a lighter, cookie-free link-only mode, but it isn't always the default.
- Comments. WordPress's native comment form sets a cookie remembering a commenter's name and email for next time, strictly necessary for that convenience. Third-party comment systems and Jetpack's enhanced comments can add cookies of their own on top.
- Maps and other widgets. An embedded Google Map, booking widget, or review widget each loads its own third-party script, worth checking individually rather than folding into a generic analytics disclosure.
Where to link the cookie policy in your theme footer
A cookie policy that exists as an unlinked page does little good, and it's worth covering more than one spot.
Under Appearance, Menus, most themes (Astra, GeneratePress, OceanWP, and the default Twenty Twenty-Four theme included) offer a dedicated Footer Menu location separate from the main navigation. Adding your cookie policy page there is the most reliable option, since it survives a theme switch better than a hand-edited template. If your footer is widget-based instead, Appearance, Widgets usually has a footer widget area where a Navigation Menu or Custom HTML widget can hold the same link.
If your footer is built inside a page builder's own Theme Builder, in Elementor or Divi, add the link to that footer template directly, since a builder-generated footer often overrides the theme's default one. If you're running a separate cookie consent plugin (CookieYes, Complianz, Cookiebot), check whether it auto-injects a "Cookie Settings" link: that opens the consent preferences, and it is not a substitute for a plain, always-visible link to your actual cookie policy page.
Get a WordPress-ready cookie policy without starting from scratch
Writing an accurate cookie policy by hand means checking your plugins individually and tracking every embed, then keeping it current as your stack changes. Our Cookie Policy Generator builds a policy around the categories and third parties you actually tell it about, so the document you publish names your real plugin stack instead of a generic list, and you can update it in minutes the next time you install something new.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
