Methodology · Version 1.0
AG AgentReady Research Benchmark Methodology
This page documents the methodology used for the AG AgentReady research benchmark. The benchmark measures broader Website Readiness across Revenue Readiness, Agent Readiness and Trust & Clarity. It is related to, but distinct from, the current Agent Readiness diagnostic and runtime WebMCP verification shown in individual reports. Figures produced with this methodology appear on the State of AI Customer Readiness benchmark.
Product assessment and research benchmark
AG AgentReady uses two related measurement layers. Individual current reports focus on Agent Readiness: what AI agents can discover, understand and use, including observed website actions, agent-facing tools, evidence-backed gaps and runtime WebMCP verification where available.
Separately, AG AgentReady Research maintains a broader Website Readiness benchmark covering Revenue Readiness, Agent Readiness and Trust & Clarity. The benchmark supports aggregate research and historical comparison; it should not be read as meaning every benchmark signal contributes to current runtime Agent Readiness verification.
Source-level prerequisites and broader website-quality signals are not the same as runtime-observed WebMCP capability. Runtime verification remains specific to the page and time observed, and AG AgentReady does not execute registered tools.
What the scanner measures
A scan reads up to five publicly accessible pages of the submitted website: the homepage plus, where they can be discovered from it, pages such as services, contact, about and pricing. Only published, publicly reachable content is analysed — nothing behind a login is read.
Deterministic checks defined in code extract observable signals from that content — headings, page titles and descriptions, action wording, contact routes, forms, review and credential references, semantic landmarks, JSON-LD structured data, agent-discovery signals and basic technical hygiene. Each check returns a 0–1 result, which may include partial credit.
Every score is computed in code from those checks. A language model is used only to rewrite the plain-language summary and recommendations; it never influences a score, a severity or a check result.
Page-specific WebMCP discovery
WebMCP tools are registered by individual webpages, so capability can differ from one page to another. A homepage may expose no tools while a booking, quote, product or application page on the same website does.
AG AgentReady keeps the submitted URL as the exact-page verification anchor. Separately, it performs bounded website-wide discovery across selected relevant same-site pages to identify additional WebMCP capabilities.
The broader website diagnostic may read up to five public pages. Runtime WebMCP discovery uses its own bounded page-selection process, so these are related but separate scopes.
Additional pages may be selected from same-site links, canonical URLs and sitemap information, with commercially relevant pages such as booking, quote, contact, product, service or application pages generally prioritised.
The submitted page remains the authoritative exact-page result. Tools observed on another page widen the website-wide inventory but do not change the submitted page’s own result. Example: the homepage may show zero tools while /booking registers four. In that case AG AgentReady reports both facts separately.
A zero tool count is shown only when a runtime browser check completed and confirmed no qualifying tools. Failed, skipped, timed-out or unattempted checks remain unresolved and are not treated as zero.
AG AgentReady inspects registered tool definitions and available input schemas. It does not invoke tools, submit forms or complete customer actions.
The four research benchmark scores
- Revenue Readiness (45% of Overall) — whether a visitor can understand what is sold, where it is sold, and act on it: proposition and service clarity, service area, pricing signals, primary and above-the-fold calls to action, contact routes, quote, booking and lead-capture paths.
- Agent Readiness (30% of Overall) — whether a machine can parse and act on the site: semantic HTML landmarks, heading hierarchy, machine-readable contact details, labelled and parseable forms, unambiguous actions, JSON-LD structured data including LocalBusiness and Service types, agent-tool/WebMCP discovery signals, and technical hygiene.
- Trust & Clarity (25% of Overall) — whether the business looks credible and legible: testimonials, reviews, credentials, evidence of past work, complete contact details, business identity, policy pages, navigation clarity and content depth.
- Overall Website Readiness — the weighted combination of the three pillars above (45% revenue, 30% agent, 25% trust), rounded to a whole number.
These scores belong to the broader research benchmark model. They are not a claim that every signal in the benchmark contributes to the current runtime Agent Readiness assessment.
Each pillar score is the weighted average of its checks, expressed 0–100. Check weights reflect how much a signal typically affects a real buying or agent interaction, and they are fixed in code so two scans of the same content produce the same score.
Score bands
- 90–100 Excellent
- 70–89 Good
- 50–69 Fair
- 0–49 Needs Improvement
Bands are presentation only. They group scores for reporting and never change how a score is calculated.
Corpus eligibility
A scan enters the research corpus only when its status is completed and all four scores — Overall, Revenue, Agent and Trust & Clarity — are present. Queued, in-progress and failed scans are excluded, as are completed scans missing any score.
One website, one row
Websites are frequently rescanned. To stop repeat scanning from skewing an average, the corpus keeps only the most recent completed scan per website, ranked by completion time. Every aggregate on the research pages therefore has a denominator of distinct websites, not scans.
Domain normalisation
Before deduplication, each domain is lowercased and a leading “www.” is removed, so example.com, WWW.Example.com and www.example.com are treated as one website. Other subdomains are treated as distinct websites, because they usually publish different content.
Exclusions
An internal exclusion list holds domains that must never appear in research aggregates — our own sites, preview environments and obvious test targets. Excluded domains are removed after normalisation and before any figure is calculated. Adding a domain to that list is an internal operation and does not affect the owner's report.
Means and medians
For each score we publish both the arithmetic mean and the median across the corpus, rounded to one decimal place. Both are shown because a small corpus with a few very low or very high sites moves the mean much more than the median; where the two diverge, the distribution is skewed.
Finding-category prevalence
Every finding belongs to one category: revenue, conversion, trust, clarity, structured data, agent readiness, WebMCP or technical. A website counts towards a category when it has at least one finding in that category that is not marked positive — that is, an unresolved issue rather than a passed check. Prevalence is that count of websites divided by the corpus size. A website with five unresolved findings in a category still counts once.
Stable check failure rates
Each deterministic check carries a stable, namespaced identifier in code — for example conversion.primary_cta, structured_data.local_business or agent_readiness.semantic_structure. Only findings carrying such an identifier, and flagged as benchmark-eligible, are aggregated per check.
For a given check, the denominator is the number of corpus websites where that check was actually observed, and the numerator is the number where it did not pass. We publish the denominator alongside every rate, and we do not rank checks observed on very few websites.
Free-form finding titles are never aggregated as checks. Only code-defined identities are counted, so a wording change to a finding title cannot silently create or split a statistic.
Check versioning
Each stored finding records the check version that produced it, currently version 1.0. If a check's logic changes materially, the version is incremented rather than the identifier being reused, so historical results stay interpretable. Findings recorded before stable identifiers existed carry no identifier and are excluded from per-check rates while still counting towards score aggregates.
How agents can use AG AgentReady (two transports)
AG AgentReady exposes its public diagnostic capability to AI agents over two distinct transports. They are related capabilities, not the same protocol endpoint.
- In-page WebMCP — when a browser or agent runtime exposes document.modelContext, agagentready.com registers five tools while the page is open: run_website_scan, check_webmcp, get_scan_report, search_webmcp_directory and get_directory_listing. This is progressive enhancement: in a browser without WebMCP support nothing is registered and the site behaves exactly as before.
- Remote MCP server — a separate public Model Context Protocol server at https://agagentready.com/mcp for compatible external AI clients, offering run_website_scan, check_webmcp and get_scan_report. It requires no login.
Both transports call the same canonical public payload builders as the website itself, so a score, a WebMCP detection verdict or a directory profile reads identically however it was requested. Both are limited to public capability: paid or locked findings, private evidence, payment records, enquiry data, directory submission, moderation and account functions are never exposed as tools, and every scan runs through the same protected pipeline with public-address validation, per-domain limits, global ceilings and caching.
Privacy and anonymisation
Research pages publish aggregates only. Domains, website addresses, report links, email addresses, IP addresses, finding evidence, enquiry submissions and payment records are never published, and are never queried by the browser: aggregation runs server-side and returns only computed figures.
We are not claiming the underlying records are anonymous. Operational data — the scanned address, the report and its findings — remains stored internally so your report link keeps working, as described in our privacy policy. What is anonymised is the research output: nothing published identifies an individual scanned website.
Sample bias
This is a self-selected corpus of websites whose owners or users chose to scan them. It should be read as a directional benchmark, not a census of the entire web.
Websites reach the corpus because somebody chose to scan them, often because they suspected a problem. That plausibly biases the corpus towards weaker sites, and towards the sectors and regions we reach. Nothing corrects for that bias, so figures should be read as directional.
Changelog
- 1.0 — Initial published methodology. Three weighted pillars (45/30/25), four score bands, latest-completed-scan-per-domain corpus, domain normalisation with www stripping, internal exclusion list, mean and median reporting, category prevalence counted per website, and stable check failure rates with published denominators.
Run an Agent Readiness scan
Run a free scan to inspect your website's current Agent Readiness and observable agent-facing capabilities. Aggregate research from qualifying scans also contributes to the broader AG AgentReady research benchmark.
Run Free Website Scan