A driver's license establishes who someone is and that they passed a test — not that they will drive responsibly later. Verified bots work the same way: identity is a starting point, and trust depends on subsequent behavior. A bot that has proven who operates it can still overload origins, ignore site preferences, or attempt to evade controls. Not every deviation is malicious; misconfigurations and bugs are common causes.
Cloudflare's verification model asks two questions: "Are you who you say you are?" and "Can we trust you?" Earning Verified Bot status broadly requires meeting three criteria:
- Identify yourself accurately and securely
- Do only what you say you will do
- Don't engage in abusive behavior
Bots sign requests with Web Bot Auth to establish identity, and BotBase catalogues that identity in an open format. With the first criterion handled, the remaining question is behavioral: whether an identified bot lives up to the second.
Risk, trust, and what changes when behavior slips
The distinction matters. Risk describes the likelihood that a specific request or point-in-time action may be harmful, and it shifts from moment to moment. Trust accumulates over time through repeated, consistent behavior. Cloudflare is introducing a system to evaluate and report when a Verified bot's behavior deviates from the no-harm rule, so that the answer to "Can we trust you?" stays positive rather than being assumed from identity.
There is precedent for revoking that answer. In 2025 Cloudflare removed Perplexity's bot from its Verified list after it accessed resources on sites that had opted out of scraping and then attempted to circumvent the controls blocking those requests.
Measuring respect for site preferences
"Do not engage in abusive behavior" sounds straightforward, but the details carry weight. Crawlers that ignore site preferences erode trust; crawlers that continue at the same rate when asked to slow down do the same. Cloudflare has built a system to measure how consistently a crawler honors those preferences. The output is an explainable trust band — a range describing how reliably a bot respects site preferences, along with the observed behaviors behind the assessment. It is not a permanent verdict on a bot or its operator.
Two signals are evaluated initially:
- Does the bot respect instructions?
- Did it respond to direct feedback?
These are treated as common-sense rules — a courtesy to the operators who publish the information bots are seeking. Cloudflare says it will share these scores publicly on Radar in the future and will expand the measurement methods over time. The score gives responsible operators a way to show that trust is being maintained rather than merely claimed.
Honoring published rules
Robots.txt is the primary channel for site owner preferences, and the system checks whether a bot's observed traffic stays consistent with those published rules over time. Isolated violations and one-off events may not be meaningful on their own; the focus is on repeated patterns of disregarding site preferences. Responsible bots are expected to consult and honor published preferences in line with RFC 9309.
Robots.txt sets a floor, not a ceiling. Nothing unstated in a robots.txt should be read as permitted, and the file does not have to spell out that a bot must stop when a site communicates through other signals that continued access is unwelcome.
Reacting to backpressure
A bot can stay entirely within allowed paths and still place substantial load on a site. An HTTP 429 ("Too Many Requests") response is one of the clearest ways a site pushes back, directing the visitor to reduce its request rate and sometimes indicating how long to wait before retrying. The system watches whether traffic adapts after that signal — slowing down or pausing — or whether it continues at the same pace. That behavior feeds into the trust band over time: consistent adaptation raises trust, and repeated disregard lowers it.
Where this fits
Observing these signals is a first step toward holding verified automation accountable over time, pairing identity with evidence of continuing behavior. That serves site owners deciding which bots to allow, operators wanting to demonstrate they deserve trust, and anyone who needs context about the automated traffic reaching them.
Alongside Bot Preference Sync and Bot Management, the system forms an accountability loop for automated traffic. Bot Preference Sync lets site owners publish their preferences; observing how bots interact with those preferences reveals whether Verified bots consistently honor them; Bot Management lets site owners decide how that traffic is handled. The intent is that trust comes from sustained, transparent behavior rather than being granted by identity.
Cloudflare is already using the system internally to evaluate how consistently Verified bots honor website preferences, assessing sustained patterns rather than isolated events and using this phase to build history and refine how observations translate into guidance. It plans to make the system available to all Cloudflare customers, who will be able to choose the trust threshold that determines how Verified bot traffic is handled. The stated goal is to keep website preferences meaningful and to ensure trust is earned through behavior over time.
Cloudflare customers can already use Bot Management to manage automated traffic and Bot Preference Sync to align published preferences with configured policies. Verified bot trends are available on Radar.
