Agent Readiness Score Explained: How We Calculate It

If you've run a scan on AgentReady, you've seen a single number come back — your Agent Readiness Score (ARS). This post explains exactly what goes into that number: the five pillars we check, why each one matters to an AI agent specifically (not just a search engine), and how to read a low score without guessing at what to fix first.

Why a single score, and why now

Every emerging technology creates its own wave of "readiness" scanners — mobile-friendliness checks, Core Web Vitals, accessibility audits. Each one exists because the underlying shift (mobile traffic, page speed, assistive technology) changed how a meaningful share of visitors actually experienced the web, and site owners needed a fast way to know where they stood.

Browser-based AI agents are the same kind of shift. An agent visiting your site isn't a search engine crawler indexing text for later retrieval, and it isn't a human reading your layout — it's a third kind of visitor with its own requirements: it needs to parse your content efficiently, understand what actions are available, and act on the page reliably. A site can rank perfectly in Google and still be effectively unusable to an agent trying to complete a task on it. The Agent Readiness Score exists to measure that gap directly.

The five pillars

Your overall score is a composite of five categories. Each category is scored independently, and your final ARS is a weighted average — a site can't compensate for a serious gap in one pillar simply by excelling in another, because a critically broken pillar (say, a robots.txt file that blocks all AI crawlers outright) caps what the rest of the score can achieve.

1. WebMCP Support

This pillar checks whether your site exposes any structured, machine-callable actions at all — the core question of whether an agent can do something on your page, not just read it. We check for:

• Presence of navigator.modelContext tool registrations on key pages
• Whether your forms use the Declarative API's toolname/tooldescription attributes, or plain unannotated markup
• Whether registered tools have complete, well-formed input schemas rather than vague or missing parameter definitions
• Whether tool descriptions are written in a way a language model can actually parse (specific verbs, clear parameters) versus generic labels like "submit" or "go"

This is the newest and, for most sites today, lowest-scoring pillar — WebMCP is still an early-preview technology, so a low score here reflects the state of the ecosystem as much as it reflects your specific implementation. We weight it accordingly relative to the more established pillars below, but flag it clearly because it's where the fastest competitive advantage is currently available.

2. Structured Data

This checks for machine-readable markup that lets an agent understand what your content is without inferring it from layout or visual design — Schema.org types delivered as JSON-LD, correctly nested and matched to your actual content:

• Product, Offer, and AggregateRating for e-commerce pages
• Organization and WebSite on your homepage
• FAQPage for FAQ content, Article for blog content
• Whether your structured data actually matches what's visibly on the page — mismatched or stale structured data (a common regression after redesigns) is flagged as a failure, not a partial pass

This pillar overlaps with traditional SEO structured data checks, but the bar is different: a search engine can often recover from partial or slightly malformed JSON-LD by falling back to visible text. An agent parsing your page programmatically is more likely to trust — and act on — whatever structured data is present, even if it's wrong, which makes accuracy here higher-stakes than it was under classic SEO.

3. Semantic HTML

This checks whether your page's underlying markup actually describes its content and structure, independent of how it's styled:

• Real heading hierarchy (h1 through h6 used in order, not skipped or duplicated for visual effect)
• Semantic elements (nav, main, article, button) instead of generic divs with click handlers standing in for interactive elements
• Proper label association on form inputs, not placeholder text used as a label substitute
• Text-to-markup ratio — pages that are mostly nested div wrappers with little actual text content are harder for an agent to extract meaning from, even when they render clearly to a human eye

This is the pillar most directly inherited from accessibility best practices, and that's not a coincidence — a page built to be understandable by assistive technology is, by construction, closer to being understandable by a language model parsing the DOM.

4. Technical Accessibility

This covers the baseline conditions that determine whether an agent can reach and process your content at all, before any of the content-quality checks above are even relevant:

• robots.txt rules for AI crawlers specifically — GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and others, distinguished from your general crawl rules
• Whether critical content requires JavaScript execution to appear at all, versus being present in the initial HTML response
• First Contentful Paint and render-blocking resources — agents tend to time out faster than a patient human user waiting on a slow page
• HTTPS enforcement, since several agent-facing APIs (including WebMCP itself) refuse to operate in an insecure context

A failure here is treated as a hard gate in scoring, not just a deduction: if your robots.txt blocks AI crawlers outright, none of your structured data or semantic HTML matters, because the agent never gets far enough to read it.

5. API Integrity & Auth

For sites that expose functionality beyond static content — booking systems, account dashboards, checkout flows — this pillar checks whether the surrounding API and authentication layer is discoverable and well-formed:

• Presence and validity of OpenAPI descriptions for exposed HTTP endpoints
• OAuth discovery documents (/.well-known/oauth-authorization-server and related metadata) where delegated access is relevant
• Whether error responses are descriptive enough for an agent to understand what went wrong and retry correctly, versus generic failure codes

This pillar is weighted down for sites without an API surface at all — a documentation site or a static marketing page isn't penalized for lacking OAuth metadata it has no reason to expose, in the same way a docs site was never expected to implement e-commerce checkout requirements.

How the weighting works

Not every pillar carries equal weight for every site, because not every site has the same surface. A marketing site with no checkout flow and no API isn't scored against API Integrity & Auth the same way a SaaS product is — the check simply doesn't apply, and the remaining pillars are reweighted to still produce a meaningful 0–100 score rather than penalizing a site for a category that was never relevant to it.

Within each pillar, individual checks are not weighted equally either. A missing robots.txt AI-crawler policy affects every downstream pillar and is treated as more severe than, say, a slightly generic tool description on a low-traffic page. The goal is for the score to reflect actual impact on agent usability, not just a raw count of passed and failed checks.

Reading your results

A score in the 80s or 90s means an agent can reliably find, parse, and (where applicable) act on your site's content today. A score in the 40s or 50s usually means the technical accessibility basics are in place but structured data or semantic HTML have real gaps — this is the most common range for established sites that have invested in traditional SEO but haven't yet built for agents specifically. A score below that typically points to a hard gate: blocked crawlers, JavaScript-only content, or missing HTTPS.

Every scan returns prioritized, per-check recommendations rather than just the composite number, specifically so a low score comes with a concrete next step instead of a grade with no path forward.

Run it on your own site

Scores shift as standards evolve and as your site changes — a redesign that drops structured data, a new page shipped without semantic markup, will move your number even if nothing else about your agent-readiness strategy changed. Run a free scan at AgentReady to see where your site currently stands across all five pillars, and track your score over time as you make changes.