In takeaways from State of Web Access 2026 - Zyte's extensive analysis of access control methods in place on the web's most popular sites - individual technology methods may get most of the attention.
The WAF adoption headline, the CAPTCHA percentage, the antibot vendor landscape - for sure, each barrier has a story. But the more operationally significant question for anyone trying to access web data at scale is not whether a site runs any given barrier, but how many it runs simultaneously, and which combinations appear together.
Barrier stacking - the practice of layering multiple access controls - is where individual mechanisms become a coordinated defence posture. And the State of Web Access 2026 data shows that stacking is now the majority condition on the web.
Three kinds of site: open, default-defended, fortified
The 11,100 sites in our dataset divide into three meaningfully distinct populations.
18.5% deploy no detectable barriers at all. These are the genuinely open sites - concentrated in static content, public sector, agriculture, and information-first sectors where crawl access aligns with the site's distribution goals rather than cutting against them. Open access here is a feature, not an oversight.
30.7% deploy exactly one barrier. This sounds like a deliberate, minimal posture - but the composition of this group reveals it is almost entirely WAF-only sites. A single WAF that arrived bundled with a CDN is the accidental baseline of modern web infrastructure, not a strategic access-control decision. Most of the "one barrier" sites have not chosen a defence; they have inherited one.
50.8% deploy two or more barriers. This is the majority of the web's defended sites - operators who have gone beyond the default, either deliberately or through accumulated configuration choices. Within this group, 12.1% run three barriers, 5.4% run four, 7.4% run five, and 0.8% run all six simultaneously.
WAF as the only barrier that operates alone
The standalone usage data is one of the clearest signals in the entire dataset.
33.4% of WAF-protected sites use the WAF and nothing else. That is the only barrier category where standalone deployment is common. Every other barrier tells the opposite story:
- TLS fingerprinting operates alone on just 7.9% of TLS sites
- JavaScript alone: 0.6%
- Rate limiting alone: 0.2%
- CAPTCHA alone: 0.1%
- Antibot alone: 0.0%
The pattern is unambiguous. Every barrier except WAF is an architectural addition - something deployed on top of an existing foundation, not in place of one.
Sites that buy antibot already have a WAF., sites that implement rate limiting already have a WAF. The WAF is the substrate; everything else is layers.
This has a practical diagnostic corollary: finding any barrier other than WAF on a site is strong evidence you are dealing with a layered environment, not a single-mechanism deployment.
The dominant combinations
The top barrier combinations in the dataset tell the access story more precisely than any individual adoption rate.
The three most common outcomes - WAF-only (30.8%), WAF and JavaScript (20.4%), and no barriers at all (18.5%) - together account for nearly 70% of all landing pages.
For anyone building a data pipeline, this is the practical implication: a setup that handles WAF and JavaScript rendering covers the vast majority of what exists on the web.
The WAF and JavaScript combo deserves a specific note. At 20.4%, it is the single most common active-defence combination in the dataset - and yet, JavaScript as a barrier is largely accidental. Almost none of these sites chose JavaScript rendering as a security layer; they are built on React, Next.js, or other SPA frameworks whose architecture happens to be invisible to plain HTTP clients. The "stacking" of WAF and JavaScript in these cases reflects two unrelated decisions converging: a CDN choice and a frontend framework choice.
The combinations that follow in the ranking are meaningfully different in character:
- WAF + CAPTCHA (6.5%) - a deliberate second layer for user-facing verification
- WAF + CAPTCHA + JavaScript (4.4%) - three mechanisms, one accidental
- WAF + JavaScript + Rate Limiting (4.1%) - rate limiting signals commercial data defense
- WAF + Antibot + CAPTCHA + Rate Limiting + TLS (3.3%) - the near-full stack
Defence in depth
The 3.3% running five simultaneous barriers is worth examining specifically. That is unlikely to be configuration drift - it looks more like deliberate security architecture.
The concept of defence in depth originates in military strategy: rather than relying on a single fortification, layer multiple independent barriers so that a breach of any one does not compromise the whole.
The same logic applies to web access control. Each barrier addresses different failure modes:
- TLS fingerprinting catches automated clients at the connection layer before any HTTP request
- WAF filters at the HTTP layer, blocking known attack signatures and rate patterns
- JavaScript rendering requirements expose clients that cannot execute browser code
- CAPTCHA and antibot challenge clients that have reached the application layer
- Rate limiting applies a quota-based final check on request frequency
A sophisticated operator who has thought about each of these layers independently will likely end up deploying most of them - not because any single layer is impenetrable, but because the attacker who defeats TLS fingerprinting still faces WAF, and the attacker who defeats WAF still faces antibot, and so on. The cost of defeating a five-layer stack is qualitatively different from defeating any one mechanism.
The 0.8% running all six barriers simultaneously are the extreme expression of this logic: sites where the commercial value of the protected data is high enough that the operational cost of maintaining a full stack is justified.
What stacking tells you
The stacking picture has a direct diagnostic implication for any system navigating web access.
The individual co-occurrence data across the barrier reports confirms this: rate-limited sites run TLS fingerprinting at 49% versus 3.9% elsewhere; antibot sites run rate limiting at 61.5% versus 13.2% elsewhere.
Finding one of the intentional barriers - rate limiting, antibot, TLS fingerprinting - is not so much a signal about that barrier; it is a signal about the whole environment. For example:
- A site running antibot has almost certainly also deployed WAF, rate limiting, and CAPTCHA.
- A site running rate limiting is running TLS fingerprinting at 12 times the rate of other sites.
The barriers travel together because the decision to invest in access control tends to be holistic, not piecemeal.
The practical read: when you encounter any barrier beyond a default WAF, the right question is not "how do I handle this barrier?" but "how many layers am I actually dealing with here?"
The answer, more often than not, is "several".
