The system evaluates repeated respect for crawling preferences and rate-limit signals, beyond verifying identity.
PPC Land reports that on 16 October Cloudflare published “Continuous accountability for Verified bots,” describing a system already running inside the company that checks whether bots it has approved keep behaving. It watches two things: whether a bot’s traffic is consistent with a site’s published robots.txt preferences over time, and whether it slows down or pauses after an HTTP 429 “Too Many Requests” response. The output is a “trust band,” a range showing how consistently a bot respects site preferences, which Cloudflare plans to publish on Radar and later let customers use as a threshold for how Verified bot traffic is handled.
Cloudflare says one-off violations are not significant; it looks for repeated patterns, and that bots that respond appropriately gain trust, while persistent disregard reduces it. PPC Land notes the post does not say how many bands exist, how long the observation window is or how many violations move a bot down, and that it is not yet a customer feature. The precedent is Cloudflare’s 2025 removal of Perplexity’s bot from the Verified list.
In plain English
A “Verified bot” is a crawler Cloudflare has approved. “robots.txt” is a file where a site says what bots may fetch. HTTP 429 is the status code meaning “slow down.” A “trust band” is a range showing how reliably a bot follows those rules.
Why it matters
Analytics, ad-fraud and AI-visibility reports often treat “verified” as “safe.” This separates who a bot is from how it behaves, which matters when AI crawlers inflate traffic or server load.
Identity and behavior answer different questions. Knowing which company operates a crawler helps establish accountability, but it does not show that the crawler will respect a particular website's preferences. A continuing behavior assessment could make that distinction more visible to site operators.
The two signals described in the announcement are concrete. A robots.txt file expresses crawling preferences, while a 429 response tells a requester that it is sending too much traffic. Observing a bot over time can reveal whether it repeatedly ignores those signals or adjusts its behavior.
For a website owner, this should be understood as another input to access decisions. It is not proof that every request from a well-rated bot is appropriate for every page. Public content, account pages and expensive endpoints can still require different handling.
The rollout status matters as well. An internal evaluation system, a public rating and a customer control are separate stages. The announcement does not mean a site can already configure all of the promised behavior. Before relying on a future rating, operators will need to understand the observation period, rating changes and how exceptions are handled. The proposed approach is useful because it makes repeated conduct part of the discussion, rather than treating initial verification as permanent trust.