WordPress Cookies and Consent: Staying Privacy-Compliant

This guide explains what cookies and trackers your WordPress site really sets, how to find them, and how to put a consent mechanism in place that actually satisfies privacy law rather than just looking the part. It covers the plain-language basics of the three regimes most Noiz clients need to think about, the European Union's GDPR and ePrivacy rules, South Africa's POPIA, and California's CCPA/CPRA, and it explains the single most common and most expensive mistake site owners make: showing a consent banner while the tracking scripts keep running underneath it. Cookie consent is sometimes called a cookie notice, a cookie banner or a consent management platform (CMP); the advice here applies to all of them. It is written for Noiz clients who run their own WordPress site, and it deliberately describes what a consent tool must do rather than endorsing any single plugin.

Last reviewed: 27 July 2026, against WordPress 7.0.2 (latest stable). This guide is written for Noiz hosting and is kept current against WordPress. It complements, and does not replace, the official WordPress documentation and the legal texts linked below. It is general guidance, not legal advice; where compliance is business-critical, confirm your obligations with a qualified data-protection adviser.

Official Documentation Reference

• WordPress Privacy (WordPress Documentation): the built-in privacy features, including the Privacy Policy page tool and the personal-data export and erasure tools.
• WordPress Cookies (WordPress Developer Resources): exactly which cookies WordPress core sets for logged-in users and for commenters, and what each one is for.
• Regulation (EU) 2016/679 (GDPR, EUR-Lex): the primary text of the General Data Protection Regulation, including the definition of valid consent.
• Directive 2002/58/EC (ePrivacy Directive, EUR-Lex): the "cookie law" that actually requires prior consent before non-essential cookies are stored on a visitor's device.
• Information Regulator (South Africa): the body that supervises and enforces POPIA, with guidance notes and the Act itself.
• California Consumer Privacy Act (California Attorney General): the official overview of consumer rights and business duties under the CCPA as amended by the CPRA.

Prerequisites

• You can log in to your WordPress admin dashboard.
• A web browser with developer tools, which every modern browser has built in. You will use it to see what your own site stores on a visitor's device.
• A rough idea of who visits your site and where they are. The law that applies to you is driven by where your visitors are, not by where your server sits, so this matters more than it first appears.

Why This Matters, and Which Laws Apply to You

The first thing to understand is that these laws follow your visitors, not your hosting. A site hosted with Noiz in South Africa or Ireland that has visitors in the European Union is squarely within the reach of EU law; a site aimed at South Africans is within POPIA wherever it is hosted. Most small sites end up needing to satisfy more than one regime at once, simply because their audience is spread across borders. The good news is that the three regimes below overlap heavily, so a single well-built consent setup usually covers all of them.

The European Union: GDPR and the ePrivacy Directive

People talk about "GDPR consent" for cookies, but the requirement to ask before storing cookies actually comes from the older ePrivacy Directive, the so-called cookie law, which each EU country writes into its own national law. What the GDPR adds is the definition of what counts as real consent: it must be freely given, specific, informed and unambiguous, and given by a clear affirmative action. In plain terms, a pre-ticked box is not consent, "by continuing to browse you accept" is not consent, and silence is not consent. The visitor has to actively choose.

The rule that catches people out is the timing. Non-essential cookies and scripts must not run before the visitor has agreed. A banner that appears while your analytics and advertising scripts have already loaded and already dropped their cookies does not make you compliant; it simply documents the violation. This is not a theoretical risk. In September 2025 the French regulator issued a fine of 150 million euro against a site that placed advertising cookies the moment visitors arrived, before they had touched the banner, and pre-consent loading is among the most frequently cited findings in enforcement actions across Europe. GDPR penalties reach up to 20 million euro, or four per cent of a company's worldwide annual turnover, whichever is higher.

South Africa: POPIA

For Noiz clients based in South Africa this is usually the most directly relevant law. The Protection of Personal Information Act took full effect on 1 July 2021 and is enforced by the Information Regulator. POPIA does not mention cookies by name, but it defines personal information very broadly, and that definition captures online identifiers such as IP addresses and the profiles that tracking cookies build. Where a cookie processes personal information and is not strictly necessary to provide the service the visitor asked for, POPIA's conditions for lawful processing apply, which in practice means telling visitors what you collect and why, and obtaining consent for non-essential tracking. Non-compliance can attract an administrative fine of up to R10 million, and certain offences carry the possibility of imprisonment, so this is not a box-ticking nicety.

California: CCPA and CPRA

California works on a different model, and it is worth understanding the difference. Instead of asking visitors to opt in before tracking, the CCPA (as strengthened by the CPRA) gives consumers the right to opt out of the "sale" or "sharing" of their personal information, where "sharing" includes handing data to advertising networks for cross-context behavioural advertising. In practice a site that reaches Californians and meets the CCPA thresholds needs a clear "Do Not Sell or Share My Personal Information" link, and it must honour the Global Privacy Control (GPC), a signal some browsers send automatically to say the visitor has opted out. As of 2026, regulators expect the site to confirm to the visitor that an opt-out has actually taken effect. Penalties are charged per violation and mount quickly across many visitors.

Because the EU and POPIA both lean towards opt-in and California leans towards opt-out, a good consent tool lets you switch behaviour based on where the visitor is. You do not have to reconcile the regimes by hand.

What Cookies and Trackers Actually Are

A cookie is a small file a website asks the browser to store, so the site can recognise the same browser on a later visit. Not all cookies are equal in the eyes of the law, and the whole of consent hinges on one distinction.

• Strictly necessary cookies are the ones a site genuinely cannot work without: keeping you logged in, remembering the contents of a shopping basket, holding a security token, balancing traffic across servers. These do not require consent, because the visitor has effectively asked for them by using the feature.
• Non-essential cookies are everything else: analytics that count visitors, advertising and remarketing pixels, embedded video and social widgets, personalisation, A/B testing. These do require prior consent under the EU and POPIA regimes.

A second distinction matters just as much. First-party cookies are set by your own domain. Third-party cookies and scripts are pulled in from someone else's domain, and they are where most of the risk lives, because they hand data to a company you do not control. Crucially, a "cookie" is really shorthand for any tracking technology: modern trackers also use browser storage, tracking pixels and device fingerprinting, and the law treats those the same way. A tool that only looks for classic cookies will miss half the picture.

What WordPress Itself Sets

It helps to know that WordPress core is not the source of your compliance problem. Left to itself, a plain WordPress install sets only a small, well-behaved set of cookies, and they are functional rather than tracking.

• For logged-in users, WordPress sets authentication cookies (their names begin wordpress_ and wordpress_logged_in_) plus a wp-settings- cookie that remembers admin-screen preferences. The authentication cookies are strictly necessary; nobody could log in without them.
• For commenters, WordPress can set three cookies (their names begin comment_author_) so a returning visitor does not have to retype their name, email and website. These are a convenience, not a necessity.

The comment cookies are worth a closer look, because WordPress already handles them correctly for you. Since WordPress 4.9.6 the comment form can show an opt-in checkbox, "Save my name, email, and website in this browser for the next time I comment", and the cookies are only set if the visitor ticks it and posts a comment. This is a small, built-in piece of GDPR-friendly design. Make sure it is switched on under Settings > Discussion, where the option is labelled Show comments cookies opt-in checkbox.

So if WordPress core is well-behaved, where do the tracking cookies come from? Almost always from things you or a plugin added: analytics, marketing and advertising plugins, embedded media, social buttons, chat widgets, and fonts or scripts loaded from other companies' servers. Those are what you need to find and control.

Finding Out What Your Site Really Sets

You cannot get consent right until you know what you are asking consent for, and this is the step most people skip. Do not rely on memory or on the plugin list alone, because a single marketing or page-builder plugin can quietly load several third-party trackers. Instead, look at what actually reaches the browser.

Inspect Your Own Site in the Browser

Open your site in a private or incognito window, so you are testing as a first-time visitor with no existing cookies, and open your browser's developer tools (F12 in most browsers). Two panels tell you almost everything:

• The Application (or Storage) panel lists Cookies and other local storage, grouped by the domain that set them. Anything grouped under a domain that is not yours is a third-party tracker.
• The Network panel shows every request the page makes as it loads. Look for requests going out to domains that are not yours, for example analytics endpoints, advertising networks, font providers, video hosts and social platforms. Each of those is a third party receiving data about your visitor, and often at least the visitor's IP address.

The revealing test is to load the page before interacting with any consent banner. If trackers appear in these panels the moment the page loads, they are firing before consent, which is precisely the problem this guide exists to fix.

The Usual Hiding Places

On a typical WordPress site, non-essential trackers usually arrive through one of these routes. Knowing the list makes the audit far quicker:

• Analytics and tag managers, which are the most common by far and set cookies as soon as they load.
• Advertising and remarketing pixels from ad networks and social platforms.
• Embedded media: a single embedded video or map can set several third-party cookies before the visitor even presses play.
• Social sharing and follow buttons that load code directly from the social network.
• Live chat, reviews and other widgets that load from a vendor's servers.
• Fonts and scripts loaded from another company's servers. This one is easy to miss and has real legal history behind it: a German court ruled in 2022 that loading fonts directly from a font provider's servers, which passes the visitor's IP address to that provider without consent, breached the GDPR. Self-hosting your fonts avoids the transfer entirely and is covered later in this guide.

The Consent Banner Trap

Here is the heart of the matter, and the point on which most WordPress sites quietly fail. Installing a plugin that displays a cookie banner is not, on its own, compliance. A great many banner setups do exactly one thing: they show a notice and record the click. Meanwhile the analytics, advertising and embed scripts have already loaded with the page and already set their cookies, regardless of what the visitor clicks. The banner becomes a piece of theatre that, if anything, proves you knew tracking was happening and let it run anyway.

Real consent has to change what the site does. Under the EU and POPIA regimes, "prior consent" means the non-essential scripts must be held back and only allowed to run after the visitor agrees. That single requirement, blocking before consent, is what separates a compliant setup from a decorative one, and it is the requirement most site owners do not realise they are missing.

Blocking Third-Party Scripts Before Consent

A consent mechanism that does the job properly works roughly like this, and it is worth understanding the shape of it even though a plugin will handle the mechanics.

• It categorises trackers. Cookies and scripts are grouped, typically into necessary, analytics/statistics, and marketing/advertising, so visitors can accept some categories and refuse others rather than facing an all-or-nothing choice.
• It blocks the non-essential categories by default. Until the visitor consents, scripts in those categories are prevented from loading and setting cookies. This is the part cheap banners skip.
• It offers a genuine choice. Accepting and rejecting must be equally easy. A prominent "Accept all" beside a buried or missing "Reject" is itself a compliance failure, and regulators have said so repeatedly.
• It records and stores the consent. You need to be able to show, later, what a visitor agreed to and when. Keeping that record on your own server rather than a third party's is the more privacy-respecting approach, and one worth preferring.
• It lets visitors change their mind. Withdrawing consent must be as easy as giving it, so the banner or a persistent link needs to reopen the preferences at any time.
• It can adapt to the visitor's region. The same tool can present an opt-in experience to EU and South African visitors and an opt-out "Do Not Sell or Share" experience to Californians, and honour the Global Privacy Control signal where required.

WordPress core does not include any of this: it has no built-in consent banner and no built-in script blocker, which is why this specific job needs a plugin. The category of plugin you want is usually described as a consent management platform or a cookie consent plugin. Several capable options exist, free and paid, so choose on the criteria below rather than on brand, and prefer one that stores consent records on your own site.

What to Look For in a Consent Plugin

• It actually blocks non-essential scripts before consent, rather than only displaying a notice. This is non-negotiable and is the first thing to verify, ideally by re-running the browser test above after you set it up.
• It can scan your site to discover the cookies and trackers you found in the audit, and keep that list current as you add plugins.
• It supports granular categories and an equally easy accept and reject.
• It logs consent in a way you can retrieve, and ideally stores that log on your own server.
• It can differentiate by region if your audience spans the opt-in and opt-out regimes.
• It is actively maintained, tested against current WordPress, and does not itself load from a third party in a way that reintroduces the very problem you are solving.

WordPress's Built-in Privacy Tools (No Plugin Needed)

Consent is only part of privacy compliance. WordPress core also gives you several genuinely useful privacy tools that need no plugin at all, and they are easy to overlook. They do not, by themselves, make you compliant, but they cover duties that these laws impose alongside cookie consent.

The Privacy Policy Page

Under Settings > Privacy, WordPress helps you create or nominate a privacy policy page and provides an editing helper that assembles starter text from WordPress core and from any installed plugins that supply it. Treat the generated text strictly as a starting point: it is drafted around GDPR expectations, it cannot know about third-party services you have added, and the wording and completeness of the final policy are your responsibility. A privacy policy is expected under all three regimes, and it should honestly describe the cookies and trackers you found in your audit.

Handling Data Requests: Export and Erase

Both the GDPR and POPIA give people the right to see the personal data you hold about them and to ask for it to be deleted. WordPress builds in tools for exactly this, under Tools > Export Personal Data and Tools > Erase Personal Data. Each works from a verified email request: the visitor's request is confirmed by email, you approve it, and WordPress then either compiles a downloadable file of the data it holds or removes it. Two limits are important to understand. First, these tools only reach data held inside WordPress and participating plugins, so anything held in a third-party service you use will need handling separately. Second, an erasure is permanent and is not undone in your backups, so restoring an old backup could bring deleted data back; honour any outstanding erasure again if you restore.

Reducing What You Have to Consent For

The least risky tracker is the one you never load. Before you spend effort perfecting a consent banner, it is worth shrinking the problem, and often you can remove trackers entirely without losing anything visitors value.

• Self-host your fonts. Instead of loading fonts from an external provider, which passes visitor IP addresses to that provider, serve the font files from your own site. This removes a genuine legal exposure (the German court ruling above) and usually loads faster too. Many themes and a small plugin can localise fonts for you.
• Reconsider analytics. If you only need visitor numbers, privacy-respecting, cookieless analytics options exist that avoid the whole consent question for that purpose. If you keep a full analytics suite, it must sit behind consent.
• Load embeds only on request. Replace auto-loading video, map and social embeds with a placeholder that only loads the third-party content, and its cookies, once the visitor clicks. This keeps those trackers from firing before consent and speeds up the page.
• Remove what you do not use. Marketing pixels left over from a campaign, an analytics tag you forgot, a social widget nobody clicks: each is a tracker you are liable for and gain nothing from. Delete the plugins and tags you no longer need.

Every tracker you remove is one fewer thing to disclose, one fewer thing to block before consent, and one fewer thing that can leak data. This trimming sits alongside the wider measures in the Noiz WordPress Security Checklist.

A Practical Compliance Checklist

Pulling the guide together, a reasonable order of work looks like this:

1. Audit. Use the incognito-plus-developer-tools method to list every cookie and third-party request your site makes on load.
2. Reduce. Remove trackers you do not need, self-host fonts, and switch embeds to click-to-load.
3. Classify. Sort what remains into strictly necessary and non-essential.
4. Block before consent. Put a consent tool in place that actually holds back the non-essential scripts until the visitor agrees, then re-run the audit to prove it works.
5. Offer a real choice. Make accepting and rejecting equally easy, allow per-category choices, and let visitors change their mind.
6. Record consent, preferably on your own server.
7. Publish an honest privacy policy using the built-in tool, describing the trackers you actually run.
8. Be ready for data requests using the built-in export and erase tools, and know where your third-party data lives.
9. Adapt by region if your audience spans opt-in and opt-out regimes, and honour Global Privacy Control where it applies.
10. Re-check periodically, because every new plugin can add a tracker.

Troubleshooting

• Symptom: your consent banner appears, but trackers still show up in developer tools before you click anything. The banner is display-only and is not blocking scripts. This is the core compliance failure. Move to a consent tool that blocks non-essential scripts by default, or enable its script-blocking feature, and re-test in an incognito window.
• Symptom: analytics stopped recording visitors after you added consent. That is expected, because the script now waits for consent; it will record visitors who accept. If numbers dropped sharply, that gap reflects how many visitors were previously tracked without consent.
• Symptom: you cannot see any cookies in developer tools but you know you use analytics. You may be testing with an ad-blocker or privacy browser active, or your session already granted consent. Test in a clean incognito window with extensions disabled.
• Symptom: an embedded video or map disappeared after you enabled blocking. The embed is being held back until consent, which is correct. Add a click-to-load placeholder so visitors can choose to load it, or ensure that embed's category is offered in the banner.
• Symptom: the comment form saves visitor details without asking. Turn on Show comments cookies opt-in checkbox under Settings > Discussion so those convenience cookies are only set when the visitor ticks the box.

If you are not sure what your site is loading, or you would like help auditing your cookies, self-hosting fonts, or setting up a consent tool that genuinely blocks trackers before consent, open a support ticket with the Noiz support team. Include your domain and a note of the main plugins and third-party services you use, and mention which countries most of your visitors come from so the advice fits the law that applies to you.