WordPress Cookie Consent in 2026: What Has Changed

WordPress powers over 40% of the web, and enforcement of cookie consent rules has caught up. The French CNIL, the Italian Garante, and the Spanish AEPD have all fined sites that set analytics or marketing cookies before obtaining valid consent — and WordPress's plugin ecosystem makes this especially easy to do accidentally.

The core challenge with WordPress cookie consent in 2026 is that your site loads cookies from sources you did not explicitly add: your theme, your plugins, embedded third-party content, and the CMS itself. None of these respect a cookie banner by default.

This guide covers the full implementation — which plugins set cookies, how to install a CMP, server-side consent enforcement with WordPress hooks, WooCommerce checkout handling, Google Consent Mode v2, and the caching pitfalls that silently break compliance.

WordPress Plugins That Set Cookies (and What They Set)

Before you can configure consent, you need to know what you are consenting to. A cookie audit is the first step. Here are the plugins that most commonly set cookies on WordPress sites, and the specific cookies they create:

Common WordPress plugins and the cookies they set
Plugin	Cookies set	Category	Consent needed?
WooCommerce	woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_*	Necessary (cart/session) or Functional	Generally no for cart functionality — but marketing add-ons (recently viewed, cross-sells with tracking) do need consent
Yoast SEO	No cookies directly, but schema markup may trigger third-party resource loads (e.g. Google Knowledge Panel requests)	N/A	Monitor for third-party network connections
Jetpack	jetpack_sso_, tk_, multiple wp-stats cookies, quantcast cookies (if Jetpack Stats enabled)	Analytics / Marketing	Yes — Jetpack Stats tracks visitors via WordPress.com infrastructure
Contact Form 7 / WPForms	No cookies by default, but reCAPTCHA integration sets _GRECAPTCHA, NID, and related Google cookies	Necessary (spam prevention)	reCAPTCHA cookies are typically classed as necessary, but some DPAs disagree — document your justification
Google Analytics (via plugin or GTM)	_ga, _ga_*, _gid, _gat, _gcl_au	Analytics / Marketing	Yes — always requires prior consent in the EEA
Meta Pixel (via plugin or manual)	_fbp, _fbc, fr	Marketing	Yes
WordPress core	wordpress_test_cookie, wordpress_logged_in_, wp-settings-	Necessary	No — these are strictly necessary for CMS operation and authenticated sessions

The important takeaway: WordPress core cookies are necessary and exempt, but the moment you add analytics, marketing tools, or social embeds, you cross into territory that requires prior consent. Do not assume a plugin is consent-safe just because it is popular. Run a cookie scan after installing any new plugin to catch what it actually drops.

Plugins vs SaaS CMPs: Which Approach Works for WordPress

WordPress site owners typically choose between two approaches:

WordPress consent plugins live inside your installation, store consent in your database, and hook into WordPress's action/filter system. The upside is tight integration. The downside is that they are only as good as the last update — a plugin that has not implemented Google Consent Mode v2 or that still ships pre-ticked categories puts you at risk.

SaaS-based CMPs (like CookieBeam) run as external services. You add a single script tag, and the CMP handles banner rendering, consent storage, script blocking, cookie scanning, and Consent Mode signals from the cloud. Updates happen automatically — no waiting for a plugin release when a regulatory requirement changes.

For most WordPress sites in 2026, a SaaS CMP is the more reliable choice. The two approaches are not mutually exclusive though — you can use a SaaS CMP for consent management while using WordPress hooks for server-side enforcement.

Installing a CMP on WordPress: Script Tag vs Plugin

There are two ways to add a CMP script to WordPress: directly via a script tag in your theme, or via a lightweight loader plugin. Both work. The script tag approach gives you more control; the plugin approach is easier for non-developers.

Option 1: Script tag in your theme

Add the CMP script to your theme's functions.php (or, better, a site-specific plugin) using wp_enqueue_script. The CMP script must load before any other scripts on the page, so give it a high priority:

functions.php

1 // In functions.php or a site-specific plugin
2 add_action( 'wp_enqueue_scripts', 'load_cookiebeam_cmp', 1 );
3 
4 function load_cookiebeam_cmp() {
5     wp_enqueue_script(
6         'cookiebeam-cmp',
7         'https://cdn.cookiebeam.com/banner/YOUR_BANNER_ID/default/latest.js',
8         array(), // No dependencies — must load first
9         null,    // No version — CDN handles versioning
10         false    // Load in <head>, not footer
11     );
12 }

The CMP script must load before everything else

If your CMP script loads after analytics or marketing scripts, those scripts will fire before consent is established — making the entire setup non-compliant. Use priority 1 on the wp_enqueue_scripts hook and load in the <head> (not the footer) to ensure it executes first. If your theme or a performance plugin defers all scripts, exclude the CMP script from deferral.

Option 2: Direct insertion in header.php

If you want to bypass WordPress's script queue entirely (which avoids issues with optimization plugins rearranging script order), you can insert the CMP tag directly in your theme's header.php or via the wp_head action at the earliest priority:

functions.php

1 // Load CMP before wp_enqueue_script output
2 add_action( 'wp_head', 'inject_cookiebeam_early', 1 );
3 
4 function inject_cookiebeam_early() {
5     echo '<script src="https://cdn.cookiebeam.com/banner/YOUR_BANNER_ID/default/latest.js"></script>';
6 }

This approach is simpler and avoids any interference from caching or optimization plugins that rewrite enqueued scripts. The downside is that it is less "WordPress-native" — it will not show up in script dependency trees and cannot be dequeued by child themes.

Server-Side Consent Enforcement with WordPress

A CMP handles client-side blocking — preventing JavaScript from executing until consent is given. But WordPress also loads scripts server-side via wp_enqueue_script and wp_enqueue_style. If a plugin enqueues Google Analytics in PHP, the script tag is in the HTML before the CMP can intercept it. The CMP can still block execution using type="text/plain" rewriting, but a more robust approach is to prevent the script from being enqueued at all when consent is not yet given.

Dequeuing scripts conditionally

WordPress provides wp_dequeue_script to remove scripts that other plugins have registered. You can use this to strip out analytics and marketing scripts for visitors who have not yet consented:

consent-enforcement.php

1 add_action( 'wp_enqueue_scripts', 'enforce_consent_on_scripts', 999 );
2 
3 function enforce_consent_on_scripts() {
4     // Check if user has given analytics consent via cookie
5     $consent = isset( $_COOKIE['cookiebeam_consent'] )
6         ? json_decode( stripslashes( $_COOKIE['cookiebeam_consent'] ), true )
7         : null;
8 
9     $has_analytics_consent = is_array( $consent )
10         && isset( $consent['analytics'] )
11         && $consent['analytics'] === true;
12 
13     if ( ! $has_analytics_consent ) {
14         // Dequeue analytics scripts added by plugins
15         wp_dequeue_script( 'google-analytics' );
16         wp_dequeue_script( 'jetpack-stats' );
17         wp_dequeue_script( 'facebook-pixel' );
18     }
19 }

The priority of 999 ensures this runs after other plugins have enqueued their scripts, so there is something to dequeue. Adjust the script handles to match the actual handles used by your plugins — you can find them by inspecting the page source or using wp_scripts()->registered.

Consent-aware script registration

For scripts you control (your own tracking, custom analytics), you can conditionally enqueue them from the start:

consent-helper.php

1 add_action( 'wp_enqueue_scripts', 'enqueue_analytics_with_consent' );
2 
3 function enqueue_analytics_with_consent() {
4     if ( has_cookie_consent( 'analytics' ) ) {
5         wp_enqueue_script(
6             'site-analytics',
7             get_template_directory_uri() . '/js/analytics.js',
8             array(),
9             '1.0.0',
10             true
11         );
12     }
13 }
14 
15 function has_cookie_consent( $category ) {
16     if ( ! isset( $_COOKIE['cookiebeam_consent'] ) ) {
17         return false;
18     }
19     $consent = json_decode(
20         stripslashes( $_COOKIE['cookiebeam_consent'] ),
21         true
22     );
23     return is_array( $consent )
24         && isset( $consent[ $category ] )
25         && $consent[ $category ] === true;
26 }

Note that server-side consent checking reads the consent cookie, which is only set after the first page load where the user interacts with the banner. On the very first visit, there is no cookie yet — the CMP's client-side blocking handles that initial pageview. Server-side enforcement adds a second layer for subsequent page loads and is especially useful for scripts that plugins enqueue in ways that are hard to intercept client-side.

WooCommerce Checkout and Consent

WooCommerce is a special case because checkout requires session cookies and payment gateway scripts that must work regardless of cookie preferences.

Session and payment cookies are strictly necessary. wp_woocommerce_session_*, woocommerce_cart_hash, and payment processor scripts (Stripe, PayPal) are essential to the cart and checkout flow — do not block them behind consent, or you will break your store.

Marketing add-ons do need consent. Recently viewed products, cross-sell recommendation engines, abandoned cart plugins (which set persistent tracking cookies), and custom product analytics should be categorized as analytics or marketing and blocked until consent is given.

woo-consent.php

1 // Dequeue WooCommerce marketing add-ons without consent
2 add_action( 'wp_enqueue_scripts', 'gate_woo_marketing_scripts', 999 );
3 
4 function gate_woo_marketing_scripts() {
5     if ( ! has_cookie_consent( 'marketing' ) ) {
6         // Example: dequeue abandoned cart tracking
7         wp_dequeue_script( 'woo-abandoned-cart-tracking' );
8         // Example: dequeue product recommendation tracker
9         wp_dequeue_script( 'woo-recommendations-tracker' );
10     }
11 }

Google Consent Mode v2 with WordPress and GTM

If you use Google Tag Manager on your WordPress site, you need Google Consent Mode v2 to be set up properly. Consent Mode tells Google tags (GA4, Google Ads, Floodlight) the visitor's consent state so they can adjust their behavior — firing in a limited, cookieless mode when consent is denied, and fully when it is granted.

How CookieBeam integrates with Consent Mode on WordPress

CookieBeam automatically sets the Consent Mode default and update commands. When you install the CookieBeam script on your WordPress site, it:

Sets consent('default', ...) with all non-essential consent types denied before GTM loads
Calls consent('update', ...) when the visitor interacts with the banner, updating the consent state for analytics_storage, ad_storage, ad_user_data, and ad_personalization

The key requirement is that the CookieBeam script loads before the GTM container snippet. If GTM loads first and fires tags before the default consent state is set, those tags will run without any consent signal — which means no behavioral modeling and no compliance.

gtm-consent-mode.php

1 // Correct load order: CookieBeam first, then GTM
2 add_action( 'wp_head', 'inject_cookiebeam_early', 1 );
3 add_action( 'wp_head', 'inject_gtm_container', 2 );
4 
5 function inject_cookiebeam_early() {
6     echo '<script src="https://cdn.cookiebeam.com/banner/YOUR_BANNER_ID/default/latest.js"></script>';
7 }
8 
9 function inject_gtm_container() {
10     ?>
11     <script>
12     (function(w,d,s,l,i){w[l]=w[l]||[];
13     w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});
14     var f=d.getElementsByTagName(s)[0],
15     j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';
16     j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;
17     f.parentNode.insertBefore(j,f);
18     })(window,document,'script','dataLayer','GTM-XXXXXXX');
19     </script>
20     <?php
21 }

For more detail on what Consent Mode does to your GA4 data, see our guide on how Consent Mode v2 affects GA4 reporting. The short version: with Consent Mode properly configured, GA4 uses behavioral modeling to recover some of the data that would otherwise be lost from non-consenting visitors.

The Caching Problem: WordPress's Biggest Consent Pitfall

Caching is where most WordPress consent implementations silently break. WordPress sites almost universally use caching — WP Super Cache, W3 Total Cache, WP Rocket, LiteSpeed Cache, Cloudflare, or Nginx FastCGI — and every one of these can undermine your setup.

Problem 1: Page caching serves cookies before consent

When a page cache stores the full HTML response, it may also cache Set-Cookie headers from plugins. A first-time visitor receives cached tracking cookies in the response headers before they see the consent banner. Fix: configure your caching plugin to strip non-essential Set-Cookie headers from cached responses, or exclude pages that set tracking cookies from the cache.

Problem 2: CDN caching consent choices

If your CDN caches a page that includes server-side consent enforcement (different HTML based on the consent cookie), it serves one visitor's consent state to everyone else. This is especially problematic with the wp_dequeue_script approach above.

cache-consent-fix.php

1 // Tell caching plugins not to cache when consent state varies
2 add_action( 'init', 'vary_cache_by_consent' );
3 
4 function vary_cache_by_consent() {
5     if ( isset( $_COOKIE['cookiebeam_consent'] ) ) {
6         // Signal to caching plugins that this response varies
7         if ( ! defined( 'DONOTCACHEPAGE' ) ) {
8             define( 'DONOTCACHEPAGE', true );
9         }
10         // For Cloudflare / Varnish: add Vary header
11         header( 'Vary: Cookie', false );
12     }
13 }

DONOTCACHEPAGE disables caching entirely for consented visitors

The code above is a nuclear option — it prevents page caching for any visitor who has interacted with the consent banner. A better approach is to keep server-side consent enforcement lightweight (only dequeue/enqueue scripts, do not change page content based on consent state) so that page caching remains safe. Let the CMP handle client-side script blocking, and use server-side dequeuing only as a defense-in-depth layer. If your cached and uncached HTML are identical except for which scripts are loaded, most CDNs will handle it correctly with client-side blocking alone.

Problem 3: Optimization plugins rewriting your CMP script

Performance plugins like WP Rocket, Autoptimize, and LiteSpeed Cache often defer, async, or concatenate JavaScript files. If they defer your CMP script, it loads after the rest of the page's JavaScript — which means analytics and marketing scripts fire before consent is established.

Always exclude your CMP script from JavaScript optimization. In WP Rocket, add the CMP URL to the "Excluded JavaScript" list. In Autoptimize, add it to "Exclude scripts from Autoptimize." In LiteSpeed Cache, add it to the JS excludes. The performance cost of loading one small script synchronously is negligible compared to the compliance cost of loading it late.

How CookieBeam Works with WordPress

CookieBeam is designed to work with any website that can load a script tag, and WordPress is no exception. Here is what the integration looks like:

Installation

You add a single script tag to your WordPress site using any of the methods described above — wp_head action, wp_enqueue_script, or a header/footer injection plugin. There is no WordPress-specific plugin to install or maintain. The CMP script is served from CookieBeam's CDN and updates automatically when you change your banner configuration in the CookieBeam dashboard.

Auto-scanning

CookieBeam's cookie scanner crawls your WordPress site and detects all cookies, scripts, and third-party connections — including those set by plugins you may not even know about. It categorizes them automatically and alerts you when new trackers appear (drift detection). This is especially valuable for WordPress because the plugin ecosystem makes your cookie footprint unpredictable. A plugin update can introduce new tracking that was not there before.

Script blocking

CookieBeam blocks non-essential scripts client-side using the type="text/plain" pattern described in our script blocking guide. For WordPress sites, you can tag your scripts with data-category attributes in your theme, or use CookieBeam's auto-blocking feature which identifies known tracking scripts and blocks them without manual tagging.

Consent Mode v2

CookieBeam ships Consent Mode v2 signals out of the box. No additional GTM configuration is needed beyond ensuring the CookieBeam script loads before GTM. Your GA4, Google Ads, and Floodlight tags will automatically respect the visitor's consent choices.

Regional consent

CookieBeam adapts the banner behavior based on the visitor's location. EEA visitors see a prior-consent banner (opt-in). US visitors can see an opt-out notice that complies with state laws like CCPA/CPRA. This is handled automatically by CookieBeam's regional consent engine — no WordPress configuration needed.

Common Mistakes to Avoid

Loading the CMP in the footer. Your CMP must load in the <head> before any other scripts. Footer loading guarantees tracking fires before consent.
Not excluding the CMP from optimization plugins. WP Rocket, Autoptimize, and LiteSpeed Cache will defer or concatenate your CMP script unless excluded. This breaks consent timing.
Relying only on server-side enforcement. Server-side wp_dequeue_script does not work on the first pageview (no consent cookie exists yet). Client-side blocking is the primary mechanism; server-side is a backup.
Forgetting embedded content. YouTube embeds, Google Maps, and social share buttons set cookies. Lazy-load them behind consent or use privacy-enhanced modes (youtube-nocookie.com).
Caching consent state into HTML. If server-side enforcement produces different HTML per consent state, page caching serves the wrong version. Keep page content identical and let client-side blocking handle it.
Using consent plugins that do not block scripts. Many free WordPress consent plugins display a banner but perform no script blocking — creating a false sense of compliance while cookies fire unchecked.

A Recommended WordPress Consent Setup

Putting it all together for a WordPress site with WooCommerce, GA4 (via GTM), and typical marketing plugins:

Audit your cookies. Run CookieBeam's scanner against your live site to get a complete inventory.
Install the CMP script first. Add CookieBeam via wp_head at priority 1. Ensure it loads before GTM.
Load GTM second. Use wp_head at priority 2. Verify in DevTools that the CookieBeam script appears before GTM in the DOM.
Tag remaining scripts. Add type="text/plain" and data-category to any tracking scripts loaded outside GTM. See our script blocking guide.
Add server-side enforcement. Use wp_dequeue_script at priority 999 as defense-in-depth.
Exclude the CMP from optimization. Whitelist the CookieBeam URL in your caching plugin's JS exclusion list.
Test in incognito. Verify no non-essential cookies or third-party requests appear before banner interaction. Confirm consent('default', ...) fires before GTM.

Testing Your Implementation

A consent implementation is only as good as its testing. Here is a quick testing checklist:

Open the site in a private/incognito window (no existing cookies)
Before interacting with the banner, open DevTools > Application > Cookies. You should see only strictly necessary cookies (WordPress core cookies, WooCommerce session cookies if you added items to cart)
Check DevTools > Network and filter for third-party domains. No analytics or marketing requests should appear before consent
In the Console, run dataLayer and check that the consent default command appears before the gtm.js event
Accept all cookies in the banner. Verify that analytics and marketing scripts now load and their cookies appear
Reject all cookies. Refresh the page. Verify the rejection persists and no non-essential cookies are set
Reopen the consent preferences (via the floating button or footer link). Change your choices. Verify the change takes effect immediately

If you are using CookieBeam, the dashboard's scan results will show you exactly which cookies your site is setting and whether any are loading before consent — giving you an ongoing monitoring layer that catches regressions from plugin updates or theme changes.

WordPress Cookie Consent in 2026: The Complete Implementation Guide