WordPress cookie consent plugin: how to choose

A WordPress cookie consent plugin has one job that matters: keep Google Analytics, advertising pixels, embedded videos and other trackers from loading until the visitor clicks "Accept", and keep them off after "Reject". Many sites install one, see a banner appear and stop there, while the theme or another plugin keeps printing tracking code for everyone. This guide shows how to choose a plugin that really blocks scripts, how to set it up alongside caching and optimisation plugins, and how to prove it works with a first-visit scan. It is part of our guide to cookie consent and what the law requires.

Note

This guide is about the technical side of consent on WordPress. It is not legal advice; which categories need consent, and whether a US-style opt-out is enough, depends on where your visitors are.

Quick answer

Pick a plugin that blocks, not one that only shows a notice. Look for automatic script blocking by category, or tight integration with the tools you use.
It must offer "Reject all" on the first layer, equal to "Accept all", and a link to reopen the choice on every page.
It should support Google Consent Mode v2 and the WP Consent API, so Google tags and consent-aware plugins such as Site Kit and WooCommerce follow the choice.
Route every tracker through it. Remove tracking code pasted into the theme header or a "header scripts" plugin, and add it back through the consent plugin or Tag Manager.
Tell your caching and optimisation plugins about it: exclude its script from JavaScript delay, deferral and combining.
Prove it: run the free cookie scanner in a fresh browser. No tracker should load before the click.

A WordPress page is assembled from the theme and every active plugin, and any of them can print a <script> tag. A consent plugin sits in the middle of that and has to do four things:

Show the choice: a banner with accept, reject and settings, per category (statistics, marketing, preferences).
Block until consent: stop scripts, iframes and pixels in non-necessary categories from running before the visitor agrees.
Release on consent: load the blocked items once the visitor accepts, without a page reload if possible.
Remember and prove: store the choice in a strictly necessary cookie, log it, and let the visitor change it.

Showing the banner is the easy part; every plugin does it. The differences, and the audit findings, are in step 2.

There are three ways a plugin can hold a tracker back. Most good plugins combine them.

Method	How it works	Strength	Weak spot
Automatic blocking	Scans the page output and changes known tracker scripts to `type="text/plain"` with a category, then restores them after consent	Catches code the theme or other plugins print	Only knows trackers in its database; unknown scripts run
Built-in integrations	The plugin adds Google Analytics, Tag Manager or a pixel itself, only after consent	Clean and reliable	Only for the services it integrates
Consent signals	Passes the choice to Google Consent Mode, the WP Consent API or Tag Manager, and the tools respect it	Tools keep working in a limited, consent-aware mode	Only works if each tool reads the signal

Blocking by rewriting the script tag happens in PHP, before the page is sent, so it must run on every request. With a page cache, the blocked version is what gets cached, which is fine as long as the plugin releases scripts in the browser with JavaScript after consent. Plugins designed for WordPress do this; generic banner scripts pasted into a header box usually do not block anything at all.

What to look for when choosing

Popular options in the wordpress.org directory include Complianz, CookieYes, Cookiebot by Usercentrics, Real Cookie Banner and Cookie Notice & Compliance, and there are premium plugins such as Borlabs Cookie. Rather than recommend one, here is a checklist to hold any of them against:

Script blocking before consent, automatic or by integration, for the trackers you actually use. Test it; don't trust the feature list.
A first-layer "Reject all" button that can be styled the same as "Accept all". Some free tiers hide it by default.
Per-category consent (statistics, marketing, preferences) with no pre-ticked boxes.
Google Consent Mode v2 with all four signals, and a choice between basic and advanced mode. Our guide to Google Consent Mode v2 explains the difference.
WP Consent API support. The WP Consent API is a small plugin that gives WordPress a shared way to store and read consent. Site Kit by Google, WooCommerce and several analytics plugins read it, so one choice in the banner reaches them all.
Blocking iframes and embeds: YouTube, Vimeo, Google Maps and social posts, with a placeholder the visitor can click to load one.
Consent records you can export, and a cookie policy table generated from a scan, which our guide to writing a cookie policy explains how to check.
Geolocation, if you need it: opt-in for EU, UK and Swiss visitors, opt-out with Global Privacy Control for US visitors. Our guide to CCPA cookie banner requirements covers the US side.
Google certification, if you run AdSense or Ad Manager. Google requires publishers serving ads to visitors in the EEA, the UK and Switzerland to use a Google-certified consent management platform; check Google's list before choosing.
Weight. A banner loads on every page for every visitor. Compare its JavaScript and CSS with the WordPress plugin detector before and after installing.

Cloud-based platforms keep the scanner and consent log on the vendor's servers and usually charge by traffic or number of pages; plugins that run entirely inside WordPress store everything in your database. Both work; the cloud option adds a third-party script and a data processor to your privacy notice.

Setting it up step by step

Do this on a staging copy first if your site has a lot of tracking.

1. Take an inventory

Run a first-visit scan and list every cookie and tracker the site sets today, with the plugin or code that adds each one. The plugin detector shows which plugins load files on the page; the cookie scanner shows which trackers make requests.

2. Remove tracking code from the theme

Search for tracking code outside the consent plugin: the theme's header.php or functions.php, "Insert Headers and Footers"-style plugins, the theme customiser's "custom scripts" box, and page builder custom code settings. Every Google Analytics snippet, Meta Pixel, Hotjar or TikTok code found there runs regardless of the banner. Move each one into the consent plugin's integrations or into Tag Manager with consent triggers.

3. Configure categories

Map every service to a category. Only the login session, cart, security, load balancing and the consent cookie itself are strictly necessary. Analytics goes in statistics, pixels and remarketing in marketing, chat widgets and embeds wherever the plugin's scan puts them, after you check. Nothing optional should be in "necessary".

Enable Google Consent Mode v2 in the consent plugin, map statistics to analytics_storage and marketing to ad_storage, ad_user_data and ad_personalization, and install the WP Consent API if the plugin asks for it. If you use Site Kit, check that its consent mode setting is on and that it is not also adding a second Google tag outside the consent plugin.

"Accept all" and "Reject all" side by side, same size and weight.
A settings link for per-category choices.
A floating icon or footer link, "Cookie settings", that reopens the banner on every page.
A position that does not cover the whole screen on phones.

Our guide to a cookie banner that passes covers the first layer, lifetimes and wording in detail.

6. Make caching and optimisation plugins cooperate

Most consent failures on otherwise well-configured WordPress sites come from optimisation plugins:

Exclude the consent plugin's script from "delay JavaScript execution", "defer JavaScript" and "combine JavaScript" in WP Rocket, LiteSpeed Cache, Perfmatters and similar plugins. If the banner script is delayed until interaction, the banner appears late or not at all; if trackers are combined into one file, they can no longer be blocked individually.
Purge all caches after changing consent settings, including the host's cache and a CDN such as Cloudflare.
Geolocated banners need a cache that varies by country, or a plugin that decides in the browser. Otherwise the first visitor's version is served to everyone.

Our guide to two caching plugins and which to keep is worth reading if you are unsure which layer caches what.

7. Test before the click and after reject

In a private window: load the page, don't click anything, and check DevTools → Network for requests to google-analytics.com, facebook.net, hotjar.com and similar, and Application → Cookies for _ga, _fbp and _gcl_au. Then click "Reject all", browse two pages and check again. Then accept and confirm the tools start working.

How to verify with getReport

The cookie scanner loads your page in a fresh browser from Frankfurt, records every cookie and tracker, clicks the accept button it finds (it knows the selectors of 18 consent platforms and visible accept buttons in 20 languages), and records what appears afterwards. On a WordPress site the full report shows these findings together with the plugin table:

The scanner clicks Accept, not Reject, so test the refusal path by hand as in step 7. Scan more than the home page: a contact page with a map embed or a product page with a reviews widget often loads trackers the home page does not.

The banner itself has a cost too. The plugin detector shows each plugin's kilobytes on the page, so you can see whether your consent plugin is one of the heavier ones:

Common mistakes

A notice-only plugin that shows "We use cookies" with an OK button and blocks nothing.
Tracking code in the theme header that bypasses the consent plugin entirely.
Two consent plugins, or a consent plugin plus a cloud banner script, fighting over the same choice.
Google Analytics added twice: once by Site Kit or an analytics plugin and once by the consent plugin's integration, with only one of them blocked.
The consent script delayed by an optimisation plugin, so trackers load before the banner exists.
Analytics placed in "necessary" because the plugin's scan guessed wrong.
Never re-scanning after installing a new plugin, which may bring its own tracking.

Questions people ask

The best one is the one that demonstrably blocks the trackers your site uses before consent. Several established plugins do this, including Complianz, CookieYes, Cookiebot and Real Cookie Banner. Choose by script blocking for your tools, a first-layer reject button, Consent Mode v2 and WP Consent API support, then verify with a first-visit scan. A plugin with a nice banner but no blocking does not protect you.

Some do, some only show a notice. Several free plugins include automatic blocking of common trackers and Google Consent Mode, while others reserve blocking, geolocation or consent logs for paid plans. Read what the free tier includes, then test: load the site in a private window without clicking, and check that no analytics or pixel requests appear in the Network panel.

The WP Consent API is a free wordpress.org plugin that gives WordPress one shared place to store and read a visitor's consent by category. A consent plugin writes the choice once, and consent-aware plugins such as Site Kit by Google and WooCommerce read it before setting cookies. It does not show a banner itself; it connects the banner to the other plugins.

Usually because the tracking code does not go through the plugin. Snippets pasted into the theme header, a header-scripts plugin or a page builder run for everyone, and optimisation plugins that delay or combine JavaScript can load trackers before the banner. Find the source with a first-visit scan, move each tracker into the consent plugin or Tag Manager, and exclude the consent script from JavaScript delay.

WordPress cookie consent plugin: choosing one that really blocks scripts