Skip to content
ThemesIonic — home
Plugins

Cookie Consent on WordPress: Doing It Properly

A banner that appears while analytics already loaded is decoration, not consent. The plugin has to block scripts until permission is given, and record what was agreed.

4 min read intermediate

The test that separates real consent tools from decorative ones: open a private window, load the site, and check the Application tab in DevTools before clicking anything. If analytics and marketing cookies are already set, the banner is doing nothing.

That is prior blocking, and it is the feature to evaluate on. This article covers the technical implementation; whether your specific site needs consent, and in what form, is a legal question for someone qualified in your jurisdiction.

Capability Why
Prior blocking Scripts must not run before consent
Granular categories Necessary, analytics, marketing, preferences — consented separately
Equal refusal Rejecting must be as easy as accepting
Consent records Proof of what was agreed, when, and to which version
Withdrawal A way to change the decision later
Cookie policy A readable list of what is set and why
Consent mode signals Passing consent state to tag platforms that support it

Plugins that only show a banner and set an "accepted" cookie provide the first zero of those.

How prior blocking works in practice

A consent plugin blocks scripts in one of two ways:

  • By rewriting script tags so they do not execute until consent, then activating them.
  • By integrating with a tag manager, which holds tags until it receives a consent signal.

Either is fine. What matters is coverage: scripts added by plugins, by the theme, hard-coded in the header, and embedded in content all need handling. Embedded videos and maps are frequently missed — they set cookies as soon as the iframe loads, so a consent tool should replace them with a placeholder until permission is given.

Check the coverage yourself rather than trusting the feature list. Load the site in a private window, refuse everything, browse a few pages, and look at what is in storage.

Categories that make sense

  • Strictly necessary — session, cart, login, security. No consent needed, and they must keep working when everything else is refused.
  • Analytics — measurement. Consent required in most jurisdictions.
  • Marketing — advertising and remarketing pixels.
  • Preferences — remembered choices such as language.

Keep it to four at most. More categories look thorough and reduce the chance anyone reads them.

Design the banner so it does not damage the site

Do not push content down. A banner inserted into the document flow shifts the entire page after render, which is one of the biggest sources of layout shift — see how to fix cumulative layout shift. Use a fixed overlay:

.consent-banner {
    position: fixed;
    bottom: 0;
    left: 0;
    right: 0;
    z-index: 9999;
}

Keep it light. A consent script that loads before everything else, on every page, is in the critical path by definition. Check its weight — some are larger than the analytics they gate.

Make refusal equally easy. A prominent "Accept all" beside a buried "Manage preferences" is exactly the pattern regulators have been fining. Give both actions equal weight at the top level.

Do not block the page with a full-screen wall unless you have specific advice telling you to.

Two problems appear on cached sites:

  1. The banner shows to people who already consented, because the cached HTML contains the pre-consent state. Solutions vary: client-side rendering of the banner, or excluding the decision from the cached markup.
  2. Blocked scripts stay blocked after consent, because the cached page never contained them.

Most consent plugins handle this by doing the work in JavaScript on the client. If yours writes the decision into the HTML, it will fight your page cache — the general behaviour is described in how to clear the WordPress cache.

Keep the records

Store, per consent: a timestamp, the categories agreed, the banner version, and enough information to identify the record without keeping more personal data than necessary. Retention should be defined rather than infinite.

If your plugin does not record consent, you have a banner and no evidence — which is the position that becomes uncomfortable if anyone asks.

What a banner does not fix

  • Scripts loading from your own theme that nobody accounted for.
  • Data sent to third parties through forms, chat widgets and captchas — including reCAPTCHA, per how to add reCAPTCHA to a form.
  • An out-of-date or missing privacy policy.
  • Embedded content that sets cookies before the placeholder logic runs.
  • Analytics configured to collect more than you disclose.

A consent tool manages permission. It does not audit what your site actually does, and that audit is the part worth doing at least once — the wider hygiene list is in the WordPress security checklist.

Verify the setup

  1. Private window, load the site, check storage before clicking. Nothing non-essential should be present.
  2. Refuse everything, browse several pages, check again.
  3. Accept analytics only, and confirm marketing scripts stay blocked.
  4. Reload and confirm the decision persists.
  5. Withdraw consent and confirm the scripts stop.
  6. Check the cookie policy matches what actually loads.
  7. Repeat on mobile, where the banner is most likely to obstruct something.

Frequently asked

No. A banner is one visible part of a wider obligation that includes actually blocking non-essential scripts before consent, recording consent, and offering an equally easy way to refuse.
Preventing tracking scripts from running until the visitor consents. Without it, cookies are set before anyone clicks anything, and the banner is purely cosmetic.
It depends on the jurisdiction and how the analytics is configured. Some setups with no personal data and no cookies avoid the requirement, but that is a legal question rather than a technical one.

Related guides