webscrape.dev

Cloudflare put a meter on the web. It only bills the bots that raise their hand.

Cloudflare pay per crawl meters only declared AI crawlers, not the proxied collection most teams run. The web is splitting into two lanes. How to sort targets.

Nathan Kessler

Written by Nathan Kessler

Last updated: 5 min read

On September 15, 2026, Cloudflare flips a default that will change the block rate on a large slice of the web. Any new site, any new domain added by an existing customer, and every site on Cloudflare's free tier will start blocking "mixed-use" crawlers, the Agent and Training bots, on pages that display ads. Most of the coverage reads this as a publisher story: sites finally get paid when AI companies take their words. That part is real. It is also not the question a team collecting web data at scale should be asking. Cloudflare pay per crawl does not put a wall around the web. It puts a meter on one lane of it, and the meter only reads the bots that raise their hand.

What Cloudflare actually shipped

The timeline is short. Cloudflare launched Pay Per Crawl as a private beta on July 1, 2025, and at the same time made new domains block all AI crawlers by default. Publishers on board at launch included Condé Nast, TIME, The Associated Press, The Atlantic, and Fortune. The mechanism is a contract. A declared AI crawler either pays the site's set rate and gets its content, or it receives an HTTP 402 Payment Required and gets nothing.

A year later, on July 1, 2026, Cloudflare announced the next step: Pay Per Use, which bills when content creates value rather than only when a bot fetches a page. It launched with two partners, Ceramic.ai and You.com. The same announcement split bots into three classes, Search, Agent, and Training, and set the September 15 default that blocks the Agent and Training classes on ad-bearing pages while leaving Search allowed. Site owners can also signal intent in robots.txt with use=immediate, use=reference, and use=full. Part of the reasoning is waste: Cloudflare says over 50% of AI crawl traffic re-fetches pages that have not changed.

What does Cloudflare pay per crawl mean for web scraping? It meters only the crawlers that declare themselves as AI bots and authenticate. Undeclared collection, the kind routed through proxies and unblockers, is untouched by the meter. So the web is splitting into two lanes: a paid, authenticated lane with a clean contract, and an undeclared lane where the old block-and-evade dynamic continues as before.

The meter only reads bots that raise their hand

Pay per crawl works by identity. A crawler signs its requests and declares who it is, Cloudflare checks that declaration against the site's rules, and it either bills the crawler or returns a 402. The whole system depends on the bot volunteering its name. Take the name away and there is nothing for the meter to read.

Two lanes, not one wall

That is the part most write-ups skip. Pay per crawl is a contract, not a barrier. A declared crawler gets a 402 or a 200 and knows where it stands. An undeclared client, say a headless browser behind a residential IP that presents as an ordinary visitor, never enters the accounting at all. It runs into the same anti-bot systems it always did, handled by the same web unblocker tooling teams already run. Cloudflare's September default raises the wall for bots that identify themselves. It does nothing to the wall undeclared traffic has been climbing for years. So the choice in front of a data team is not "pay or get blocked." It is which lane to put each target in.

When the toll lane is the cheaper lane

Declaring yourself and paying looks expensive until you price the alternative honestly. Fighting a hardened origin costs real money: unblocker fees, retries, engineering time spent tracking why requests get blocked, and the tail risk that a source you depend on tightens its defenses overnight. For some targets, the toll is the lower number.

A few conditions point toward the paid lane. One is high-value publisher content behind a participating site, where the rate is fixed and delivery is reliable, against an evasion budget that grows every quarter. Another is sources you hit constantly. If you re-fetch the same pages thousands of times a day, a metered, cache-friendly relationship can undercut per-request unblocking, and Cloudflare's own re-fetch number hints at how much of that traffic is redundant. The third, and the one that gets discussed least, is legal exposure. Undeclared collection at scale is where the disputes live. When a proxy vendor and a scraping API end up named in the same complaint, as they did in Reddit's suit over industrial-scale collection, a documented, paid, terms-compliant relationship with the source is a much easier position to defend.

None of this makes the paid lane right by default. It makes it a real option for one class of target: content-heavy, hit often, and legally sensitive. For those, "identify, agree a rate, pay" can be cheaper and calmer than another year of the arms race.

When you stay in the arms-race lane

For most commercial collection, the paid lane does not exist and never will. Pay per crawl covers publisher content on Cloudflare sites that opt in. Marketplaces, search results, travel inventory, pricing pages, and the long tail of non-publisher data are not in the marketplace, have no reason to join, and would not sell you structured access at any price. There is no meter to step into. Collection there stays what it has always been: a managed unblocking endpoint or your own large-scale crawl architecture, priced per successful request and judged on success rate.

The September default still touches this lane, just indirectly. It pushes the free-tier long tail toward blocking Agent and Training bots by default, which nudges the baseline difficulty of anonymous collection upward across a lot of small sites at once, not only the hardened enterprise targets. The effect is spread thin rather than sharp, but it points the same way. Undeclared access keeps getting a little harder, and the tooling to sustain it stays a running cost instead of a solved problem.

What this changes for your stack

The three-layer decision has not gone away. You still choose between a managed scraping API, a proxy network, and a self-hosted framework based on target difficulty, volume, and how much control you need. What is new is a question that sits above that choice.

Before you pick a layer, put each target in a lane. Is this a source where declaring yourself and paying is available and defensible, or one where undeclared, proxied collection is the only path? The answer changes the layer question underneath it. Declared-and-paid targets reward a clean client and good bookkeeping, where the hard part is commercial rather than technical. Proxied targets reward the stack teams already build: strong unblocking, healthy proxy rotation, and the discipline to keep success rates up as defenses shift. Most real pipelines run both. The useful work is deciding which sources belong where instead of forcing every target through one lane.

The signal, not the answer

Pay per crawl matters less for what it prices today than for what it says about direction. The origin side of the web is learning to tell declared bots from anonymous ones and to charge the first group. That does not solve the collection problem, and for most targets it does not touch it. But it adds a real second option for a slice of your sources, and the teams that sort their targets by lane now will be less surprised later.

Share:

Tags:

  • #anti-bot
  • #web-scraping-apis
  • #proxy-networks
  • #market-analysis