Public Readiness Scanners

Public scanners answer a narrower question than a repository audit: what can an outside agent observe from the deployed site right now? Use them as smoke tests for crawl access, machine-readable content, discovery documents, public APIs, and callable surfaces. They cannot see an unpublished contract, an authenticated flow they cannot enter, or the source-level reason a check failed.

Scanners named on this page either publish a methodology or check catalog, or are clearly labelled as specialist tools with limited published methodology (Shopify's audit, below). Pair an observed report with a Surface audit, then trace failed signals back to code and deployment configuration. See Evaluating Product Journeys to interpret external findings in terms of a real task, source ownership, applicability, and verified outcomes.

Is AgenticCopy Anchor Link

Is Agentic is a Vercel service powered by Ora. Its Essential checks share an 80-point pool, Recommended checks share 20 points, and emerging signals can add up to five bonus points. Inapplicable surfaces are excluded; API, OAuth, MCP, GraphQL, and MCP Apps checks activate only when detected. The report timestamp and individual evidence matter more than the headline score because both the target and methodology can change.

Its public integration surfaces are deliberately read-only:

• GET https://is-agentic.com/api/v1/report?url=... retrieves the latest completed public report but does not start a scan.
• npx is-agentic <domain> --json returns a stored report or starts a scan when none exists.
• https://is-agentic.com/mcp exposes report, methodology, and developer-documentation tools over remote MCP.
• npx skills add vercel-labs/is-agentic installs its agent skill.

Only submit public URLs. Do not use an external scanner for private, authenticated, pre-release, or confidential environments merely to obtain a score.

Ora / orank scansCopy Anchor Link

Ora - formerly at orank.ai, which now redirects to ora.ai - provides a public score and actionable findings across discovery, access, usability, and payments. Retrieve the cached result with GET https://ora.ai/api/score/example.com, or request a scan with POST https://ora.ai/api/scan and JSON body {"url":"example.com"}. See its API reference for caching and rate limits. That reference also lists journey-run endpoints (such as POST /api/journey/runs) alongside the static scan API, so Ora is not limited to static signals; this guide has not evaluated the journey runs.

Treat each finding as evidence to investigate. A public documentation API benefits from OpenAPI and recoverable JSON errors; it does not need an OAuth authorization server when no protected resources exist. Wikipedia and Wikidata presence depend on independent evidence and eligibility, not configuration. Record the scan date and deployed version before comparing scores.

Ora's checks catalog was at contract 1.38.0 with 132 checks when observed on 2026-10-29. Its August 2026 audit reweighted two of them: ARD catalog discovery (ard-catalog) dropped from 3 to 1 point while ecosystem adoption of the ARD standard is still early, and developer-resource discoverability (agentic-search-specific) dropped from 6 to 3 points because search-result categorization for that check is noisy.

Ora also published AgentReady, a vendor-neutral, MIT-licensed standard for agent readiness, developed together with Vercel, Mintlify, and Auth0 and reaching v1.0 in August 2026; the current specification is v2.0 (October 2026), written by Ora and Vercel. A major version is a breaking change to a normative requirement, so recheck any requirement you cite rather than carrying forward v1 text. Requirements carry stable IDs in three categories - AR-FIND-*, AR-READ-*, AR-ACT-* - each rated MUST, SHOULD, or MAY from traced agent runs and a controlled experiment. The spec deliberately defines no scoring, weights, or leaderboard; those are left to independent implementations, including Ora's own scanner, Is Agentic, and Mintlify's Agent Score. See the spec and announcement.

Cloudflare Agent ReadinessCopy Anchor Link

Cloudflare's checker covers discovery, content, bot access control, API/auth/tool metadata, and commerce. It exposes a skill index, a remote MCP server at https://isitagentready.com/mcp, and a scan API:

curl https://isitagentready.com/api/scan \
  -H 'Content-Type: application/json' \
  --data '{"url":"https://example.com"}'

First verified on 10 September 2026 with 22 available checks. On 29 October 2026 the page's loaded script recognized 23 check IDs, including a new personal agent protocol check (personalAgentProtocol, Poppy), while the rendered form showed 22 checkboxes (AP2 is in the script but not rendered); the default selection still excludes A2A and AP2. Count the exact surface you use. Commerce is excluded from the displayed overall percentage, as is the personal agent protocol check, and neutral results do not count in its denominator. The API also returns a separate readiness level. Record the selected checks and scan time when comparing results.

Its useful differences from Ora's published catalog are:

• DNS-AID: an additional DNS discovery check, absent from Ora contract 1.38.0's 132 checks. See DNS Discovery for applicability and verification.
• Content Signals: Cloudflare scores it as a standalone check, separate from crawler rules. Ora's single crawler-policy check (robots-ai-policy-quality) now describes search-crawler access and says blocking training crawlers never lowers the score; its catalog does not describe scoring Content Signals directives, so confirm how it treats them before comparing. Keep access and content use separate in your implementation even when a scanner combines their scores.
• Discovery routes: the catalog probe also tries DNS TXT and SRV records. A broader set of probes does not imply a new product requirement.

Is Agentic uses Ora's checks, so it provides another interpretation of that evidence rather than an independent checklist. Most Cloudflare capabilities overlap Ora, with different acceptance criteria and weights. Use each report to investigate actual client failures; a scanner's preferred path or older API name is not a substitute for the current protocol specification.

Google Lighthouse Agentic BrowsingCopy Anchor Link

Lighthouse ships an agentic-browsing category in its default config, added in Lighthouse 13.3.0 (7 May 2026) and included by default since. The latest release at the last check, 13.6.0 (27 October 2026), keeps the same seven audits and adds multi-URL CLI auditing (--url-file, --fail-fast), which suits repeatable coverage. It runs in both navigation and snapshot mode and is explicitly marked experimental: "This category is still under development and subject to change." Chrome's scoring guide says testing it needs Chrome 150 or later, and the WebMCP audits need the WebMCP origin trial. It scores as a pass fraction rather than 0-100.

Seven audits make up the category, defined in agentic-browsing-config.js and default-config.js:

• agent-accessibility-tree - a subset of axe rules covering accessible names, labels, ARIA validity, and document title.
• webmcp-registered-tools - lists registered WebMCP tools and warns above 40.
• webmcp-form-coverage - flags forms missing WebMCP tool annotations.
• webmcp-schema-validity - flags issues such as a missing form toolname, tooldescription, or parameter descriptions.
• cumulative-layout-shift - the standard performance audit, reused here.
• llms-txt - fetchable, Markdown, with at least one H1.
• ard-schema - validates ai-catalog.json against the ARD spec, discovered via a robots.txt Agentmap: line, an HTML <link rel="ai-catalog">, an HTTP Link header, or the /.well-known/ai-catalog.json fallback.

Run it locally:

npx lighthouse https://example.com --only-categories=agentic-browsing

Unlike the hosted scanners above, Lighthouse runs on your own machine, so the "only submit public URLs" caution above does not apply to it: point it at a pre-release, staging, or authenticated environment you can reach locally.

Agent-Friendly Documentation Spec and AFDocsCopy Anchor Link

The Agent-Friendly Documentation Spec, by Dachary Carey and community contributors, defines 28 checks in seven categories for how well a documentation site serves agents that fetch it: llms.txt, Markdown availability, page size and truncation, content structure, URL stability, observability and authentication. It was a draft at v0.6.0 (13 September 2026) when observed on 2026-10-29. Its platforms page records the fetch and truncation behaviour of common agents, which is where its size thresholds come from.

AFDocs is the MIT-licensed implementation, published on npm as afdocs (0.22.2 when observed, and still labelled early development, so check IDs and flags can change between minor versions). It powers Fern's Agent Score, and Mintlify's Agent Score reports group their documentation checks under AFDocs references, adding components of their own for llms-full.txt, skill.md and MCP.

Use AFDocs where a hosted report stops: it names the pages. A hosted score samples a handful of pages and reports, for example, "3 of 15 pages have content differences" without saying which. AFDocs runs locally against any URL, including a local production build, and --format json returns per-page evidence:

# Whole site, discovered through llms.txt and the sitemap
npx afdocs check https://docs.example.com --max-links 200 --format json

# Exactly these pages, for example a local build before deploying
npx afdocs check http://localhost:3000 --urls http://localhost:3000/,http://localhost:3000/docs/quickstart \
  --checks markdown-content-parity,content-start-position,llms-txt-directive-html

Its page-level checks catch problems that look fine in a browser: words lost from sentences because they sat inside a <button>, navigation read before content, Markdown twins that drifted from the page, and relative links in Markdown. See What Survives Conversion to Markdown and representation parity. When it samples links from llms.txt, it also tests non-page targets such as openapi.json and JSON discovery documents against page checks; read those results as not applicable rather than as failures. AFDocs also ships vitest helpers for running its checks in CI.

Shopify product-page auditCopy Anchor Link

Shopify's product-page audit takes a single product-page URL and checks the structured data AI shopping agents read to answer shoppers' questions, tied to Shopify Catalog and Agentic Storefronts. Shopify does not publish a detailed methodology or check list for the tool; it states plainly that results are "informational signals" and do not guarantee a product will be surfaced by AI agents. Treat it as a commerce-specific spot check on a product page's structured data, not a general-purpose agent-readiness scanner.

Other public checkersCopy Anchor Link

Many smaller free checkers exist beyond the ones above, mostly re-skinning variations of the same checklist. This guide tracks practices by the underlying standard - robots.txt, Content Signals, llms.txt, ARD, WebMCP, and so on - rather than by which checker currently scores them, since checker rosters turn over faster than the standards do.