Cookie Consent for WordPress and WooCommerce

Most of the web's cookie compliance problem lives on WordPress. It is also where the most consent banners are installed — and where a surprising number of them don't do very much.

We've published katla-app/wordpress, a plugin that connects a WordPress or WooCommerce site to Katla. It loads the consent script, blocks non-consented scripts and embeds on the server, and renders the cookie and privacy policies Katla generates from your actual scanned cookies.

The problem with blocking in the browser

Katla's cookie guard stops cookies from being written. That is the right primitive, and on a hand-built site it's usually enough, because you control which scripts are on the page.

WordPress is different. A theme enqueues a script. Three plugins enqueue four more. A page builder injects a pixel. By the time a visitor loads the page, there are trackers on it that nobody deliberately added — and a tracker that loads has already made a request to a third party carrying an IP address and a referrer, whether or not it managed to set a cookie.

Blocking that in the browser is a race you don't reliably win. The consent script has to execute, patch the right globals, and neutralise the tag before the tag runs. Sometimes it does. Then an optimisation plugin reorders your scripts and it doesn't.

So block it before the page is sent

The plugin does the blocking server-side, while WordPress is still assembling the HTML. Map a script handle to a category — on the Blocking tab or in code:

add_action( 'wp_enqueue_scripts', function () {
	katla_block_script( 'google-analytics', 'analytics' );
	katla_block_script( 'facebook-pixel', 'marketing' );
}, 20 );

The script that reaches the browser is inert:

<script type="text/plain" data-katla-src="…" data-katla-category="analytics"></script>

There is no race, because the executable version never existed in the response.

The detail we care most about is what happens to inline scripts. Analytics tags are rarely one file — there's a loader, then an inline gtag('config', …) or a dataLayer push attached to the same handle through wp_add_inline_script. Blockers that only handle the src tend to drop those, and the tag comes back after consent configured wrong or not at all. This plugin neutralises inline scripts alongside their handle and replays them in source order once the category is allowed, so the tag is restored exactly as WordPress assembled it.

WooCommerce, where breaking things is expensive

A consent plugin on a store has a second job that matters as much as compliance: don't break the store. Block the wrong handle and the cart stops updating, or checkout silently fails, and you find out from a customer.

So the WooCommerce integration is mostly a list of things the plugin refuses to do. Cart, session and checkout cookies bypass the guard entirely — woocommerce_cart_hash, wp_woocommerce_session_*, wc_fragments_* and friends. Store-critical handles like wc-cart-fragments, wc-checkout and wc-blocks-checkout are stripped out of the blocked list, so a careless rule can't take checkout down. It declares compatibility with HPOS and the cart/checkout blocks.

One deliberate exception: order attribution cookies (sbjs_*) are not allowlisted. They are marketing cookies — convenient ones, but marketing. If you want them gone before consent, gate the wc-order-attribution handle.

Three levels of control

The default needs no code: Katla renders the banner and preferences dialog, styled from your dashboard.

If you'd rather own the markup, headless mode loads the guard and window.KatlaConsent without the hosted UI, and the plugin renders its own banner — translated through WordPress, styled with CSS custom properties, so it inherits your theme:

add_filter( 'katla_banner_css_vars', function () {
	return array(
		'katla-primary' => '#111111',
		'katla-radius'  => '0px',
		'katla-font'    => 'var(--wp--preset--font-family--body)',
	);
} );

Or turn the UI off entirely and build your own against window.KatlaConsent and the katla:consent event. Same guard underneath in all three cases.

Policies that are actually on the page

[katla_policy] renders your generated cookie and privacy policy server-side, as part of the page HTML. Not an iframe, not a client-side fetch — real markup, indexable, styled by your theme, and regenerated from your cookies as they change. There's a Gutenberg block for every shortcode, plus [katla_cookie_table] if you only want the tables and [katla_cookie_settings] for the "manage preferences" link your policy page needs anyway.

Getting started

You need a verified Katla site with at least one completed scan — the plugin needs cookie data to render policies. Then:

wp plugin activate katla-consent
wp katla site-id 00000000-0000-0000-0000-000000000000
wp katla verify

Or paste the Site ID into Settings → Katla Consent.

The WordPress guide covers the shortcodes, the filters, the WP-CLI commands and the WooCommerce specifics. The plugin is on GitHub at katla-app/wordpress — issues and pull requests welcome.