Cloudflare's September 15 flip: what our rescan measured

AgentReady at agentready.market, operated by Villepinte Studio — the e-commerce transaction audit. Unaffiliated with other AgentReady-named products.

On September 15, 2026 Cloudflare changes its default rules for AI traffic: the Agent and Training classes are blocked by default on ad-carrying pages of newly onboarded domains, and existing zones that had the legacy “Block AI Bots” switch on are migrated to Agent: Block on pages with ads. (This paragraph originally added that the legacy switch would start catching Googlebot; Cloudflare’s customer notice of September 15 says it will not, see the amendment below.) We took the announcement apart in Cloudflare’s September 15 AI defaults: what merchants must check. This page is the other half: what actually happened to real stores, measured before and after, with the protocol written down before the data exists.

The protocol, fixed on September 4

We are writing this on September 4, eleven days before the switch, so the method cannot bend to the result.

• Population. Every store in our audit corpus whose most recent pre-flip scan recorded a Cloudflare response header (cf-ray or Server: cloudflare). That flag is a header fact the engine stores on every scan; it is not inferred.
• Baseline. That most recent pre-flip scan, taken any day before September 15.
• Measurement. From the morning of September 16, each store is re-audited once, in batches of forty per day until the population is exhausted. One pair per store: a before/after comparison, not a time series.
• Outcome. The change in the audit’s Access pillar — the share of the access checks a shopping agent passes (robots policy for the agent class, WAF posture, crawlability, parity between what bots and humans receive). We also record whether the store became unbuyable (the audit’s “capped” state: an agent is stopped before it sees a single product).
• What we will report. The count of stores measured, how many lost access points, how many became unbuyable, how many gained, how many were unchanged, and the ten largest losses by name. The table below is generated from the database at every page load. No number on this page is typed by a person.
• What would falsify the worry. If fewer than one store in ten loses access points, the September 15 defaults are a non-event for existing stores and we will say so in this same paragraph’s live block. Newly onboarded domains, which the announcement targets first, are outside this population by construction: our corpus only holds stores that existed before the flip.

Protocol amendment, September 16

Written the morning after the switch, before any pair had been read, on the strength of one new primary source: the customer notice Cloudflare emailed its account holders on September 15 (“Updates to managing AI crawlers on your account”, signed by its Director of Product Security). Three facts in it change the protocol above; the population, the baseline, the outcome and the falsification rule do not move.

• The migration is not a single-day switch. The notice says the settings of existing zones are migrated “over the coming week” and that the migration is complete when the old “Block AI Bots” switch disappears from the dashboard. A rescan taken on the morning of September 16 can therefore predate the change it is meant to measure. The measurement now starts on September 23, one week after the original date. The pairs the job took on September 16 under the original protocol are kept in the log, held out of every count on this page, and each of those stores is re-measured once after September 23 against the same pre-flip baseline. One final pair per store, as before.
• Existing stores are affected after all, on one condition. Zones that had “Block AI Bots” enabled are migrated to Search: Allow, Training: Disallow AI Training, Agent: Block on pages with ads. Zones that never touched the setting stay on Allow. This is the mechanism this study can now actually observe among existing stores, which the original protocol expected to be untouched.
• The Googlebot side is withdrawn. The recommended Training setting moves from Block to “Disallow AI Training”, which the notice says lets Googlebot, Applebot and Bingbot keep indexing. The “legacy switch starts catching Googlebot” warning in our August 17 article and repeated above no longer describes what Cloudflare shipped; the correction is logged on that article.

One expectation to write down now rather than after: the Agent block applies “on pages with ads”, and most product pages carry none. The falsification rule above (fewer than one store in ten losing access points) is therefore the likelier outcome, and if the table says so, that is the finding.

The measurement, live

The pairs come from cloudflare_flip, a scheduled job in the same audit engine that produces every score on this site. The Access pillar is one of four; the full method is on the methodology page.

What a merchant behind Cloudflare should do this week

The settings, not a rebuild. Two minutes in the Cloudflare dashboard decide which side of the default a store is on:

1. Security → Bots → AI traffic. Check the per-class rules. If the Agent class reads “block”, shopping agents cannot load the store, whatever the product data says.
2. Replace the single “Block AI Bots” toggle where it is still on. Since September 15 Cloudflare migrates it to per-class rules, with the Agent class blocked on pages that show ads; set that class yourself rather than inheriting the default. (An earlier version of this step said the switch would also catch Googlebot; Cloudflare’s September 15 notice says the migrated Training setting keeps Googlebot indexing.)
3. Re-run the free scan afterwards. The Access pillar on the report shows whether the agent class gets through, and the report page keeps the before/after for you.

For the wider comparison between Cloudflare’s own agent-readiness score and a transaction audit, see Cloudflare’s agent readiness score vs AgentReady.

FAQ

Does Cloudflare block AI shopping agents by default?

From September 15, 2026, on ad-carrying pages of newly onboarded domains, yes: the Agent traffic class is blocked unless the operator changes the setting. Existing domains that never configured AI-bot settings keep Allow; existing domains that had “Block AI Bots” on are migrated, over the week that follows, to Agent: Block on pages with ads (per Cloudflare’s September 15 customer notice). That migration is what this study measures on existing stores.

How do I know whether my store is behind Cloudflare?

The audit records it from the response headers. Run the free scan; the Access pillar of the report says whether Cloudflare fronts the site and whether the agent class gets through.

Why publish the protocol before the numbers?

So the method cannot be adjusted to fit a result. The count, the pillar and the cutoff dates were fixed on September 4; the one amendment (the start moved from September 16 to September 23, dated September 16) was written before any pair was read and is printed above. The table fills itself from the database from September 23 and is never edited by hand.

Sources

• Cloudflare Blog — “Your site, your rules: new AI traffic options for all customers” (fetched August 17, 2026, quoted in our September 15 defaults article)
• Cloudflare Blog — “Giving users choice with Cloudflare’s new Content Signals Policy” (fetched August 17, 2026)
• Cloudflare customer notice, “Updates to managing AI crawlers on your account”, emailed to account holders on September 15, 2026 and signed by Bryan Becker, Director, Product Security (received by Villepinte Studio’s Cloudflare account September 16, 2026; not published as a web page, quoted from the copy we hold)
• The AgentReady audit corpus: pre-flip scans stored by the engine with the Cloudflare header fact, and the post-flip rescans produced by the cloudflare_flip job from September 23, 2026 (amended from September 16, see above). Both are first-party data; the table on this page reads them directly.