Find Companies Using CookieYes: Detection API Guide

Cookie consent platforms are the most honest technographic signal on a website. Nobody installs one for fun. A company installs a consent management platform because somebody — legal, a customer, a regulator, an enterprise buyer’s security questionnaire — made them, and the platform they picked tells you how much they were willing to spend to satisfy that pressure.

CookieYes sits at the low-cost, self-serve end of that market, and that is exactly what makes it useful. A list of companies using CookieYes is a list of companies that have a compliance obligation and a small budget. That combination is a buying signal for privacy tooling, for agencies, for WordPress maintenance services, and for anyone selling the upmarket alternative.

This guide covers the exact fingerprints CookieYes leaves in page HTML, how to check one site with curl, how to screen a list with the API, and what the data says about who actually runs it.

Why Companies Using CookieYes Are a Distinct Prospect Segment

There are 84 technologies in the Cookie compliance category of the fingerprint database, but only a handful appear often enough to matter. Here is how the main ones rank across the 4,636 domains in the DetectZeStack index as of September 20, 2026:

One caveat worth stating plainly before you build anything on those numbers: this index is the set of domains our users have scanned, not a random sample of the web. It is skewed toward whatever people point the API at. Use it for relative shape, not for market share.

CookieYes Skews SMB and WordPress, Not Enterprise CMP

The relative shape is the interesting part. Taking every domain in the index where CookieYes was detected and asking what else runs on those same domains produces a remarkably consistent profile:

That is not an enterprise stack. It is a WordPress site with a page builder, an SEO plugin, a contact form, and a tag manager — a marketing site built by a small team or a small agency.

The contrast with OneTrust in the same index makes the point sharper. Of 264 OneTrust domains, only 47 run WordPress (17.8%), while 51 sit behind Akamai and 26 run Adobe Experience Manager. Of 143 CookieYes domains, 104 run WordPress (72.7%). Same category, same regulatory driver, two completely different buyers.

CookieYes is not WordPress-only, though, and assuming it is will cost you real prospects. The platform split across those 143 domains: 104 WordPress, 14 Webflow, 4 Next.js, 2 Shopify. The Webflow tail is the notable one — trainual.com and www.auror.co are both Webflow sites running CookieYes, which is a different company profile from the WordPress majority.

How CookieYes Fingerprints Show Up in Page Source

CookieYes is detected from the HTTP response body. There are three script-source patterns, and which one a site uses tells you how CookieYes was installed.

Script Sources: app.cookieyes.com/client_data/ and cdn-cookieyes.com/client_data/

The hosted script is the most common install. It carries a per-site identifier in the path and is loaded with a set of attributes designed to stop optimization plugins from touching it. This is the real tag from seesaw.com:

<script id="cookieyes" type="text/javascript"
  src="https://cdn-cookieyes.com/client_data/4314bcefdbe31920285762ef/script.js"
  data-cfasync="false" data-no-optimize="1"
  data-noptimize="1" data-no-defer="1" data-no-minify="1"></script>

Two host variants exist, cdn-cookieyes.com and app.cookieyes.com, and both are matched on the /client_data/ path segment. The hex string is the site’s CookieYes account identifier. It is stable per site, which makes it a usable join key if you are tracking the same domains over time.

The data-cfasync="false" and data-no-optimize attributes are a side signal in their own right: they are instructions to Cloudflare Rocket Loader and to WordPress caching plugins. A consent script has to load before everything it gates, so it is always exempted from the optimizations applied to the rest of the page.

The WordPress Signal: /wp-content/plugins/cookie-law-info/ Script Paths

CookieYes started life as the WordPress plugin “Cookie Law Info,” and the plugin directory still carries that name. Sites running the plugin’s bundled script rather than the hosted one expose a path that includes a version query string:

<script id="cookie-law-info-js"
  src="https://ilovepecans.org/wp-content/plugins/cookie-law-info/lite/frontend/js/script.min.js?ver=3.5.6">
</script>

That ?ver=3.5.6 is captured directly into the version field of the API response. It is the difference between knowing a prospect uses CookieYes and knowing they are three releases behind on it.

This only works for the plugin-path install. In the index, 40 of 143 CookieYes domains resolved to a specific version; the other 103 load the hosted script, whose URL contains no version at all. The versions that did resolve spread from 3.5.6 at the current end down to a single site still on 2.0.6 — a spread that is itself a segmentation axis if you sell maintenance.

DOM and JS Markers (#cookie-law-info-bar, window.cookieYes) and Why an HTTP Scan Misses Them

Two more markers exist and are worth knowing for manual verification, but they behave differently from the script sources.

The banner container carries a stable id. Older installs render #cookie-law-info-bar; current ones render #cky-consent-bar inside #cky-consent-container, and the cky- prefix shows up across the whole widget. The JavaScript marker is a cookieYes global on window.

Here is the honest limitation: DetectZeStack fingerprints the HTTP response — headers and HTML body — without executing JavaScript. The consent banner is injected by the CookieYes script at runtime, and the window.cookieYes global only exists after that script has run. Neither is present in the HTML an HTTP client receives. They are excellent confirmations in DevTools and useless in a curl pipeline.

This is the right trade for scanning a list, because the script tag that creates those markers is in the HTML, and that is what the API matches on. It matters only in one specific failure case, covered further down.

Manual Check With curl Before You Automate

Before you write a pipeline, confirm the signal by hand. One command settles it:

$ curl -s https://seesaw.com | grep -o 'cdn-cookieyes.com/client_data/'
cdn-cookieyes.com/client_data/

A version-bearing check against a plugin-path install:

$ curl -s https://ilovepecans.org | grep -o 'cookie-law-info[^"]*ver=[0-9.]*'
cookie-law-info/lite/frontend/js/script.min.js?ver=3.5.6

Catch both install types in one pass with an alternation:

$ curl -sL https://example.com | grep -oE 'cookieyes\.com/client_data/|cookie-law-info'

Add -L whenever the apex domain might redirect, and add a browser User-Agent if you get a 403. In DevTools the equivalent check is document.querySelector('#cky-consent-bar') or simply typing cookieYes in the console.

API Example: Detect CookieYes With DetectZeStack

GET /demo — Free Single-Domain Check, No Key Required

The /demo endpoint runs the same detection as the paid endpoint and needs no signup:

curl -s "https://detectzestack.com/demo?url=seesaw.com"

Piping through jq gets straight to the answer:

curl -s "https://detectzestack.com/demo?url=seesaw.com" \
  | jq -r '.technologies[] | select(.name == "CookieYes")'

GET /analyze — Full Stack With Categories and Versions

Same response shape as /demo, against your own quota and without the per-IP cap:

curl -s "https://detectzestack.com/analyze?url=https://ilovepecans.org" \
  -H "X-API-Key: YOUR_KEY" \
  | jq -r '.technologies[] | select(.name == "CookieYes") | "\(.name) \(.version)"'

CookieYes 3.5.6

GET /check?tech=CookieYes — Yes/No With Confidence and Version

When you only need a boolean, /check collapses the full stack into one flat object:

curl -s "https://detectzestack.com/check?url=https://seesaw.com&tech=cookieyes" \
  -H "X-API-Key: YOUR_KEY"

{
  "domain": "seesaw.com",
  "technology": "CookieYes",
  "detected": true,
  "confidence": 100,
  "version": "",
  "categories": ["Cookie compliance"],
  "response_ms": 0,
  "cached": true
}

The tech parameter is case-insensitive and the response echoes back the canonical name, so cookieyes comes back as CookieYes. A negative is an explicit "detected": false with an empty categories array rather than an error, which makes it safe to run across a list without special-casing misses.

POST /analyze/batch — Screen a Domain List for CookieYes

Ten URLs per call, scanned concurrently, results returned in input order:

curl -s -X POST "https://detectzestack.com/analyze/batch" \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"urls":["https://seesaw.com","https://ilovepecans.org","https://www.rumpl.com"]}'

Each entry in results has a url and a result holding exactly the object /analyze returns, so the filter reaches one level deeper:

... | jq -r '.results[]
  | select(.result.technologies[]?.name == "CookieYes")
  | .result.domain'

For lists longer than ten domains, chunk them — see Batch Scan 1,000 Websites for the full pattern including retries and rate-limit handling.

GET /lookup?tech=CookieYes — Domains Already Seen Running CookieYes

The other direction: instead of asking whether a domain you already have runs CookieYes, ask which indexed domains do. No scanning, no waiting.

curl -s "https://detectzestack.com/lookup?tech=CookieYes&limit=50" \
  -H "X-API-Key: YOUR_KEY"

{
  "technology": "CookieYes",
  "total": 143,
  "results": [
    {
      "domain": "seesaw.com",
      "category": "Cookie compliance",
      "confidence": 100,
      "version": "",
      "first_seen": "2026-09-20T03:44:00Z",
      "last_seen": "2026-09-20T03:44:00Z"
    }
  ],
  "limit": 50,
  "offset": 0,
  "response_ms": 10
}

total is the full count regardless of how many rows come back, so you can size the job before paging through it with offset. The first_seen and last_seen timestamps are the useful part for outreach: a domain first seen with CookieYes last week is a fresh install, and a fresh install means somebody on that team is actively working the compliance problem right now.

Reading the Response: What Detected, Version, and Categories Actually Mean

Here is the live /demo response for ilovepecans.org, trimmed to the CookieYes entry and the summary fields:

{
  "url": "https://ilovepecans.org",
  "domain": "ilovepecans.org",
  "technologies": [
    {
      "name": "CookieYes",
      "version": "3.5.6",
      "categories": ["Cookie compliance"],
      "confidence": 100,
      "website": "https://www.cookieyes.com/",
      "icon": "cookieyes.svg",
      "source": "http"
    }
  ],
  "categories": {
    "Cookie compliance": ["CookieYes"],
    "CMS": ["WordPress"],
    "Page builders": ["wpBakery"],
    "Ecommerce": ["WooCommerce"]
  },
  "meta": {
    "status_code": 200,
    "tech_count": 23,
    "scan_depth": "full"
  },
  "cached": false,
  "response_ms": 1890
}

Four things to know when writing code against this:

• source: "http" — CookieYes was found in the HTTP response body. Other technologies in the same response carry "dns" or "tls". CookieYes will never be "dns"; no DNS record reveals a consent platform.
• confidence: 100 — an unambiguous script-source match. Lower scores appear on inferred signals; Let’s Encrypt, for example, comes back at 70 because certificate-issuer inference is weaker evidence.
• version — present only for plugin-path installs. An empty string means “hosted script, version not knowable from the HTML,” not “no version.” Do not filter it out as a failed detection.
• cached and response_ms — both top-level, not inside meta. A cached hit returns response_ms: 0. The only fields inside meta are status_code, tech_count, and scan_depth.

CookieYes carries no description and no cpe in the fingerprint data, so those fields are absent from the object rather than empty. Read defensively.

Turning CookieYes Detections Into a Qualified List

A raw list of CookieYes domains is not yet a prospect list. The qualification happens in the rest of the same response — which costs you nothing extra, because one scan returns the entire stack.

Enrich With WordPress, Elementor, and Analytics Signals From the Same Response

Compare two real detections. seesaw.com returns 19 technologies:

Cloudflare, Cloudflare Bot Management, CookieYes, Elementor,
Google Tag Manager, Gravity Forms, HTTP/3, Let's Encrypt, MySQL,
PHP, Swiper, WP Engine, WPML, Wistia, WordPress, Yoast SEO,
Yoast SEO Premium, jQuery, jQuery Migrate

www.rumpl.com returns 17, with no overlap in the commercial layer at all:

Cart Functionality, Cloudflare, CookieYes, Covet.pics, Fondue,
Google Analytics, Google Tag Manager, HSTS, HTTP/3, Intelligems,
Klaviyo, Let's Encrypt, Rebuy, Shopify, Slick, Swiper, jQuery

Both are “companies using CookieYes.” Only one is a WordPress marketing site on managed hosting with a paid SEO plugin and a translation layer, which tells you there is a budget and someone who owns the site. The other is a Shopify store with a conversion-optimization stack, which tells you the buyer sits in ecommerce, not IT.

Three filters that turn the raw list into something a salesperson can work:

• Paid-plugin signals. Yoast SEO Premium, WPML, Gravity Forms, and WP Engine all cost money. A site carrying several of them has a real budget line for its website. Elementor appears on 25.9% of CookieYes domains and WP Engine on another 25.9% — these are not rare.
• Version staleness. Filter version to anything below the current 3.5.x line. A site on 2.0.6 has an unmaintained compliance plugin, which is a concrete thing to open a conversation about.
• Analytics presence. Google Tag Manager appears on 68.5% of CookieYes domains. A consent platform plus a tag manager means there are tags actually being gated — a live compliance implementation, not a banner someone installed and forgot.

The general pattern here — scan once, filter on co-occurrence, score the result — is covered end to end in Building a Lead Enrichment Pipeline With Tech Detection.

Limits, Caching, and Tier Result Caps You Should Plan Around

The false negative that will fool you: client-side script injection

The clearest example is CookieYes’s own website. Scan cookieyes.com and the response comes back with five technologies — Cloudflare, Google Cloud, Google Tag Manager, HSTS, HTTP/3 — and no CookieYes.

That is not a bug in the detection, and cookieyes.com does run CookieYes. The site is built on Next.js and loads the consent script through the framework’s Script component with an afterInteractive strategy. What actually ships in the server HTML is a preload hint:

<link rel="preload"
  href="https://cdn-cookieyes.com/client_data/e5ee5d26e0341217ffb7eccd/script.js"
  as="script"/>

That is a link tag, not a script tag. The actual <script src> is created by JavaScript after hydration, and an HTTP-only scan never sees it. Any modern framework that defers third-party scripts this way will produce the same false negative — which is part of why only 4 of 143 indexed CookieYes domains are Next.js sites. The true number is certainly higher.

If you need to close that gap, the recovery is a headless browser on the subset that came back empty. For a list of a thousand domains, run the API first and reserve the expensive rendering pass for the misses.

Bot challenges return a page that is not the site

A domain behind a challenge returns the challenge page, not the site. You can spot it by what did come back: a result consisting only of edge-layer technologies such as Cloudflare, Cloudflare Bot Management, and HSTS, with no application layer at all, is a blocked fetch rather than a bare site. Do not record those as CookieYes negatives.

Caching and tier caps

Repeat scans of the same domain return "cached": true with response_ms: 0. That is useful when you are iterating on a jq filter, and something to be aware of if you are trying to measure a change you just shipped.

The /lookup endpoint caps how many rows each plan can see per request. The free tier returns 2 — enough to confirm the endpoint works, not enough to build a list. The paid caps are 50, 200, and 800 rows per request, and offset pages through the rest. The total field always reports the true count regardless of tier, so you can see the size of what you are not getting. Batch calls count each URL in the batch against your monthly request quota.

Get an API Key and Run Your First CookieYes Scan

CookieYes detection comes down to one rule: read the HTML body for a script source, not the headers. cdn-cookieyes.com/client_data/, app.cookieyes.com/client_data/, and /wp-content/plugins/cookie-law-info/ are the three patterns, and the third one hands you a version number for free.

Start with the free demo call on a domain you already know, then move to a key when you want to run it against a list or page through the ones already indexed.

Conclusion

Consent platform choice is one of the few technographic signals that maps cleanly onto company size and budget, because it is driven by an obligation nobody volunteers for. CookieYes marks the self-serve, WordPress-heavy, small-budget end of that market, and the same scan that identifies it hands you the page builder, the host, the SEO plugin, and the tag manager that qualify the account.

One scan, one response, everything you need to decide whether the domain is worth an email. Start with the free demo call.