CookieYes's consent mechanism follows the same well-documented shape as Complianz: category/consent state lives in a browser cookie, and third-party scripts are blocked by swapping their type attribute (rather than removing them from the markup) until the visitor consents. Unlike Complianz, CookieYes declares no REST route or server-side bridge at all — the static build only has to preserve that markup exactly, with zero WordPress involvement on a per-visitor basis, which is what keeps it in Fully Static rather than Complianz's Hybrid.
Fully Static
The consent banner and its script-blocking markup (the type="text/plain" / data-category attribute swap) are served from the static release.
None — consent state is resolved entirely client-side, and scanning the site for cookies/scripts plus banner configuration are both admin-only, logged-in activities.
None needed — CookieYes declares no public routes of its own.
No special setup — detected automatically once active.
Any HTML-cleanup or minification step in the static pipeline that strips unrecognized script attributes would break CookieYes's consent-based script blocking, letting tracking or marketing scripts load for visitors who never consented — never rewrite or strip those attributes during static generation. This classification is rule-derived from CookieYes's known architecture, not from an automated end-to-end test.
Static Shield Lite is free to install and inspects your actual plugins, not just what's publicly visible.
Get Static Shield
Tulapp