Stop asking how hard a site is to scrape. Ask who runs its front door. A target’s difficulty doesn’t emerge from the site itself. It comes down to a purchasing decision the site made, and the vendor it bought determines almost everything about what you’ll face. Sites on the same tier behave the same way. Sites on different tiers fail you for entirely different reasons. Get the vendor right and the rest is legwork.
The mental model: difficulty is bought, not built
Most site owners do not write bot detection. They install it. When you fingerprint the front door of a serious e-commerce, ticketing or airline target, you are almost never fighting bespoke logic. You are fighting a managed product from one of maybe eight vendors, deployed with default-to-moderate tuning. The failure modes cluster by vendor as a result. Nike, adidas, Best Buy and most airlines feel identical to automate because they all run Akamai Bot Manager. Vinted, Leboncoin and Hermès feel identical because they all run DataDome. Once you know the stack, you know the shape of the wall.
This is the single most-repeated first-hand view across r/webscraping and BlackHatWorld:
The difficulty was never the website. It’s the vendor. Same-tier sites behave the same and the top tier, Kasada and Akamai, is where DIY setups go to die.
There’s a corollary that matters most for anyone spoofing a browser fingerprint. The hardest walls are network-and-behavior first. A perfect Canvas/WebGL/Audio spoof that sails through CreepJS does nothing against a stack that has already scored your TLS handshake, your request cadence and a cryptographic proof-of-work before any fingerprint JS even runs. Passing a test surface is not passing a production wall.
The ladder
Independent sources broadly agree on the ordering: vendor-published bypass rates (inverted, since lower means harder), community difficulty rankings and academic block-rate measurements. Absolute positions shift with tuning and time, yet the tiers are stable.
| Tier | Vendor stack | Core detection layer | Signature artifacts |
|---|---|---|---|
| 1 | Kasada | Client-side cryptographic proof-of-work computed per request, on real CPU | x-kpsdk-cd / x-kpsdk-ct; bare HTTP/2 429 with no body, no challenge page; tokens renewed ~every minute |
| 1 to 2 | Akamai Bot Manager | sensor_data, ~512 KB obfuscated JS collecting 100+ signals, encrypted and posted back |
Stateful _abck cookie (~-1~ = not cleared); bm_sz, ak_bmsc; SBSD challenge |
| 2 to 3 | DataDome | Behavioral profiling from the first request + per-customer ML model + JA4 | datadome cookie bound to IP; x-datadome, x-datadome-cid response headers; 403 with JSON challenge |
| 3 | Cloudflare Enterprise Bot Management | TLS JA3/JA4 + HTTP/2 fingerprint + Canvas/WebGL + ML bot score | cf_clearance, __cf_bm, CF-RAY; Turnstile / managed challenge |
| 4 | PerimeterX / HUMAN | Behavioral biometrics ML, mouse, scroll, keystroke dynamics | _px3 token (~60 s TTL); “Press & Hold” CAPTCHA |
| 4 | Imperva / Incapsula | reese84 server-signed token whose encoder morphs on every refresh |
reese84 cookie; incap_ses_*, visid_incap_*; added JA4 signals in 2024 |
| 5 | Cloudflare Free / hCaptcha / AWS WAF / reCAPTCHA v2 | Static challenge, IP reputation, coarse fingerprint | cf_clearance; visible checkbox/image CAPTCHA |
A note on the ordering evidence, all of it hedged. Vendor self-reported bypass rates (Scrapfly’s series) rank Kasada hardest by putting its claimed bypass rate lowest (~94%) and Cloudflare’s highest (~98%). Community comparison boards through 2026 rank Kasada > Akamai > DataDome > PerimeterX > Imperva. The independent academic dataset (Bamberg, below) measures the highest actual block rates for Cloudflare (~37%) and Akamai (~26%). Three different lenses, then: self-report, discussion heat and measured blocking. They agree on the tiers even where they disagree on exact numbers.
Tier 1: Kasada and Akamai, where DIY dies
Kasada sits at the top of the ladder because it makes the client pay. Its script forces the browser to compute a real cryptographic proof-of-work on the CPU, emitting a freshly-computed x-kpsdk-cd value per request, with tokens renewed roughly every minute. You cannot replay a token. You cannot cheaply mint one. There is no headless shortcut, because the PoW has to actually execute in an environment that produces the right signals. Its most recognizable behavior is what it doesn’t send back: a bare 429 with no challenge page and no body.
HTTP/2 429
x-kpsdk-ct: <token>
content-length: 0
No CAPTCHA, no “prove you’re human” page, nothing to solve. Just a wall. Kasada is widely described in the community as “not viable to reproduce in DIY production.” Its named clients include Wizz Air, Vercel, Hyatt and Canada Goose.
Akamai Bot Manager sits alongside it. Its detection layer is sensor_data: roughly half a megabyte of heavily obfuscated JavaScript per page that harvests 100+ device and behavioral signals, encrypts them and posts them back. The stateful piece is the _abck cookie. Its value carries whether the session has been “cleared,” and the tell every Akamai reverse-engineer learns first is the ~-1~ segment, which means the sensor has not cleared you.
_abck=7A3B...~-1~||-1||...~-1~...
A _abck that still contains ~-1~ after your sensor POST means your payload was rejected; subsequent XHRs come back 403 with no body. One airline-scraping dev put the whole failure mode succinctly: “_abck is the key… works on my machine, dies on the VPS.” A datacenter IP is itself one of the strongest signals feeding the model. Akamai’s named clients span Nike/SNKRS, adidas, Best Buy, Zalando, The Washington Post, Japan Airlines and most major airlines.
Two attributions worth correcting here, because they circulate wrong. Zalando is Akamai, not DataDome, and its public product catalog is soft (basic Scrapy with adjusted headers works) while login/checkout is the hard wall. And Ryanair is Cloudflare, not PerimeterX.
Tier 2 to 3: DataDome, behavioral from request zero
DataDome does not wait for a fingerprint. It builds a behavioral profile from the very first request, feeds it into a per-customer ML model and layers JA4 on top. The state lives in a datadome cookie that is bound to the IP that obtained it. Move the cookie to another IP and it’s worthless. The verdict shows up in x-datadome response headers.
set-cookie: datadome=<opaque>; Domain=.example.com; SameSite=Lax
x-datadome: protected
x-datadome-cid: <client-id>
The first-hand failure logs show how fast the model converges. One developer scraping Vinted reported plain requests “died in 18 seconds,” residential proxy plus a real UA “died in 4 minutes,” and Playwright with a spoofed JA3 “died after 80 requests.” Each layer of spoofing buys seconds-to-requests, not immunity, and that escalation curve is the DataDome signature. Named clients include Vinted, Leboncoin, Hermès, Footlocker (which migrated to a Fastly + DataDome stack) and Reddit.
Tier 4: PerimeterX/HUMAN and Imperva
PerimeterX / HUMAN leans on behavioral biometrics (mouse movement, scroll dynamics, keystroke timing) fed into an ML model, gated by the short-lived _px3 token (~60 s TTL) and the familiar “Press & Hold” CAPTCHA.
The instructive community observation: on a PerimeterX target you “can pass everything else and still get blocked by mouse-movement ML alone.” Named clients include StockX, LinkedIn and Walmart.
Imperva / Incapsula is defined by the reese84 token, a server-signed value whose encoder morphs on every refresh, so you need a real browser to execute the current variant; a static solver breaks the moment the encoding rotates. Imperva added JA4 signals in 2024. The attribution to nail down: reese84 is Imperva, not F5/Shape. People confuse these two constantly. F5/Shape uses TS* cookies and a custom JS virtual machine with randomized opcodes rebuilt per deployment, a different vendor with a different artifact. The canonical reference for the reese84 internals is the HyperSolutions Incapsula docs.
Below these sit the interactive and score-based layers: reCAPTCHA v3/Enterprise (an invisible 0 to 1 behavioral score plus fingerprint and Google cookie, heavily weighting IP reputation and action consistency) and Arkose/FunCaptcha (interactive 3D rotate/match puzzles with 1250+ variants, backed by behavioral risk scoring).
Reading the front door
You can usually identify the stack before writing a line of automation, straight from cookies and headers. A fast field cheat-sheet:
_abck=...~-1~... -> Akamai Bot Manager (uncleared)
datadome=... + x-datadome: -> DataDome
x-kpsdk-cd / bare 429 -> Kasada
reese84=... + incap_ses_* -> Imperva / Incapsula
cf_clearance / __cf_bm / CF-RAY -> Cloudflare
_px3=... -> PerimeterX / HUMAN
TS<hex>=... -> F5 / Shape
Tooling that automates this mapping exists. is-antibot covers 20+ vendors, and Scrapfly and Proxies.sx both publish antibot scanners. But the cookie/header signatures above are enough to place any target on the ladder by hand.
The quantitative landscape: most walls are asleep
Two independent scans of the Tranco Top 1M in 2026 give the macro picture. They agree on the shape while differing on exact percentages by method.
Crawlora’s Anti-Bot Adoption Index scanned ~998k sites, 818k reachable. Of those reachable sites, ~53.5% run some managed anti-bot or WAF, but only ~9.8% actually challenge an ordinary request. The rest are configured but passive. As the community shorthand goes, most walls are asleep. Cloudflare dominates at ~45% of reachable sites (84% of all protected sites); dedicated Enterprise Bot Management is only ~0.8% (~6,888 sites). Protection rises with rank depth: Top 1k sits at 44.2% protected, the 100k to 1M band at 53.6%. The head of the web is less defended than the long tail.
The academic dataset, Bamberg’s Detecting Bot Detection (arXiv:2606.14525, ARES 2026), corroborates the tiering with measured block rates. Cloudflare presence climbs from 14.5% of the Top 1k to 37.6% of the Top 1M. Measured block rates are highest for Cloudflare (~37%) and Akamai (~26%), with the paper concluding bluntly that “blocking is provider-driven.” Its most useful figure for target selection:
Enterprise bot-management is under 1% of the web overall but roughly 15.5% among high-value, actually-scraped sites.
That single gap explains the whole subjective experience of “every serious target has a hard wall.” It’s a selection effect. The web at large is mostly undefended, while the sites worth scraping (the ones with inventory, pricing or accounts worth money) are exactly the ones that bought Tier 1 to 4 protection. You are not unlucky. You are self-selecting into the 15.5%.
Bamberg also quantifies how much of the fight happens below the fingerprint layer: 75% of Chromium-headless blocks can be triggered on HTTP-header signals alone, 46% of sites probe at least one automation-only JS property and 34% check navigator.webdriver. Much of detection is decided before your carefully-spoofed Canvas hash is ever read.
Takeaway
Profile the vendor before you profile the browser. Pull the cookies and headers, place the target on the ladder and let the tier tell you where to spend effort. On Tier 1 (Kasada, Akamai) a fingerprint spoof alone is wasted motion; the fight is network-layer TLS/HTTP2 and behavioral, and DIY largely doesn’t survive there. On Tiers 3 to 5 a consistent fingerprint plus decent residential proxies gets you a long way. And keep the macro shape in mind: most walls are asleep, but the ones guarding anything worth taking are wide awake. The site isn’t being clever. You’re up against the check it wrote to a vendor.