Cloudflare will score whether Verified bots obey robots.txt and 429s, with customer-set trust thresholds
In a blog post dated October 16, 2026, Cloudflare introduced a system that continuously measures how well Verified bots respect site preferences. It already runs internally. Rolling it out to customers, publishing scores on Radar and letting customers choose the threshold are listed as plans.
A bot with a verified identity can still ignore the rules, and Cloudflare wants to measure that
Cloudflare starts from a simple gap: confirming who a bot is makes it accountable, yet it does not guarantee good behavior. A known bot can still brush aside site preferences, overload an origin server or slip past controls, and the post says this often traces back to misconfiguration or bugs rather than bad intent. The company wants to be able to tell sites over time that yes, the bot can be trusted.
To get there, Cloudflare built an evaluation system that tracks how often Verified bots follow site preferences. The post says the system is already in internal use, and that Cloudflare is using this initial phase to build up a history and refine how the observations turn into useful guidance. The post sums up its approach in a short line: "Verify, but continuously re-verify."
The first signals are robots.txt and HTTP 429, and the output is a "trust band"
Verified status has three requirements: the bot identifies itself accurately and securely, does only what it says it will do, and avoids abusive behavior. On the identity side, bots sign their requests with Web Bot Auth, and BotBase catalogs them in an open format. The new system adds a behavior layer on top, starting with two kinds of signal: whether a bot follows site instructions and how it reacts to direct feedback.
For instructions, the main reference is robots.txt (RFC 9309). The system looks at repeated patterns of disregard over time rather than a single violation, and the post stresses that robots.txt sets minimum rules and does not imply that anything unstated is allowed. For feedback, there is HTTP 429 (Too Many Requests): a bot that slows down or pauses after one earns trust, while a bot that keeps ignoring the signal loses it. Results will be expressed as an explainable trust band showing how consistently a bot respects preferences and which observations shaped that view. It is not meant as a permanent verdict. Cloudflare describes trust as something earned across time: "Trust is built over time through repeated and consistent behavior."
What exists today and what is only planned are different things
According to the post, what exists today is internal use. The planned items are publishing scores publicly on Radar, widening the behaviors that get measured, and offering the system to all Cloudflare customers. Customers are also expected to choose the trust threshold that decides how Verified bot traffic is handled. In other words, the post does not describe a score dashboard or a threshold setting that site owners can use right now. The system is presented as one part of an accountability loop that works alongside Bot Preference Sync, where sites publish their preferences, and Bot Management, where sites decide how traffic is handled.
The post also gives a precedent for why behavior needs measuring: in 2025 Cloudflare removed Perplexity's bot from its Verified bot list after it sought to access resources on sites that had opted out of scraping and then tried to get around controls once those requests were blocked. Allowing or refusing AI crawlers is now a visibility and cost decision for site owners, so a measure of whether a bot keeps its word could help make that decision with data rather than guesswork. That sentence is our own reading, not a claim from the post. For our earlier coverage of Cloudflare and bot traffic, see the October 15 issue.
The post says nothing about Türkiye, so this section is UNALSOFT commentary
The Cloudflare post contains no information about Türkiye, bots operating there or local customers. What follows is not a fact drawn from the source but UNALSOFT's own reading. For small and mid-sized sites in Türkiye that use Cloudflare, the valuable part would be choosing the threshold themselves, but that only holds if the feature actually reaches customers.
The unknowns, one by one. The post does not give: a general availability date for customers, trust band thresholds or numeric scores, or a date for scores to appear on Radar.
UNALSOFT's take
We read this as a bot policy question for site owners. Deciding which crawler gets through the door starts with a robots.txt that is current and clear; however advanced the measurement becomes, what a bot is supposed to follow begins with the site's own instructions. The practical steps are plain: review your robots.txt, choose deliberately which bots you allow, and make sure your server returns signals such as 429 correctly. In our web design projects we treat this technical groundwork as a core part of the site. Because the source carries nothing about Türkiye, we claim no local facts.
Sources
Do you know what your site tells bots?
A short conversation is enough to review your robots.txt and your server responses together.