Cookie Consent For Wordpress
A WordPress consent banner that actually blocks — and keeps the proof in your database.
wp plugin install devix-cookie-consent --activate
Live demo coming soon
Trackers enqueued by your theme and plugins are rewritten so the browser treats them as data: never fetched, never run. YouTube, Vimeo and Maps embeds keep their URL out of reach until the visitor allows them. Google Analytics, Tag Manager, the Meta pixel, Hotjar, Clarity, TikTok, LinkedIn and HubSpot are recognised the moment you switch it on. Google Consent Mode v2 is denied by default, Global Privacy Control counts as a refusal, and every decision becomes a row in this site's own database with a hashed IP. No account, no quota, no dashboard somewhere else.
What you get
Blocks what WordPress enqueues
Scripts, the inline code attached to them, oEmbeds and hand-pasted iframes — with an optional whole-page scan for snippets pasted into a theme.
Useful the moment it is on
Analytics, Tag Manager, Site Kit, the Meta pixel, Hotjar, Clarity, Matomo, Plausible, Segment, TikTok, LinkedIn, Google Ads and HubSpot are recognised by handle or URL out of the box.
Google Consent Mode v2
Denied before any Google tag, with ads_data_redaction and wait_for_update, then updated to match the decision — not an upsell.
The proof stays here
One row per decision and per change of mind, in your own database, with the IP stored as a hash and pruning on the schedule you set.
Read on the server
A category the visitor has already allowed is printed as an ordinary tag — the cookie is read in PHP, so there is no blocking round trip at all.
Nothing phones home
The widget is bundled with the plugin. No account, no page-view quota, no third-party request before your visitor has agreed to anything.
Cookie Consent for WordPress — overview
Why it exists
The free cookie plugins in the WordPress directory mostly show a banner and set a flag; the ones that genuinely block are freemium front ends for a subscription, and the record of what your visitors agreed to lives in someone else's dashboard.
What it does differently
- Blocks by default, and knows what to block. The common trackers are recognised on install, by script handle or URL — no rule writing before the plugin is useful.
- Three layers of blocking, because WordPress scripts arrive three ways: enqueued, inline, and pasted into a theme.
- Consent Mode v2 printed before any Google tag.
- The proof stays here. One row per decision, in this site's database, with a hashed IP.
- Nothing phones home. The widget is bundled; there is no account and no dashboard elsewhere.
- Reads consent on the server, so an allowed tag is printed as itself.
Not in 1.0
A cookie scanner that crawls the site, IAB TCF 2.2, and multi-site management are the Pro edition's shape. The JavaScript widget and the Laravel package are separate products in this catalogue.
How it compares
Questions
Does it really stop the tracker?
Yes. A blocked script is rewritten to type="text/plain", so the browser never fetches or runs it, and an embed's src is held in data-cc-src so no connection is made. The end-to-end tests assert it by checking whether the blocked scripts actually executed.
A tag is still getting through.
It was probably printed straight into your theme rather than enqueued. Switch on “Scan the whole page” in the settings, which rewrites anything pointing at a known third-party host.
Will this break Google Analytics?
No — it makes it lawful. With Consent Mode v2 on, Google's tags load but hold their data until the visitor answers, then behave according to that answer.
Where is the consent record kept?
In a table in your own database, with the visitor's IP hashed using this site's salt. Nothing is sent anywhere else, and there is no quota on how many decisions you may store.
How is this different from CookieYes or Complianz?
Blocking and Consent Mode are not paid features here, there is no page-view quota, and the proof of consent is in your database rather than someone's dashboard. Their cookie scanners are genuinely useful, and ours is planned for the Pro edition.
Does it work with page caching?
Yes. Blocked markup is the same for everyone, so a cached page is still correct; the widget releases the tags in the browser. The server-side shortcut only applies to visitors whose decision is already known.