Cloudflare URL Scanner Agent Readiness scores
Cloudflare splits Agent Readiness into six scores. They are not generic health checks, and they are not a simple pass or fail. Each one looks at a different part of how a machine-readable web surface behaves.
The six categories are:
- Basic Web Presence
- Discoverability
- Content Accessibility
- Bot Access Control
- Protocol Discovery
- Commerce
That list tells you what Cloudflare is paying attention to: whether a site can be found, whether its content can be reached, whether automated access is blocked or gated, whether the site exposes the right protocol signals, and whether purchase flows can be navigated at all. A site can look fine in a browser and still be awkward for an agent that is trying to identify the right page, follow a path, or complete a transaction without wandering in circles.
The six scores and what each one is actually checking
Basic Web Presence is the bluntest of the lot. It asks whether the site is there in a form that can be scanned and recognised at all. Discoverability is about whether the page can be found through the signals an agent expects to see. Content Accessibility checks whether useful content is available in a form that can be read rather than hidden behind brittle client-side behaviour or awkward page structure.
Bot Access Control looks at the gates. That includes the kind of access controls that may be fine for normal traffic but become a dead end for automated browsing if they are too rigid or badly placed. Protocol Discovery is about the machine-facing signals that tell an agent how to interact with the site. Commerce checks whether buying flows can be navigated without falling apart halfway through checkout.
The important detail is the consequence. If a site fails here, the failure is not theoretical. An agent may miss key information, burn extra requests trying to locate it, or fail to move through the service cleanly. That is a tidy way of saying the site is fine for people but awkward for software that does not guess well.
Reading the report in the Cloudflare dashboard and API
The scores show up in the Cloudflare dashboard after a scan has run. Without that scan, there is no Agent Readiness tab to open, which is a boring but useful boundary. The feature is tied to URL Scanner reports, so the workflow starts with a scan, then the readiness view becomes available for that URL.
Cloudflare also exposes the same data through the URL Scanner API. That matters if the dashboard is only one stop in a larger workflow, or if you want to pull the results into something else without clicking through each report by hand. The output is the same idea in a different shape: a scanned URL, a set of readiness scores, and enough detail to show where machine access is smooth and where it is clumsy.
Where the Agent Readiness tab appears after a scan
In the Cloudflare dashboard, the path is Protect & Connect > Application Security > Investigate. Run a scan first, then open the report and the Agent Readiness tab appears there.
That sequence matters because the tab is not a standing menu item with data waiting behind it. No scan, no report. No report, no score. Cloudflare has kept the feature tied to a concrete URL scan rather than making it look like some abstract site-wide badge.
For practical use, that means a site review starts with a known page or flow, not with a vague idea of the whole domain. That is usually enough to show whether a landing page is legible, whether key content is reachable, and whether checkout or other gated flows are likely to be a nuisance for automated access.
Pulling the same data from the URL Scanner API
The URL Scanner API returns the same readiness data programmatically. That is the useful part if the checks need to sit alongside other security or discovery work, or if a site list is too long to inspect in the dashboard one by one.
The obvious limit is that the API still depends on the scan. It is not magic site intelligence leaking out of thin air. A URL has to be scanned before the scores exist. After that, the API gives you the same categories the dashboard shows, which is enough for comparing pages, tracking changes, or flagging sites that expose poor machine-readable structure.
For a site owner, the scoring is a blunt reminder that machine access now matters in the same way layout and indexing already do. Pages that hide content behind noisy scripts, lock up access too early, or bury commerce steps under brittle navigation are going to look worse here, and they usually deserve that result.
