CookieYes audit guide for agencies (2026)

TL;DR - CookieYes is one of the most widely deployed CMPs in the WordPress ecosystem, with a Google-certified banner, a generous free tier, and IAB TCF support on the Pro and Ultimate tiers. A self-scan from any CMP is useful operational inventory, but it is not the same artefact as independent evidence from a separate verifier. This guide explains how to audit a CookieYes installation in practice - and when self-scanning alone is enough.

What CookieYes does well

CookieYes has a strong WordPress footprint: it is a Google-certified CMP, its WordPress plugin has more than 1 million active installs, and the company reports more than 1.5 million businesses on the platform. For a WordPress site of any size, the plugin is a few clicks from a working banner, and the WordPress integration is one of the more thorough in the category (custom post types, multilingual plugins, page builders).

The free tier is unusually generous. €0 / $0 / £0 per month buys you 5,000 monthly pageviews and 100 scanned pages on one domain - enough for a working installation on a small site without ever paying. The lowest paid tier (Basic, $10/month at USD display) raises that to 100,000 monthly pageviews and 600 scanned pages. Google Consent Mode v2 is available across all tiers, including the free tier. The Pro tier ($25/month at USD display) adds IAB TCF, GPC signal support, geo-targeting, and monthly scheduled scanning. The Ultimate tier ($55/month) lifts the pageview cap entirely.

For an operator whose primary need is "show a clear banner on a WordPress site, register consent, gate the obvious tags," CookieYes does the job, and that is a real strength of the product. Where it gets harder is the next question: how do you know it's actually working in real user sessions, especially on sites that aren't WordPress?

Common CookieYes implementation issues that self-scans may miss

Like any automated scan, a CookieYes scan follows a bounded scan path and observation window. The script that fires when the crawler visits your site is not necessarily the same script that fires when a real user visits from a German IP on a Tuesday afternoon. Four patterns we see repeatedly on CookieYes-protected sites that turn up in real-user audits:

1. Tag manager and Consent Mode race conditions. The highest-frequency issue, and shared with every other CMP on the market. The Google Tag Manager snippet is hardcoded inline above the CookieYes loader, so GTM initializes (and any tag with default consent set to granted fires) before the auto-blocker has a chance to intervene. Or Consent Mode v2 is wired with one or more of the four parameters defaulted to 'granted' instead of 'denied', producing the same result without the loader-ordering issue. The audit is simple: check script order, check Consent Mode defaults, then verify the first-load network trace.

2. WordPress plugin scope limits. CookieYes can block non-essential scripts and cookies in typical WordPress plugin flows, but the vendor's own guidance notes that scripts or cookies created outside CookieYes's control may still need manual handling. We see this most often with marketing widgets pasted directly into footer.php, with chat widgets installed via "paste this snippet" instructions, and with embedded forms that load their own analytics. That is where a browser-level audit helps: it verifies the live first-load network, not only the plugin configuration.

3. Non-WordPress installs miss the WordPress-plugin integration conveniences. CookieYes works on any site that can drop in a script tag, and the SaaS dashboard treats Shopify, Wix, custom-stack, and headless sites identically. Cookie auto-blocking and iframe blocking are available across plans, but the WordPress-specific theme integration, native admin UX, and plugin-only conveniences are WordPress-only. On a Shopify or Next.js site, you get the banner, the consent storage, and the auto-blocking, but custom-stack implementations should still be verified script by script because tags pasted directly into theme files or injected by other apps can sit outside the consent path.

4. Conditional and behavior-triggered marketing scripts. A scroll-triggered recorder, a delayed chat widget, an A/B-test branch, or a dynamically injected tag may not be exercised by a fixed crawler path. Treat these as manual verification targets: reproduce the user action, reject consent, reload, and check whether the tag still fires.

Step-by-step audit checklist

Each step is something you can do in a browser; an external scanner shortcuts the manual work.

1. Open the site in a clean browser profile, dev tools open, network filter on "third-party." Reload. Anything that fires before you click a banner button is a candidate.
2. Check the GTM snippet position. If the GTM loader is above the CookieYes loader in the page source, the auto-blocker is racing the tag manager. On WordPress, verify the plugin's "load before other scripts" option is enabled.
3. Verify Consent Mode v2 default state. Search the rendered page for gtag('consent', 'default'. The argument should set all four parameters - analytics_storage, ad_storage, ad_user_data, ad_personalization - to 'denied'. If any read 'granted', that's the misconfiguration.
4. Click reject. Reload. Check the same network capture. A correctly configured CookieYes install should show no third-party trackers in the post-reject network. If Meta Pixel, LinkedIn Insight, or Google Analytics still fire after reject, the consent state is not being propagated.
5. Test consent persistence across pages. Click reject, navigate to a second page. The banner should not reappear. If it does - the consent_respawn pattern - the cookie scope or lifetime is wrong, regardless of what the dashboard reports.
6. On WordPress, audit theme and page-builder injections. Search header.php, footer.php, and any "custom HTML" page-builder blocks for hardcoded script tags. These bypass the plugin's auto-blocking.
7. Switch the page to each of your live languages. Check that the cookie declaration translates and that the listed trackers match the current scan, not last quarter's.
8. Test from a non-EU IP. Some CookieYes configurations geotarget the banner to EU visitors only. If you serve users in Switzerland, the UK, or Brazil, verify the banner appears as expected.
9. Compare the network capture against the CookieYes declaration. Every non-essential cookie-setting service or tracking domain that fires before consent should appear, classified, in the declaration. Drift between live behavior and declared trackers is a common defect.
10. Save the network capture as evidence. A .har file with timestamps is a durable audit record - stronger evidence than a dashboard screenshot.

When CookieYes alone is enough

We do not recommend adding external auditing to every CookieYes deployment. For the following profile, CookieYes's built-in scanner is sufficient and a second tool is overhead:

• A single WordPress site, one or two languages, one domain.
• The CookieYes WordPress plugin (not the SaaS-only embed) so you get the auto-blocking and theme-aware injection.
• No Google Tag Manager or just a simple Google Analytics 4 install through the plugin's gated injection.
• No client reporting requirement.
• No higher-scrutiny profile (low traffic, B2C non-sensitive content, no past complaints).

For this profile, the CookieYes free or Basic tier does the job and any additional tooling is a tax. The free tier in particular (5,000 monthly pageviews, 100 scanned pages) is a working entry point for many real small sites.

When to add independent auditing

The case for external verification scales with three factors, and one of them is sharper for CookieYes users than for most CMPs:

Multi-CMS portfolio. This is the sharpest wedge. CookieYes's WordPress plugin is especially deep on the WordPress side; on Shopify, Wix, custom Next.js, or headless commerce the same product runs without the WordPress-specific theme integration and admin UX. Agencies maintaining a portfolio of clients on heterogeneous stacks benefit from a uniform audit layer that doesn't care which CMS the site runs on. An external scanner produces the same evidence pack for the WordPress site, the Shopify storefront, and the custom-stack landing page.

Marketing tag complexity. GTM, Meta Pixel, Google Ads conversion, LinkedIn Insight, TikTok Pixel, server-side tagging - every additional tag multiplies the surface area where a default-granted slip can fire trackers before consent.

Higher-scrutiny profile. Cookie-consent implementation is a recurring subject of DPA scrutiny, so for operators that would attract regulator attention if a complaint landed - high-traffic publishers, ad-supported media, financial services, healthcare - a durable, non-vendor evidence trail is materially different from a vendor's dashboard screenshot.

Evidence packs for procurement. Enterprise clients in regulated industries often request independent technical evidence as part of vendor onboarding. An external scan report addresses that ask in a way a screenshot of the CookieYes dashboard does not.

CookieYes vs. independent auditing

CookieYes and GDPR Privacy Monitor are different products serving different needs. CookieYes generates and manages your consent UX, especially well on WordPress; GDPR Privacy Monitor verifies that the result behaves correctly in the wild, regardless of the underlying CMS.

A clean CookieYes install on a single WordPress site should usually land in the low-risk band. A score in the 40s typically means one practical issue is present - for example, a tracker firing before consent, a post-reject persistence problem, or a banner configuration issue that needs review.

Run an independent scan on the site you're auditing

Start a free scan or view a sample report to see what an external capture looks like alongside the CookieYes dashboard.

Frequently asked questions

Is the CookieYes free tier enough for my small WordPress site?

For a single small WordPress site under 5,000 monthly pageviews with one or two languages, no GTM, no marketing pixels beyond Google Analytics 4, and no agency reporting requirement - yes, the free tier is genuinely sufficient. CookieYes's free tier is one of the more generous in the market and is a meaningful working entry point for small sites. If you outgrow it, the Basic paid tier ($10/month at USD display) lifts the pageview budget to 100,000.

How does CookieYes compare to Cookiebot?

Different products with different default audiences. CookieYes is plugin-first and especially strong on WordPress; Cookiebot is dashboard-first and equally strong across CMS integrations. Both are Google-aware and both have credible scanners. Cookiebot supports IAB TCF on its paid tiers; CookieYes supports IAB TCF on Pro and Ultimate. CookieYes's free tier is more generous for low-traffic sites; Cookiebot's Premium Lite tier runs €7/month when EUR is selected while CookieYes's Basic runs $10/month at USD display, but Cookiebot pricing depends on the number of domains and subpages, so multi-domain agency use can move beyond the entry tier quickly. Pick by your primary stack: WordPress-first agencies often prefer CookieYes; multi-CMS shops and SaaS-first teams often prefer Cookiebot.

CookieYes is Google-certified. Does that mean it's compliant by default?

No, and the certification doesn't claim to. Google certification means the CMP's Consent Mode v2 integration meets Google's requirements - it does not certify that any given installation respects the user's consent choices in real sessions. The certification is a vendor-level signal; your specific deployment can still fire trackers before consent if the tag manager is misconfigured or scripts bypass the plugin scope. Independent verification catches the gap between "the CMP is certified" and "this specific install is working."

Does CookieYes work outside WordPress?

Yes. The SaaS dashboard generates a script tag that drops into any HTML page, and the consent storage works the same on Shopify, Wix, headless, or custom-stack sites. CookieYes's pricing page lists cookie auto-blocking and iframe blocking as features available across plans, including outside WordPress. What is genuinely WordPress-only is the WordPress plugin layer: theme integration, WordPress-native admin UX, and plugin-specific conveniences. On Shopify or custom-stack sites you still get the banner, consent storage, and auto-blocking, but operators should still verify script-by-script gating because tags pasted into theme files or injected by other apps can sit outside the consent path. Agencies running multi-CMS portfolios often pair CookieYes with an independent audit layer to confirm the live behavior matches the dashboard across stacks.

Why can CookieYes look clean while an agency audit still finds pre-consent trackers?

Usually because a tag sits outside the plugin-controlled path, GTM is not consent-aware, or a script runs before the consent state is applied. A live browser trace catches that gap. A self-scan dashboard may not reproduce every first-load race condition or user-triggered path, while a clean browser network trace shows what actually fires before the user interacts with the banner.

Run a free CookieYes verification scan

Before you write a remediation plan, see what an independent capture shows on the site you're auditing. GDPR Privacy Monitor's free scan returns a network-level breakdown of what fires before consent, what survives reject, and what the cookie declaration says vs. what the network does. No account required for the first scan.

Start a free scan or view a sample report to see the format before you commit.

---

Other audit guides: Cookiebot · OneTrust · Iubenda · Complianz Background: Pre-consent tracking explained

---

Pricing and feature claims verified 2026-05-06 against cookieyes.com/pricing. CookieYes's pricing page is canonical when figures change. Set a quarterly reminder to re-verify.