How the agent-readiness score is computed

What the score is

A deterministic 0-100 agent-readiness score for public content websites, computed from the 8 fetches the checker already makes (homepage, one sampled internal page, their markdown mirrors, llms.txt, robots.txt, the sitemap and a probe for a path that cannot exist). No LLM, no heuristics, no off-site search, and no extra request per check. The same engine runs in the browser on the checker page and in Node, and both compute identical numbers from the same evidence.

The score does not predict inclusion, ranking, traffic or citation by any AI system. It states what the fetched responses show, check by check, and how those checks add up under the rules below.

The lens

The structure is Essentials-shaped: required checks share a 80-point pool, recommended checks share 20 points, and bonus signals add 0.25 points each up to a cap of +5. That structure is modelled on the published Essentials layer of Ora (is-agentic.com, contract version 1.38.0, audit of agentmarkup.dev dated 2026-10-10). This is not Ora's score: Ora's headline grade is a different, layered lens, several of its checks need fetches this engine does not make, and the divergences are listed below. Agreement with Ora was checked on one site only; no calibration is claimed for any other site.

Status semantics

Each check ends in exactly one status. Only the first three sit in the denominator.

• pass: fraction 1. Eligible.
• partial: fraction strictly between 0 and 1, earning proportional credit. Eligible.
• fail: fraction 0. Eligible.
• not applicable: the applicability rule says the check does not apply to this site (no form fields, no served markdown, no API or MCP surface, a blocked homepage). Leaves the denominator; listed in the panel with the reason.
• could not be verified: the evidence the check needs did not complete (status 0, a transport error, a 2xx without a body, a skipped fetch, a 429 or a 5xx without challenge markers). Leaves the denominator. One such check marks the whole run provisional: the panel shows the score with a pessimistic-to-optimistic range (every unverified check at fraction 0 and at fraction 1), the worker never caches the run, and it is never stored as a monthly reading. A timed-out fetch therefore never lowers the score.
• not measured: listed in the catalog for parity but not implemented in this version. Leaves the denominator.

Two homepage rules sit above everything else. If the homepage itself could not be verified, every check is unverified, the run is blocked and there is no score. If the homepage answers a bot challenge or a 401/403, reach.bot-detection scores 0 with the status and marker quoted, every other homepage-derived check is not applicable, and the score is computed from what remains (robots.txt, llms.txt, the sitemap and the probe). A challenge page is never evaluated for headings, JSON-LD or landmarks.

The catalog

48 rows: 34 scored in catalog 1.0.0 (9 required, 10 recommended, 15 bonus), 3 that need one extra fetch each and wait for a catalog 2.0 decision, and 11 listed for parity with Ora's catalog and not measured (off-site search, API, MCP and payment surfaces). Each row names its bucket, what it reads, the exact rule with thresholds, the Ora counterpart, and the sentence a non-technical client sees on a pass and on a fail.

Formula v1.0.0 and grade bands

1. The eligible set per tier is the checks in that tier with status pass, partial or fail. Not applicable, could-not-be-verified and not-measured checks leave the denominator.
2. required.earned = 80 x sum(fraction over eligible required) / count(eligible required), and recommended.earned = 20 x sum(fraction over eligible recommended) / count(eligible recommended). Partial results earn proportional credit.
3. bonus.points = min(5, 0.25 x sum(fraction over bonus checks with status pass or partial)). The absence of a bonus signal never subtracts. With 15 bonus signals scored now the maximum is 3.75 points before the cap binds.
4. raw = required.earned + recommended.earned + bonus.points, reported to two decimals beside the integer; score = min(100, round-half-up(raw)).
5. The grade comes from the bands below and the label from the grade. The bands are agentmarkup's own: they are not evidenced in any Ora file or page.
6. A run is complete when no check and no fetched resource is unverified, and provisional when any is, with the pessimistic-to-optimistic range taken from the unverified checks (equal to the score when only a resource is unverified). It is blocked, with no score, when the homepage could not be fetched (a re-run may succeed) or when the site root gave a final non-2xx answer other than 401 or 403 (nothing to score until the root serves a page). A 401, a 403 or a challenge page is scored as described under status semantics.
7. A tier with zero eligible checks contributes 0 and is reported as not applicable. This cannot happen for the required tier on a reachable HTML homepage because reach.bot-detection is always eligible.
8. The catalog and formula versions are embedded in every report; a comparison between reports with different major versions is refused ("formula changed, re-baseline").

Quantisation

Required steps are 80 / N for N eligible required checks: 8.9 points per full fail at N = 9 (every required check eligible), 10.0 at N = 8 (for example, a homepage without form fields). One required flip can cross a grade band. This is inherent to the pool structure; the mitigations are that an unverified check never counts, that multi-rule checks earn proportional credit, that the raw score is shown beside the integer, and that transient HTTP states (429, 5xx) never score.

Estimated gain and top fixes

Every non-passing eligible check carries the gain this score would get if the check reached fraction 1 with the current denominator:

• required / recommended: round1((1 - fraction) x pool / count(eligible in tier))
• bonus: round2(min((1 - fraction) x 0.25, 5 - bonus.points))
• null when the check already passes; not applicable, unverified and not-measured checks never carry a gain.

Top fixes are ranked by estimated gain, then tier (required, recommended, bonus), then catalog order; the panel lists the first 5. Gains assume the current denominator: a fix that makes other checks eligible (serving markdown makes markdown.code-fences eligible) changes the count, so gains are estimates. When the score is already 100 the panel says "at the cap" and still lists the remaining gains so required gaps stay visible.

Divergences from Ora

• A real 404 or 410 for a path that cannot exist earns full credit on nav.not-found; an agent-readable (markdown or JSON) 404 body is the separate bonus nav.not-found-markdown. Ora gives partial credit for the status alone.
• The two robots.txt policy checks are scored as one recommended check, robots.ai-search-access, over the AI search and agent user agents only. Blocking training crawlers is reported as a policy note and never subtracts.
• MCP and API checks are not applicable to a site without an MCP or API surface, so a public content website is not penalized for omitting an interface it does not provide. Ora scores mcp-server for every site.
• The ax.* checks are static-HTML proxies of a browser accessibility tree: they count elements and attributes in the served HTML and cannot see handlers bound by JavaScript.
• trust.anchors measures whether About, Contact and Privacy pages are linked from the homepage, not the depth of those pages.
• llms.agent-instruction is a presence rule: it looks for explicit guidance wording or a summary blockquote, not for the quality of the advice.
• jsonld.identity is evaluated over parseable JSON-LD blocks only; an unparseable block is reported by jsonld.syntax, an upside-only bonus shown as an error-level finding that never subtracts from the score.
• A check whose evidence never completed (a timed-out or failed fetch, a 429 or a 5xx without challenge markers) is unverified: it leaves the denominator, marks the run provisional with a pessimistic-to-optimistic range, and is never cached or stored.

Sampling, caps and published lists

• Sample page: the first same-origin link in document order on the homepage, resolved against the final homepage URL after redirects. Every report names it; a navigation reorder can change it.
• Same origin is judged against the origin of the final homepage URL, never the requested one, so an apex-to-www redirect does not fail trust.anchors.
• Evaluation cap: checks read at most the first 1,048,576 characters of any body; a truncated body is flagged in the evidence.
• Missing-path probe: /agentmarkup-probe-404-does-not-exist-9f3a2c at the final-URL origin, following no redirects, with Accept: text/markdown, application/json;q=0.9, text/html;q=0.8, */*;q=0.1 so a compliant negotiator can answer markdown or JSON.
• Challenge markers (a response header cf-mitigated containing challenge, or any of these strings in the first 20,480 characters of the body): __cf_chl, challenge-platform, cf-browser-verification, Just a moment..., Attention Required!, Enable JavaScript and cookies to continue, Pardon Our Interruption, _Incapsula_Resource, captcha-delivery, px-captcha. Additions bump the catalog minor version.
• AI search and agent user agents scored by robots.ai-search-access: OAI-SearchBot, Claude-SearchBot, PerplexityBot, ChatGPT-User, Claude-User, Perplexity-User.
• Training crawlers reported as a policy note, never scored: GPTBot, ClaudeBot, Google-Extended, CCBot.
• Text resource: a 2xx response whose content type is not HTML and whose body is not an HTML document. A host answering 200 HTML for llms.txt, robots.txt or a markdown URL reads as absent for that resource; a 200 status is not proof.

Versioning

The catalog and the formula carry semantic versions. Any change to required or recommended membership (adding, removing or re-tiering a check) bumps the catalog MAJOR version because it changes denominators; a rule change inside a check bumps MINOR; a copy-only change bumps PATCH. Scores compare only within a major version, and every report embeds both versions so a stale comparison is refused instead of silently mixing formulas. The 3 checks that need an extra fetch are therefore a catalog 2.0 decision, not a point release.

Reproduce it yourself

The checker's "Technical details and resources" panel shows the fetched resources, and every finding carries the evidence string the rule read: counts, ids, URLs, attribute and header values, never raw HTML. The engine itself is open source in the agentmarkup repository under packages/core/src/score/ as the score entry of @agentmarkup/core (evaluateSiteChecks and scoreChecks). From Node, npx @agentmarkup/audit <url> --score prints the same report once the audit release that carries the flag is on npm.

Change log

• Catalog 1.0.0 and formula 1.0.0 (November 2026): first public version. 34 checks scored with zero extra fetches, 3 awaiting a catalog 2.0 decision, 11 listed for parity and not measured.