

GDPR cookie consent with real script blocking.
Block Google Analytics, Google Tag Manager, Meta Pixel, Hotjar, YouTube embeds, and other third-party services before they reach the browser.
Unlike JavaScript-based consent tools, blocked scripts never reach the browser at all.
Most cookie consent plugins display a banner and rely on JavaScript to stop tracking scripts. In many cases, those scripts can begin loading before the visitor has made a choice.
COOKR takes a different approach.
Scripts are blocked server-side before page delivery. Third-party services cannot execute until consent is explicitly granted. This helps website owners meet GDPR and TTDSG requirements more reliably.
Avoids the client-side race conditions common to JavaScript-only consent tools. No script guessing. No “hope it loads in time.”
Consent enforcement instead of consent theatre.
✓ Server-side script blocking — blocked before the browser receives them
✓ Google Consent Mode v2 support
✓ No external consent cloud
✓ No proxy infrastructure
✓ No visitor data sent to third parties
✓ Works entirely on your WordPress installation
Built for site owners, agencies, and developers who want real GDPR cookie consent enforcement.
COOKR CORE includes:
window.cookrConsent)COOKR RADR additionally includes:
COOKR intercepts scripts in the PHP output buffer using WP_HTML_Tag_Processor before delivery to the browser. Matching script and iframe tags are neutralised server-side and restored only after the visitor grants consent.
There is no client-side race condition because blocking happens before the browser receives the page.
Your consent choices are applied precisely — analytics, marketing, and external media are gated independently, with no mixups between categories. You can withdraw consent at any time; it takes effect starting with your next page load.
COOKR is safe to use with page caching. The server-rendered HTML is always consent-neutral — a cached page never carries one visitor’s consent-based content into another visitor’s response.
If COOKR encounters an internal enforcement failure, it fails closed rather than silently serving unblocked trackers.
COOKR blocks known trackers that are present in the server-rendered HTML as standard external <script src> or <iframe> elements, before the visitor’s browser ever receives them.
It does not intercept arbitrary JavaScript behaviour at runtime. This includes: scripts and iframes created dynamically after page load, document.write()-based script injection, and tracker requests proxied through a first-party URL — COOKR matches known third-party hostnames, so a same-origin proxy path is invisible to that classification regardless of what it forwards to server-side.
One consequence worth knowing specifically: once a tag manager such as Google Tag Manager is itself permitted to run (its own <script src> was consented to and restored), whatever tags that container subsequently injects at runtime are outside COOKR’s enforcement scope. Configuring consent-aware tag firing inside the tag manager itself remains the site owner’s responsibility.
These are architectural limits of a server-side, markup-level blocker, not partial results. If your site loads trackers through any of the paths above, COOKR will not enforce consent on them — migrate them to standard external <script src>/<iframe> markup to bring them into scope.
Enable in Settings. Off by default.
When enabled, COOKR rewrites matching script tags and iframe tags server-side — setting type="text/plain" and preserving original attributes in data-cookr-* attributes for restoration after consent.
Test after enabling when using WP Rocket, LiteSpeed Cache, NitroPack, or Cloudflare Rocket Loader.
The Runtime Inspector exposes third-party runtime activity directly in the browser — blocked scripts, restored services, iframe activity, detected domains.
Enable in Settings. Append ?cookr_debug=1 to any frontend URL while logged in as administrator.
COOKR is verified compatible with WP Rocket and Autoptimize. It is partially verified with LiteSpeed Cache — see the Compatibility Center for exactly which parts are confirmed. For other caching and optimization plugins, check your own site’s Compatibility Center before assuming full compatibility.
COOKR never sends its own Content-Security-Policy header. It supports strict Content-Security-Policy setups without requiring unsafe-inline, provided your CSP layer supplies a nonce through the cookr_csp_nonce filter.
If your site runs a nonce-based script-src policy, hook the cookr_csp_nonce filter once with the nonce your CSP layer already generates for the response:
add_filter( 'cookr_csp_nonce', function () { return my_csp_plugin_get_nonce(); } );
COOKR then applies that single nonce consistently to its own scripts and to every dynamically-restored, consented tracker script. Without a hooked cookr_csp_nonce provider, COOKR’s own scripts and any restored tracker scripts will be blocked by a strict script-src policy with no 'unsafe-inline' — the Diagnostics self-test reports this explicitly (CSP nonce: pass/warn) rather than silently assuming it works.
cookrConsent.has('analytics')
cookrConsent.require('marketing', callback)
cookrConsent.whenConsented('analytics').then(fn)
cookrConsent.on('consent' | 'change' | 'decline' | 'reset', handler)
cookrConsent.off(event, handler)
cookrConsent.getConsent()
cookrConsent.getExpiry()
cookrConsent.categories()
cookrConsent.reset()
No. COOKR runs entirely on your WordPress installation.
No. Consent data is stored locally on your site.
No. Enable and test it after installation, particularly when using caching or JavaScript optimization plugins.
Any third-party script or iframe matching configured domains, when present in the server-rendered page as a standard external <script src> or <iframe> element. Examples: Google Tag Manager, Meta Pixel, YouTube embeds, TikTok Analytics.
COOKR gates GTM’s own <script src> load — GTM itself will not run before consent. Once a visitor consents and GTM is restored, tags that GTM subsequently injects at runtime are outside COOKR’s enforcement scope; that’s a tag manager configuration question, not something a markup-level blocker can see. See “Scope of Enforcement” above for the full picture.
Yes. Enable in settings when using GTM or GA4.
Enable the Runtime Inspector in settings and append ?cookr_debug=1 to any frontend URL while logged in as administrator.
The consent log stores a hashed IP (not the raw IP address), consent choices, and a timestamp. The raw IP address is never stored.
Yes, if your site’s CSP layer supplies a nonce. COOKR does not generate or send its own CSP, and it cannot see a nonce your CSP-generating plugin creates unless you connect the two: hook the cookr_csp_nonce filter once to return that nonce. COOKR then applies it consistently to its own scripts and to every dynamically-restored, consented tracker script. Without that filter hooked, a strict script-src policy with no 'unsafe-inline' will block COOKR’s own scripts as well as any restored trackers — check Settings Diagnostics, which reports the CSP nonce check explicitly rather than assuming success.
Yes, but always test after enabling script optimization features such as JavaScript combine, defer, delay, or Rocket Loader. COOKR performs script blocking server-side, but aggressive optimization plugins may alter script delivery and should be verified on your site.
COOKR automatically excludes itself and the tracker scripts it blocks from LiteSpeed Cache, WP Rocket, Autoptimize, and FlyingPress’s JavaScript optimization pipelines — no configuration required. Check the Compatibility Center (COOKR Compatibility) for the current tested/verified status of your specific stack.
Yes. COOKR requires HTTPS for consent state to persist correctly across page loads. Modern browsers restrict cookie behaviour on HTTP origins — on HTTP, the consent cookie may not persist, causing the banner to reappear on every page load. HTTPS is also a legal recommendation under GDPR for any site collecting consent.
WordPress 6.2 or higher. COOKR uses WP_HTML_Tag_Processor for safe, attribute-aware script rewriting, introduced in WP 6.2.
This plugin does not connect to any external service by default.
The auto-blocker contains a built-in list of known third-party domains (such as googletagmanager.com, connect.facebook.net, maps.googleapis.com, etc.) that is used purely as a local reference to identify and block scripts before consent. No data is sent to these domains by this plugin — the list is pattern-matching data stored locally in the plugin code.