Docs/Scores

Agent Readiness

What the Agent Readiness score measures and how to improve it.

What Agent Readiness measures

Weight: 30% of the AI Readiness Score

Agent Readiness answers the question: can AI agents act on your content?

Where Crawlability measures whether content is visible, Agent Readiness measures whether that content is structured, discoverable, and actionable for an AI system that needs to understand, summarize, or use your site programmatically.

The score is normalized to 0–100 before entering the composite formula.

A1 — Structured Data Completeness

Checks how complete your metadata is for AI systems that consume page-level signals.

SignalWhat the scanner checks
og:title, og:description, and og:image all presentAll three core OpenGraph meta tags exist with non-empty values
og:type presentThe og:type meta tag is set (beyond the three basics)
Schema.org JSON-LD with at least 3 non-boilerplate propertiesJSON-LD has 3 or more meaningful properties beyond @type and name
Schema.org Product or SoftwareApplication with offers, or a pricing table in the HTMLPricing data is machine-readable via Schema.org offers or an HTML <table>
twitter:card and twitter:title presentBoth Twitter Card meta tags exist for social preview support
Canonical <link rel="canonical"> presentA <link rel="canonical"> tag exists with a valid URL

What scores well vs. what doesn't:

The scanner looks for metadata in <head> that AI systems use to understand the page.

<!-- Scores well: complete metadata set -->
<head>
  <meta property="og:title" content="Your Page Title">
  <meta property="og:description" content="A clear description.">
  <meta property="og:image" content="https://example.com/og-image.png">
  <meta property="og:type" content="website">
  <meta name="twitter:card" content="summary_large_image">
  <meta name="twitter:title" content="Your Page Title">
  <link rel="canonical" href="https://example.com/this-page">
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Organization",
    "name": "Your Company",
    "url": "https://example.com",
    "description": "What you do.",
    "sameAs": ["https://twitter.com/yourco"]
  }
  </script>
</head>

<!-- Scores poorly: only a title tag, no structured metadata -->
<head>
  <title>My Page</title>
</head>

A page with all three core OpenGraph tags, Twitter Card tags, a canonical link, and JSON-LD with 3+ meaningful properties scores highest on this check.

A2 — Content Negotiation

Checks whether your server can deliver content in formats that AI agents prefer, beyond HTML.

SignalWhat the scanner checks
Server returns Markdown when Accept: text/markdown is requestedResponse has Content-Type: text/markdown or body starts with Markdown syntax
/llms.txt is present and accessibleGET /llms.txt returns HTTP 200 with a non-empty body
Page links to a JSON feed or API documentationPage contains a link to /api, /docs, or a <link rel="alternate" type="application/json"> tag

What the scanner checks:

The scanner makes three probes:

  1. Markdown negotiation — sends a request with Accept: text/markdown and checks whether the response comes back as Markdown (either via Content-Type: text/markdown or body starting with Markdown syntax)
  2. llms.txt — requests /llms.txt and checks for an HTTP 200 response with a non-empty body. This file describes your site for AI systems in the format defined at llmstxt.org
  3. API/JSON discovery — looks for links to /api, /docs, or a <link rel="alternate" type="application/json"> tag

An example llms.txt:

# Example Company

> A one-line description of your product.

## Docs
- [API Reference](https://example.com/docs/api): Full API documentation.
- [Quickstart](https://example.com/docs/quickstart): Get started in 5 minutes.

A3 — Machine-Actionable Data

Checks whether your key facts — pricing, features, contact info, and CTAs — are accessible in structured HTML or Schema.org, not just rendered visually.

SignalWhat the scanner checks
Pricing data in an HTML <table> or Schema.org offers/price/telephone/emailKey facts (pricing, contact info) exist in structured HTML or Schema.org, not just visually
Page has a clear heading hierarchy (<h1> + at least one <h2>)A proper H1-to-H2 content pattern with no more than one skipped level
Page has discoverable CTAsLinks with text like "sign up", "get started", "pricing", "docs", "api", "contact", "free trial", or "demo" exist as <a> tags in bot HTML
Bot-view has at least 50% of the text present in the rendered viewCritical data is not hidden behind JavaScript — at least half the rendered text is in the bot-view

What scores well vs. what doesn't:

The scanner looks for key facts (pricing, contact info, CTAs) in structured HTML rather than in JavaScript-rendered components.

<!-- Scores well: pricing in a <table>, descriptive CTA links -->
<table>
  <tr><th>Plan</th><th>Price</th></tr>
  <tr><td>Starter</td><td>$29/mo</td></tr>
  <tr><td>Pro</td><td>$49/mo</td></tr>
</table>
<a href="/signup">Get started free</a>
<a href="/pricing">See pricing</a>

<!-- Scores poorly: generic link text, no structured data -->
<a href="/signup">Click here</a>

The scanner also checks heading hierarchy (<h1> followed by at least one <h2>) and compares bot-view text to rendered text — at least 50% of rendered content should be present in the bot-view HTML.

Framework example:

When pricing lives in a React component that fetches from an API, the bot-view HTML contains no pricing data:

// Client component — scanner sees nothing
'use client';
export default function Pricing() {
  const [plans, setPlans] = useState([]);
  useEffect(() => { fetch('/api/plans').then(r => r.json()).then(setPlans); }, []);
  return <div>{plans.map(p => <PlanCard key={p.id} plan={p} />)}</div>;
}

When pricing is server-rendered or in a static <table>, the scanner finds it in the initial HTML. Schema.org offers provides additional machine-readable pricing:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Starter Plan",
  "offers": {
    "@type": "Offer",
    "price": "29",
    "priceCurrency": "USD"
  }
}
</script>

A4 — Standards Adoption

Checks adoption of emerging AI-specific standards and discovery mechanisms.

SignalWhat the scanner checks
robots.txt includes explicit rules for AI botsAt least one User-agent rule exists for GPTBot, ClaudeBot, PerplexityBot, or similar AI crawlers
robots.txt exists with User-agent: * (but no explicit AI bot rules)A generic robots.txt is present but has no AI-specific entries
robots.txt includes a Content-Signal: directiveA Content-Signal: directive (per contentsignals.org) with ai-train, ai-input, or search parameters
sitemap.xml returns 200 with XML content typeHEAD /sitemap.xml returns HTTP 200 with an XML content type
sitemap.xml returns 200 with non-XML content typeHEAD /sitemap.xml returns HTTP 200 but with a non-XML content type
Link response header includes a discovery relationResponse headers contain a Link: header with api-catalog, describedby, service-doc, alternate, or canonical
/.well-known/mcp/server-card.json returns 200The MCP Server Card endpoint responds successfully
/.well-known/api-catalog returns 200The RFC 9727 API Catalog endpoint responds successfully
/.well-known/oauth-authorization-server or /.well-known/openid-configuration returns 200An OAuth or OpenID Connect discovery endpoint responds successfully

What the scanner looks for:

The scanner probes several files and headers for AI-specific standards:

robots.txt — checks for explicit rules targeting AI crawlers:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

A robots.txt with AI-specific User-agent rules scores higher than one with only User-agent: *. A Content-Signal: directive (per contentsignals.org) with ai-train, ai-input, or search parameters scores additional points.

Other endpoints checked:

  • sitemap.xml — HTTP 200 with XML content type
  • /.well-known/mcp/server-card.json — MCP Server Card
  • /.well-known/api-catalog — RFC 9727 API Catalog
  • /.well-known/oauth-authorization-server or /.well-known/openid-configuration — OAuth/OIDC discovery
  • Link response header — with api-catalog, describedby, service-doc, alternate, or canonical relations

Need Help?

Can't find what you're looking for? Reach out and we'll help.

Contact us