How to Detect Cloudflare Bot Management on Any Site

Cloudflare sits in front of a large share of the public web, and a growing number of those sites layer Cloudflare Bot Management on top of the basic CDN. If you do competitive research, security reconnaissance on your own attack surface, or technographic lead qualification, knowing whether a target runs Cloudflare—and whether bot management is switched on—is a useful signal.

The challenge is that none of this is advertised. There’s no badge in the footer that says “protected by Cloudflare Bot Management.” But the evidence is in the HTTP response headers, the DNS records, and the TLS certificate. This guide walks through each manual signal, then shows how to collapse all of them into a single API call.

What Cloudflare Bot Management Actually Is

It helps to separate two things that are easy to conflate. Cloudflare is the content-delivery network and reverse proxy that fronts a site—handling caching, TLS termination, and DDoS mitigation. Cloudflare Bot Management is a separate paid product that runs on that proxy layer and scores incoming requests to identify and block automated traffic.

A site can use Cloudflare as a CDN without ever enabling Bot Management. That’s why detection tools treat them as two distinct technologies: Cloudflare lands in the CDN category, and Cloudflare Bot Management lands in the Security category. When you scan a site like notion.com or cloudflare.com itself, you’ll see both entries in the results because both are present.

Signals That Reveal Cloudflare on a Website

Before you can detect Bot Management, you confirm the site is behind Cloudflare at all. There are three independent signals, and the strongest approach uses all three because each can be inconclusive on its own.

HTTP Headers and Server Fingerprints

HTTP response headers are the fastest signal. Cloudflare injects identifying headers into every proxied response and, unlike many CDNs, advertises itself directly in the Server header. Run a curl -I against any URL:

$ curl -sI https://www.cloudflare.com | grep -iE "server|cf-ray|cf-cache"
server: cloudflare
cf-ray: 8e2a1b3c4d5e6f7a-IAD
cf-cache-status: DYNAMIC

The two headers that matter most:

• Server: cloudflare — Cloudflare identifies itself by name. Almost no other CDN does this so plainly.
• CF-Ray — present on every Cloudflare-proxied response. The suffix (here -IAD) names the edge data center that served the request.

Bot Management itself does not always expose a single dedicated public header on a normal request—its scoring happens server-side and is surfaced to the origin, not the visitor. That’s exactly why a fingerprint database that has already mapped the product’s combined signals is more reliable than eyeballing one header. The limitation of manual header reading is that operators can strip or rename headers, so treat headers as a strong-but-not-complete signal.

DNS and Nameserver Evidence

DNS is the signal that’s hardest to hide. When a domain is managed through Cloudflare, its authoritative nameservers are Cloudflare’s own. Check them with dig:

$ dig NS cloudflare.com +short
ns3.cloudflare.com.
ns4.cloudflare.com.

$ dig NS example-customer.com +short
abby.ns.cloudflare.com.
sam.ns.cloudflare.com.

Cloudflare-managed domains resolve to nameservers under *.ns.cloudflare.com. When Cloudflare’s proxy mode is on (the orange-cloud setting), the A record also points at a Cloudflare anycast IP rather than the origin server, which masks the origin while still revealing Cloudflare. For a deeper look at why CNAME and nameserver evidence is so durable, see DNS-Based Technology Detection.

A TLS certificate inspection rounds out the picture. Proxied Cloudflare sites present an edge certificate issued by Cloudflare:

$ echo | openssl s_client -connect cloudflare.com:443 2>/dev/null \
  | openssl x509 -noout -issuer
issuer=C=US, O=Cloudflare, Inc., CN=Cloudflare Inc ECC CA-3

When the issuer organization is “Cloudflare, Inc.,” the site is proxied through Cloudflare’s network—even if a header was stripped somewhere along the way.

Manual Detection vs. an API Approach

Running curl -I, dig, and openssl is fine for a one-off check on a single domain. It breaks down the moment you need to do this at scale or want a clean machine-readable answer.

Manual checks have three practical problems. First, they require stitching together three separate tools and interpreting the output by hand. Second, a single stripped header or a masked origin can make any one signal inconclusive, so you have to cross-reference. Third, none of it tells you cleanly whether the higher-level Bot Management product is active, versus plain Cloudflare CDN—that distinction comes from matching a combination of signals against a maintained fingerprint database.

An API approach solves all three. It resolves DNS, reads headers, inspects the TLS certificate, and matches everything against a fingerprint set in one request—then hands you structured JSON with each technology placed in its category and assigned a confidence score. For a fuller comparison of why browser extensions can’t see the DNS and TLS layers at all, see DNS + TLS Detection vs Browser Extensions.

Detect Cloudflare Bot Management with the DetectZeStack API

The fastest way to try this is the public demo endpoint, which needs no API key. Point it at any URL and you get the full technology breakdown back:

$ curl -s "https://detectzestack.com/demo?url=https://www.cloudflare.com" | python3 -m json.tool

The response is a single JSON object. Here’s a trimmed example showing the Cloudflare and Bot Management entries you care about:

{
  "url": "https://www.cloudflare.com/",
  "domain": "www.cloudflare.com",
  "technologies": [
    {
      "name": "Cloudflare",
      "categories": ["CDN"],
      "confidence": 100,
      "description": "Cloudflare is a web-infrastructure and website-security company, providing content-delivery-network services, DDoS mitigation, Internet security, and distributed domain-name-server services.",
      "website": "https://www.cloudflare.com",
      "icon": "CloudFlare.svg",
      "source": "http",
      "version": "",
      "cpe": ""
    },
    {
      "name": "Cloudflare Bot Management",
      "categories": ["Security"],
      "confidence": 100,
      "description": "Cloudflare bot management solution identifies and mitigates automated traffic to protect websites from bad bots.",
      "website": "https://www.cloudflare.com/en-gb/products/bot-management/",
      "icon": "CloudFlare.svg",
      "source": "http",
      "version": "",
      "cpe": ""
    }
  ],
  "categories": {
    "CDN": ["Cloudflare"],
    "Security": ["HSTS", "Cloudflare Bot Management"]
  },
  "meta": { "status_code": 200, "tech_count": 7, "scan_depth": "full" },
  "cached": false,
  "response_ms": 1842
}

Reading the JSON Response for CDN and Security Categories

Two parts of the response answer the question directly. The technologies array lists every detected technology with its name, categories, confidence, and source. The categories map is the inverse view—it groups technology names by category, so you can check categories.Security for "Cloudflare Bot Management" in one lookup.

A few fields worth understanding:

• confidence — how certain the detection is. HTTP-header matches like Cloudflare Bot Management return 100; DNS CNAME matches typically return 80 and TLS-only matches 70.
• source — which layer produced the match: http, dns, or tls. Bot Management is detected from the HTTP layer, so its source is http.
• meta.scan_depth — full when the site responded to the HTTP fetch, or partial when only DNS and TLS signals were available (for example, when a site blocks the request entirely).

The only fields inside meta are status_code, tech_count, and scan_depth. Note that cached and response_ms are top-level fields, not nested under meta.

To pull just the security technologies with jq:

$ curl -s "https://detectzestack.com/demo?url=https://www.cloudflare.com" \
  | jq '.technologies[] | select(.categories[] | contains("Security")) | .name'
"HSTS"
"Cloudflare Bot Management"

For authenticated, higher-volume use, the same shape comes back from the /analyze endpoint with your RapidAPI key:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=https://notion.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
  | jq '.categories.Security'
[
  "HSTS",
  "Cloudflare Bot Management",
  "hCaptcha"
]

Batch-Scanning Many Domains at Once

For a list of domains, loop over them and filter for the Bot Management entry. A small bash + jq pipeline against the demo endpoint works for modest lists:

$ cat domains.txt
cloudflare.com
notion.com
example.com

$ while read domain; do
    has_bm=$(curl -s "https://detectzestack.com/demo?url=https://$domain" \
      | jq -r '[.technologies[].name] | index("Cloudflare Bot Management") != null')
    echo "$domain,$has_bm"
  done < domains.txt
cloudflare.com,true
notion.com,true
example.com,false

For thousands of domains you’ll want an authenticated key, a worker pool, and proper error handling rather than a serial loop. The pattern—bounded concurrency, retries, CSV export, and handling partial scans—is covered in Batch Scan 1,000 Websites for Tech Stack.

Common Use Cases for Cloudflare Detection

Detecting Cloudflare and its bot-management layer shows up in several workflows:

• Security reconnaissance — mapping your own organization’s external attack surface, or assessing how a target behaves under automated load before authorized testing.
• Competitive and market research — understanding which infrastructure and security vendors a competitor relies on, the same way you’d study their CDN and hosting choices.
• Technographic lead qualification — the presence of a paid product like Bot Management is a spend signal that helps sales teams prioritize accounts.
• Migration and due diligence — confirming what a site actually runs before a platform migration or an acquisition tech review.
• Monitoring over time — tracking when a portfolio of sites adds or removes Cloudflare protection.

Conclusion and Next Steps

Detecting Cloudflare Bot Management comes down to two questions. Is the site behind Cloudflare? Confirm with the Server: cloudflare and CF-Ray headers, the *.ns.cloudflare.com nameservers, and the Cloudflare-issued TLS certificate. Is the bot-management product active? That’s where a fingerprint-backed API earns its keep—a single request returns a Cloudflare Bot Management entry in the Security category with 100% confidence when it’s present.

Start with the free /demo endpoint to confirm the response shape on a domain you already know, then move to the /analyze endpoint with a key when you’re ready to scan at volume.