AI Readiness Methodology

AI consumer and access-layer model

Each AI consumer reads a site differently, and the differences are structural. A coding agent often depends on raw-HTML payloads and semantic code blocks. An answer engine may rely on schema markup, headings, extracted answer spans, search indexes, or direct fetches. A commerce agent depends on product, variant, cart, and confirmation structure. Crawlers and training corpora are not a fourth user-facing job — they are the access layer the other three depend on. A single undifferentiated rubric cannot score these consumers accurately; per-consumer rubrics — sharing a common spine for comparability — are the design commitment this methodology makes.

• Primary consumer classes: coding agents and fetchers, answer engines, commerce agents.
• Access layer: crawlers and training/retrieval corpora.
• Tracked but not scored separately: voice and ambient AI.

This rubric does not attempt to model every proprietary retrieval pipeline. It scores site-side conditions that make successful retrieval, extraction, attribution, and action more likely across common AI-consumption paths — using observed agent behavior and the operators' own published guidance where it exists, and conservative defaults where it does not.

What is fully represented today: Coding Agents & Fetchers, in the shipped Docs Readiness Audit. Answer-engine signals are scored as a secondary consumer in the Docs rubric. Commerce-agent and Marketing/Answer-Engine-primary rubrics are in active design. The consumer-and-access-layer model is the architecture; one product instance is shipped today.

What AI Readiness is NOT

AI Readiness shares territory with adjacent measurement categories. The boundaries:

vs. SEO

Modern SEO and AI Readiness overlap more than they used to — both reward structured data, semantic HTML, crawlability, internal linking, and rendering hygiene. The divergence is downstream, not in the raw ingredients. SEO optimizes the page to rank in a results list a human will scan and click; AI Readiness measures whether the page is prepared to be ingested, parsed, extracted, attributed, and cited by a system that never shows a results list. The same fix often helps both. The difference is how we judge success: not ranking position, but machine-readable evidence available to AI consumers. A page can rank well in Google and still score poorly on AI Readiness if its content surfaces only after JavaScript execution; a page can have weak link equity and score well on AI Readiness if its raw HTML payload is rich, schema-correct, and agent-metadata-disclosed.

vs. web accessibility (WCAG, a11y)

AI Readiness is sometimes described as "machine accessibility," and the framing is partly fair — accessible implementation often improves AI Readiness because semantic HTML, headings, alt text, labels, and navigable structure benefit both audiences. The difference: WCAG is a compliance standard with conformance levels and legal weight; it tests whether humans with disabilities can use the page. AI Readiness is a quality measurement with no equivalent regulatory frame; it tests whether AI consumers can fetch, parse, extract, attribute, and act. WCAG conformance does not test bot access, raw-HTML content availability, schema markup, AI-metadata files, citation identity, or agent traversal. A site can be fully WCAG-compliant and score badly on AI Readiness if its content is gated behind client-side JavaScript that AI crawlers do not execute. The two measurements are complementary; neither subsumes the other.

vs. AI-visibility outcome trackers (Adobe Brand Visibility, Profound, Athena, Goodie, Peec)

Outcome trackers measure brand mentions in AI engine outputs — they sample AI responses, count citation frequency over time, and report visibility as a tracked KPI. Obaron measures the content infrastructure that determines whether AI engines can find and cite the brand at all — an input layer measured by inspecting the site's structure, schema, payload, and accessibility to AI crawlers. The honest version of the comparison: outcomes tell a brand whether AI engines are citing them; inputs tell a brand why and what to fix. Running both gives a closed loop — outcomes show the gap, inputs show the cause. Running only outcomes without input measurement leaves the brand without an actionable cause for a score that isn't moving. Owned-site readability is one controllable input to AI visibility, not the only input — third-party mentions, Wikipedia/Wikidata, marketplace pages, GitHub, package registries, and partner sites also contribute. It is the input this audit measures because it is the one a site owner can change.

vs. organizational AI-readiness assessments (Big Four, Microsoft partners, transformation consultancies)

Both are legitimate uses of the term "AI Readiness" — they describe different layers, and a company often needs both. The Big Four (and the cloud-provider, Microsoft-partner, and boutique-transformation flavors) measure whether an organization is ready to deploy AI internally — change-management readiness, AI strategy maturity, training and governance frameworks, integration into business processes. Those engagements usually produce organizational scorecards, roadmaps, governance models, and executive decision materials. The methodology on this page measures whether AI systems can read the organization's external content — the input infrastructure that determines whether AI consumers can fetch, parse, and cite. Same words, different products, different layer.

vs. Lighthouse, structured-data validators, and page-quality auditors

These are the closest tools in spirit to a Lightning Scan, and a technically literate buyer will reasonably ask "isn't this just Lighthouse with extra steps?" or "isn't this what Schema.org's validator does?" Lighthouse measures page performance, accessibility, and best-practices for human-facing browsing. Schema validators check structured-data syntactic correctness — does the JSON-LD parse, do the required properties exist, does the type chain validate. AI Readiness measures something different: whether the union of (access policy + raw-HTML payload + schema + structure + identity + agent-metadata) makes the page ingestible, parseable, extractable, attributable, and actionable by AI consumers. Validator outputs can be inputs to a Lightning Scan; the Score is on the consumer-facing result, not the syntax. A page can pass every Schema.org validator and still fail rendering checks if the schema appears only after JavaScript executes; a page can score 100 on Lighthouse Best Practices and still score 40 on AI Readiness if its docs are auth-walled to AI bots in robots.txt.

Methodology stewardship

Maintained by Adam Kinney — co-creator of Microsoft Learn, Stripe Docs contributor.

The rubric's evidence basis draws on two independent research lines. AFDocs Spec (Dachary Carey) shaped the rendering, content-density, and link-structure categories. HTTP behavioral signatures for AI agents (Oleksii Borysenko, Cisco DevNet) provided wire-level evidence on how nine named coding agents fetch documentation — evidence for how the rubric treats JavaScript-rendered content. These contributors shaped what the rubric measures. They have not reviewed or endorsed the rubric as a whole.

Separately, we're investigating the do11y community (Manny Silva) as a future input on observability framing — no catalog row currently maps to it.

The current rubric has not undergone formal external review. Anyone who wants to inspect the rubric or contest a weight is welcome to write to hi@obaron.ai.

Last reviewed: May 14, 2026. Review cadence: at every version cut.

References & conventions

The rubric draws on three different kinds of source. A buyer evaluating the methodology should know which is which — what's a formal standard, what's an emerging convention Obaron is making an explicit bet on, and what's an Obaron rubric choice subject to revision.

Established standards and widely adopted vocabularies

• Schema.org widely adopted vocabulary — structured-data vocabulary used for the docs-relevant types the rubric scores (TechArticle, SoftwareSourceCode, HowTo, FAQPage, Organization, BreadcrumbList, Product, Offer, AggregateOffer, WebSite with SearchAction).
• robots.txt formalized in RFC 9309 — the access-control protocol the rubric reads to determine which AI bots are allowed or blocked. ObaronBot honors it.
• Sitemap protocol widely adopted convention — sitemap presence and shape inform architecture-for-traversal scoring and the page-selection step on the full Audit.
• HTTP status codes formalized in RFC 9110 — 200/3xx/4xx/5xx behavior at fetch time is observed directly. The Auth-walled cap reads 401/403 against ObaronBot specifically.

Emerging conventions (the bet)

These three files are not yet formal standards. Adoption is partial and contested. Obaron treats them as the emerging convention for agent-readable site metadata and weights their joint absence accordingly. Obaron will revise the cap and the weight if adoption patterns shift.

• llms.txt draft / convention — proposed convention for surfacing a site's primary content in an LLM-fetchable summary.
• agents.md draft / convention — proposed convention for declaring agent-relevant capabilities, endpoints, and constraints. No single canonical spec; tracked across vendor proposals.
• .well-known/mcp.json Obaron-tracked emerging convention — surfacing MCP-related discovery metadata. Not a formal MCP standard unless and until a canonical specification stabilizes.

Obaron rubric choices

Everything else is an Obaron choice — the per-category weights, the hard-cap thresholds, the evidence floors used in soft-signal classification, the page-type detection logic, the Lightning ceiling derivation. These are documented as structural-delta tables in the rubric changelog; a machine-readable rubric module is planned. Choices are subject to revision at version cuts; the version-level structural crosswalks make the deltas legible to customers across versions.