Bot Protection Check
Find out what type of bot protection a website uses. Paste any URL to see the bot management, WAF, CDN and CAPTCHA stack behind it — Cloudflare, DataDome, Akamai, HUMAN, Imperva, AWS WAF, reCAPTCHA — and whether it challenged our request. Free, no signup.
Test the stack before you spend an account
Antybrowser profiles keep the fingerprint, the exit IP and the DNS path consistent per account — what bot management scores in the first place. Check the site, then check what your browser shows it.
Bot Protection Check: What Type of Bot Protection Does a Website Use?
Before a website decides whether to serve you a page, it decides whether to let you near one. That decision is made by a bot-management platform, a web application firewall or a CDN edge — and each of them leaves fingerprints in the response. This free bot protection check requests a URL the way a server-side client would, names the protection stack it found, and shows the header, cookie or challenge page that identified it.
If you have searched for “what type of bot protection does a website use”, “how to check what WAF a site uses”, “is this site protected by Cloudflare”, “DataDome vs Akamai”, “how to detect bot protection” or “does this website have a captcha”, this guide covers each of those questions: the layers a protected site runs, how to recognise every major vendor, and what the answer means for your setup.
What Type of Bot Protection Does a Website Use?
“Bot protection” is an umbrella term for four different layers, and most sites run at least two of them:
1. CDN / edge network
Cloudflare, Akamai, Fastly, Amazon CloudFront, Azure Front Door, Vercel or Bunny terminate the connection, cache the page and can rate-limit or geo-block. The edge announces itself in response headers: server: cloudflare, cf-ray, x-served-by, x-amz-cf-id, x-azure-ref.
2. WAF (web application firewall)
AWS WAF, Sucuri, FortiWeb, Barracuda, Imperva and Signal Sciences inspect the request against rule sets: SQL injection, bad user-agents, blocked ASNs, known scanners. A WAF can allow, challenge or block, and it usually leaves a header (x-amzn-waf-action, x-iinfo, x-sucuri-id) or a cookie.
3. Bot management
Cloudflare Bot Management, DataDome, Akamai Bot Manager, HUMAN/PerimeterX, Kasada, Imperva and F5/Shape score the browser session itself — fingerprint, behaviour, reputation — and return a challenge when the score is bad. This is the layer people mean when they ask why a site blocks “a normal browser”.
4. CAPTCHA and proof-of-work
reCAPTCHA (v2, v3, Enterprise), hCaptcha, Cloudflare Turnstile, Arkose Labs/FunCaptcha, GeeTest, Friendly Captcha, MTCaptcha and Altcha add an explicit human check. They are often the visible part of the stack, but they are not the whole defence.
How to Check What Bot Protection or WAF a Website Uses
If you only need the answer for one site, this tool does it: paste the URL and read the verdict. If you want to see it yourself, the signals are in three places.
Response headers
Open DevTools → Network → the document request → Response Headers. A single glance often answers the question: server: cloudflare plus cf-ray means Cloudflare; server: AkamaiGHost means Akamai; x-datadome means DataDome; x-iinfo means Imperva; x-amzn-waf-action means AWS WAF; x-sucuri-id means Sucuri.
Cookies set on the first response
Bot-management vendors persist a state cookie: __cf_bm and cf_clearance (Cloudflare), datadome (DataDome), _px3 and _pxhd (HUMAN/PerimeterX), _abck and bm_sz (Akamai), kp_ (Kasada), incap_ses_ and visid_incap_ (Imperva), aws-waf-token (AWS WAF). A cookie alone is strong evidence — you cannot get one without the vendor being in front of the site.
Challenge pages and script bundles
A 403 or 503 with “Just a moment…”, a captcha-delivery.com interstitial, an Akamai “Reference #” block page or an _Incapsula_Resource iframe is the vendor showing its hand. On a normal page, the sensor script itself is the tell: /cdn-cgi/challenge-platform/ (Cloudflare), js.datadome.co, px-cdn.net, kpsdk (Kasada).
How to Tell If a Website Uses Cloudflare Bot Management
Cloudflare is the most common answer to “what bot protection does this site use”, and also the most misunderstood. There are three levels, and the difference matters:
A site behind Cloudflare's CDN shows server: cloudflare and cf-ray on every response — that is caching and DDoS protection, not necessarily bot management. A site that issues __cf_bm or cf_clearance is running bot management. A site that answers a plain server request with HTTP 403 and a “Just a moment” / challenge-platform page is actively enforcing it.
The tool reports those three situations differently: edge-only is medium confidence with a summary that says no challenge was observed, while a challenge page is high confidence and sets the “challenged” flag. That distinction is the difference between “Cloudflare is in front of this site” and “this site blocks automation”.
DataDome, Akamai, HUMAN, Imperva, Kasada and AWS WAF — How to Recognize Each
Each vendor has a signature that is hard to fake, and the tool matches all of them:
DataDome
Server: DataDome, x-datadome / x-datadome-cid / x-datadome-riskscore headers, a datadome cookie, and a captcha-delivery.com interstitial when it blocks. Common on marketplaces and retail (Etsy and many fashion sites).
Akamai Bot Manager
Server: AkamaiGHost plus the _abck validation cookie and bm_sz/bm_sv/bm_mi sensors. The sensor script posts encrypted telemetry; replaying the cookies without it rarely works. Amazon properties and many enterprises sit behind it.
HUMAN Security (PerimeterX)
The _px family of cookies (_px3, _pxhd, _pxvid, pxcts) and scripts from px-cdn.net or px-cloud.net. Behavioural scoring with a “press and hold” interstitial when it is suspicious.
Imperva / Incapsula
incap_ses_ and visid_incap_ cookies, an x-iinfo header, and the _Incapsula_Resource iframe that delivers the challenge. Also used as a plain WAF without bot management.
Kasada
x-kpsdk-ct / x-kpsdk-cd headers and kp_* cookies. The sensor script is re-signed per request, which is why Kasada is one of the harder stacks to replay. Found on ticketing, sneakers and travel.
AWS WAF
x-amzn-waf-action: challenge or captcha, an aws-waf-token cookie, and captcha.awswaf.com challenge scripts. Common on sites hosted on AWS that enabled WAF rules — including Booking.com.
Smaller stacks worth knowing
F5/Shape (TS01/TSPD_ cookies), Radware (rdwr), Sucuri (x-sucuri-id), FortiWeb (FORTIWAFSID), Barracuda (barra_ cookies), Reblaze (rbzid), Signal Sciences (sigsci_ cookies), CrowdSec, DDoS-Guard, Qrator, Queue-it (virtual waiting rooms) and Netacea.
Why Do Sites Block VPNs and Datacenter IPs?
Bot protection scores the request before the page renders, and one of the strongest inputs is where the request comes from. Datacenter ranges (AWS, DigitalOcean, OVH, Hetzner, Vultr) are where scrapers and bots live, so a request from one starts with a much lower trust score than a residential connection — even if the browser is perfect. Commercial VPNs usually exit from those same ranges, which is why “VPN on” can make a site harder to use, not easier.
This is also why this tool sees challenges that your browser does not: the scan comes from our server, which is exactly the kind of client bot protection is built to stop. A challenge served to a datacenter IP while your browser loads the page normally is not a false positive — it is proof that the protection is enforcing, and it is often the strongest signal available. The next question is what the site does with a residential IP and a coherent browser session, which is where the proxy checker and fingerprint checker come in.
Bot Protection vs CAPTCHA vs WAF: What's the Difference?
A WAF decides whether a request looks like an attack. Bot management decides whether a session looks like a browser. A CAPTCHA asks for explicit proof of humanity when the first two are unsure. In practice they are layered: a CDN terminates the connection, a WAF filters obvious abuse, bot management scores the session, and a CAPTCHA catches the cases that fall through.
That is why “does this site have a captcha” is a weak question — plenty of sites run full bot management and show a CAPTCHA only to the 1% of traffic it decides to challenge. The useful question is what stack is behind the page, which is what this check reports.
Does Bot Protection Affect Normal Browsing?
Usually not: a real browser with normal navigation, cookies and a residential IP scores well and never sees a challenge. Problems start when the session looks synthetic — a fresh profile with no history, an IP from a hosting range, a user-agent that disagrees with the platform, WebRTC leaking a different IP, or automation flags. Vendors also score behaviour: instant form fills, no mouse movement, perfectly regular navigation.
If a site challenges you repeatedly, run the fingerprint checker and the captcha & bot test before blaming the site: a failing Turnstile or a low reCAPTCHA v3 score means the session already looks automated, and the cause is usually in the profile, not in the protection.
What to Do If a Site Blocks You
Match the identity to the site's expectations. Use one exit IP per account (no mid-session switching, or the clearance cookie is bound to the old IP), keep the fingerprint coherent — platform, user-agent, Client Hints, timezone, languages and screen must tell one story — and keep the profile residential-looking from the first request. Avoid reusing a flagged profile for a new account: bot management remembers device identifiers for a long time.
For multiple accounts, Antybrowser gives each one an isolated profile with its own fingerprint, proxy and DNS path, which is what prevents the accounts from being linked in the first place. The check tells you what the site runs; the profile is what you bring to it.
What This Check Cannot See
The check answers with one HTTP request, not a full browser session. It does not execute the page's JavaScript, solve challenges, log in or submit a form, so it sees the first response a client gets — the most informative one for identifying the stack. Protection that only appears on a checkout, an API route or after login will not show up on a home page. It also never attempts a bypass: the catalog exists to make the protection layer legible, not to defeat it.
Every protected site tells you what it runs if you read the response instead of the page. Check the stack before you invest in an account, then align the rest of the setup with it: an exit IP that matches the profile, a fingerprint that is coherent on every surface, and a session that behaves like a session. “What type of bot protection does this website use?” is the first question; the answer decides how much work the rest of the setup needs.
Related tools
See what type of fingerprinting the same website uses.
Captcha & bot test →Run real reCAPTCHA and Turnstile challenges against your browser.
Proxy checker →Check the exit IP, fraud score and blocklists behind your profile.
Download Antybrowser →Isolated profiles with their own fingerprint, proxy and DNS path.
Frequently asked questions
What type of bot protection does a website use?
One of four layers, usually several together: a CDN or edge (Cloudflare, Akamai, Fastly, CloudFront, Azure Front Door, Vercel), a WAF (AWS WAF, Sucuri, FortiWeb, Barracuda, Signal Sciences), bot management (Cloudflare Bot Management, DataDome, Akamai Bot Manager, HUMAN/PerimeterX, Kasada, Imperva, F5) and a CAPTCHA provider (reCAPTCHA, hCaptcha, Turnstile, Arkose, GeeTest). This check names the ones it finds on a URL.
How do I check what WAF or bot protection a site uses?
Paste the URL above and read the verdict. To confirm it yourself, open DevTools → Network → the document request and look at the response headers (server, cf-ray, x-datadome, x-iinfo, x-amzn-waf-action, x-sucuri-id), the cookies set on the first response (_px3, datadome, _abck, __cf_bm, aws-waf-token) and any challenge page or sensor script.
How do you identify the vendor?
From the response itself: headers, the cookies the site sets, the challenge or sensor scripts it loads and any challenge interstitial. The report lists the exact indicators, so you can verify every claim instead of trusting a label.
How can I tell if a site uses Cloudflare Bot Management?
server: cloudflare and cf-ray only mean Cloudflare is the CDN in front of the site. Bot management is when the response also sets __cf_bm or cf_clearance, or when a plain request gets HTTP 403 with a “Just a moment” / cdn-cgi/challenge-platform page. This check separates those three cases and only calls the last one a challenge.
Why does it say Cloudflare when my browser opens the site normally?
Our request comes from a datacenter IP with no cookies or history — exactly what bot protection is designed to challenge. A challenge served to us and not to you is a finding, not a false positive: it proves the protection is enforcing. The report shows the HTTP status so you can tell an edge-only header from a real challenge page.
Does bot protection affect normal browsing?
Usually not. A real browser with normal navigation, cookies and a residential IP scores well and never sees a challenge. Repeated challenges mean the session looks synthetic: a hosting IP, a fingerprint that contradicts itself, a user-agent that disagrees with the platform, or automation flags.
What do the confidence levels mean?
High means a vendor-specific signal that cannot be coincidental — a challenge header, a vendor cookie or a vendor sensor script. Medium means the vendor is present but was not observed blocking this request (common for CDNs). Low means a single weak hint that is worth checking by hand.
Does the site know it was checked?
Yes — the tool makes one normal page request from our server, like any monitoring or SEO service. It does not log in, submit forms, solve challenges or attack anything. Only the report is stored (30 days, for share links); the raw response is never kept.