On September 7, 2026, researchers from CipherCue published a measurement that everyone involved in European web automation should read: out of 44,143 European companies where a CDN was detected, 89.6% are behind Cloudflare. Not "the market leader by a wide margin" — but almost the entire market as a whole. For scraping, multi-accounting, and any automation, this means one simple thing: access to nine out of ten sites in the EU is governed by the same algorithm, based on the same criteria, at the same moment.
What Exactly Was Measured
The sample consisted of companies from Germany, the UK, the Netherlands, Poland, France, Italy, Spain, and Ireland that had at least one CDN component identified on their website. Detection was performed through HTTP responses and server fingerprints: the cf-ray header and server: cloudflare for Cloudflare, x-served-by with a cache marker for Fastly, x-amz-cf-id for CloudFront. The observation date was September 7, 2026.
Provider breakdown:
- Cloudflare — 39,547 companies (89.6%)
- Amazon CloudFront — 3,112
- Fastly — 1,299
- Akamai — 396
The distribution by country shows a noticeable variation, but the ceiling is high everywhere:
- Netherlands — 95.6% (7,587 out of 7,939)
- United Kingdom — 93.2% (15,846 out of 17,007)
- Poland — 92.6% (2,682 out of 2,896)
- France — 86.2% (3,456 out of 4,008)
- Italy — 85.4% (3,126 out of 3,661)
- Germany — 81.4% (4,650 out of 5,715)
- Spain and Ireland — 78.8% each
The authors themselves note the limitations, and this is fair: one company could be counted under multiple providers at once (double counting), and the sample is skewed towards small and medium businesses — the segment where Cloudflare's free tier is the strongest. Thus, 89.6% is the share among companies with detected CDN, not among all European legal entities.
There is an independent verification of the order of magnitude: according to W3Techs data as of September 2026, Cloudflare is used by 84.7% of websites that have a known reverse proxy — which is 25.2% of all websites in their index. Different methodologies, different samples, but the conclusion is the same: before a quarter of the web and the overwhelming majority of recognizable CDN installations stands one intermediary.
Why This Is Not Just "Market Share" for Automation
When there are many filters, an error in one fingerprint costs access to one site. When there is essentially one filter, an error costs access to the entire segment at once — and this changes the economics of operation.
Cloudflare assigns a bot score from 1 to 99 to requests: the lower the score, the higher the confidence that automation is in front of the site. The model that calculates this score, according to the company's own description, processes over 46 million HTTP requests per second and takes into account not only your specific request but also global statistics across the entire network: IP reputation, ASN, and address type (data center / residential / mobile), header consistency, TLS fingerprint, and behavioral indicators. The detection is layered — heuristics plus ML, with machine learning accounting for a large portion of the decisions.
The practical implication: your pool and your fingerprint are assessed not by the site, but by the network. If you are flagged on one resource, the reputational signal is already considered in the next request to another. In a world where nine out of ten European websites are on this network, "switching to another target and waiting it out" ceases to be a strategy.
Residential IPs Are No Longer a Guarantee
The old logic of "using a residential address means you pass as a human" runs into the fact that the filter provider has long caught onto this trick. Cloudflare has publicly described a separate model against bots using residential proxies: they initially tried network indicators (excess hops, latency) but abandoned this due to false positives on satellite internet and switched to behavioral analysis — characteristic spikes in activity from IP addresses. Their publication also provides the scale of the phenomenon they observe: around 17 million unique IPs per hour involved in attacks via residential proxies, 45,000 ASNs, and 237 countries and regions (these figures refer to March 2024; the company has not provided more recent data). The claimed accuracy of classifying a distributed attack on one of their clients is 95%, with a 20% increase in bot detection from cloud networks.
An important detail from there: the model is intentionally not built on blocking IPs — to avoid knocking real users out of the same networks. This is good news for legitimate traffic from residential addresses and bad news for those who believe that "home" automatically gives a green light. It is not the type of address that matters, but the combination of "address type + behavior + fingerprint." A detailed analysis of the differences between the walls was made in a comparison of anti-bot systems Cloudflare, DataDome, Akamai, and Kasada — it is worth revisiting with the note that the first line in Europe has become disproportionately large.
The Flip Side: When One Goes Down, All Go Down
Monoculture has a second aspect, not about blocks, but about availability. The last year and a half has provided three illustrative episodes:
- November 18, 2025 — a global outage affecting an estimated one in five web pages and a third of the 10,000 most popular websites and services. The reason, according to the company's own analysis: a change in permissions in the ClickHouse cluster led to duplicate rows in the feature file used by the ML model for scoring bots. Ironically, the mechanism that determines whether you are human or not brought down a significant portion of the internet.
- December 5, 2025 — an outage from 8:47 UTC lasting about 25 minutes, affecting a subset of clients that accounted for around 28% of all HTTP traffic passing through the network.
- February 20, 2026 — at 17:48 UTC, routes were withdrawn via BGP for some clients using BYOIP (Bring Your Own IP ranges) due to a change in the onboarding pipeline for addresses.
The authors of the study are precise here: when one provider dominates a large portion of the market, its mistakes cease to be its problem and become everyone's problem simultaneously. For the data collection pipeline, this means that "the target site is down" and "the entire region is down" are now poorly distinguished — and alerts set for a specific domain become misleading.
What to Do Practically
Below are the changes that actually occur in the workflow if you accept the monoculture of the filter as a given.
- Test the combination on more than one site. If your fingerprint works on three resources, you have likely checked the same filter three times. Include a resource for CloudFront, for Fastly, for Akamai, and one without a CDN at all; otherwise, the sample proves nothing.
- Distribute pools by projects, not by sites. Since reputation is assessed by the network, "a separate pool for each domain" does not isolate anything. Isolation makes sense at the project and profile level: one project — its own pool of addresses, its own set of fingerprints, its own pace.
- Pay attention to the type and origin of the address. ASN and address category are direct entries into scoring. For sensitive purposes, residential proxies and mobile addresses are meaningful; mass technical tasks (availability checks, your APIs, working with platforms without strict anti-bot measures) are cheaper and more honest to close with data center proxies, without wasting expensive traffic unnecessarily.
- Do not burn the subnet. Behavioral models catch spikes in activity on an address. A steady pace across a wide pool performs better in scoring than a short aggressive burst from a narrow one.
- Bring the fingerprint into order as a whole. TLS fingerprint, order and composition of headers, HTTP version, JS behavior — are all assessed together. A residential IP with the fingerprint of a bare HTTP client yields worse results than a neat data center address with a proper browser stack.
- Distinguish between "we were blocked" and "they have an outage." A simple rule: during a mass increase in errors, first check whether everything has gone down at several unrelated targets and what the provider's status page shows. Retrying during a global outage is a way to burn the pool for no reason.
- Have a Plan B for the day the filter goes down. A queue of tasks that can wait and catch up on missed ones is more expensive to develop but can withstand 25 minutes of downtime without data loss.
Conclusion
The figure of 89.6% does not indicate that Cloudflare is bad, nor that the European web has closed off. It signifies that the diversity of targets no longer means diversity of obstacles. One scoring, one model, one reputation database — and, as a consequence, one common mode of failure: both when you are mistaken for a bot and when the provider itself drops routes.
The practical takeaway is dull but actionable: stop optimizing bypasses "for the site" and start optimizing behavior — the quality of addresses, steady pace, consistent fingerprint, and honest failure diagnostics. This is the only thing that works equally well on both sides of 89.6%.