An agency that already builds and maintains websites owns most of the surface the agent readiness rubric measures. Adding it to the service list is mostly a matter of naming the work, deciding which checks you deliver yourselves and which you subcontract or brief, and being disciplined about what you claim for it. This post sets out that split, explains how the free scan and the public report can be used in a pitch, and is candid about the one check that is still a bet.
The rubric itself is public and versioned, 27 checks across four pillars, 25 points each, on /methodology. Why we publish the rubric explains the reasoning; the practical consequence for an agency is that the deliverable is defined by a document your client can read, which is a better basis for a scope than a proprietary score.
The checks an agency can own
Thirteen of the 27 checks are rated Low effort, and the three tiers of fixes describes them as hours of work. Nearly all of them are content or configuration, which is to say the things an agency with CMS access already does.
| Area | Checks | What the work is |
|---|---|---|
| Crawler access | A1, A2, A3 | A parseable robots.txt that permits the six named AI crawlers and references a valid sitemap |
| llms.txt | A4 | A root text file with three or more described links; an llms-full.txt for one more point |
| Meta and Open Graph | B4 | Unique titles of 15 to 70 characters, descriptions of 50 to 160, og:title, og:description and og:image on every page |
| Alt text | B6 | Non-empty alt on 80% or more of content images |
| Canonical hygiene | B7 | A self-consistent rel=canonical and one host across www, non-www, http and https |
| Identity and policies | D2, D3, D5 | A contact route, Organization schema with a sameAs, linked privacy and terms (shipping and returns for shops), a site name that agrees across title, og:site_name and schema, and a favicon and og:image that resolve |
| security.txt | D6 | A five-line file with a Contact and a future Expires |
| Transport | D1 | HSTS is a header; TLS is usually the host's |
Add to that the editorial parts of two Medium checks: link text for C2 (fewer than 5% contextless links) and heading discipline for B3 (one h1, no skipped levels). An agency that writes copy owns both.
That is a service: a start state (the scan report), an end state (the check definitions) and a verification step (a re-scan). Scope it as a fixed piece of work per site, and do not call it anything grander than it is.
The checks that need an engineer
The remainder touch rendering, forms, templates and infrastructure, and are rated Medium or High.
- A7, server-rendered parity, is the architecture check. If the client's site draws its content in the browser, nothing in the first list fully takes effect, because the agent never receives it. This is the one to test first and the one to be honest about: it can mean a framework change, and an agency that does not build in that stack should say so and bring a partner.
- A5 and A6, edge blocking and interstitials, are configuration, but the configuration lives in a CDN dashboard or a consent-management vendor the agency may not control. Get access, or get the client to make the change with you on the call.
- B1 and B2, structured data in templates, are Medium effort and well within a development agency's range. A content agency should brief them.
- C1, C3 and C6, forms, buttons and search, are template work with a definition of done the rubric spells out: labelled inputs, correct types, a real submit, button elements, a GET search form with a query parameter.
- C5, commerce actionability, applies to shops only and needs the storefront's cooperation: product pages within two clicks, Offer schema matching the page, a cart path returning 200 without login, and a guest or express checkout signal.
- D4 and D7 need a sitemap with honest lastmod values and a site that stays consistent across pages, which is a build pipeline question more than a content one.
The honest way to sell these is as a brief you write and a partner delivers, or as work you deliver when you have the engineers. The scan report makes the brief nearly automatic: check id, evidence block, recommendation, effort rating. If you would rather have the audit done by a person who reads the templates, that is our audit service,.
Using the scan and the public report in a pitch
Every scan produces a public report at /site/{domain}, generated from an unauthenticated crawl of the same pages any visitor sees. Each finding carries the evidence captured during the crawl, and a finding with no evidence is not published. That has two consequences for a pitch.
The first is that you can put the report in front of a prospect without being the one making the claims. The report says what it found and shows the request and the response. You are not asserting that their forms are unlabelled; the evidence block is.
The second is a discipline. Say what the report says and nothing more. "Your site scores 61, a C, and here are the four Low effort checks it is losing points on" is a sentence the report supports. "Sites like yours are losing customers to agents" is not, and we do not say it either. We have no published aggregate data, and neither do you.
Three surfaces help beyond the report itself. The leaderboard lists scanned sites by category, so a prospect can see the field they sit in. The compare page puts two scanned sites side by side, pillar by pillar and check by check, which is the most direct way to show a prospect what separates them from a named competitor, using only what the crawl found. And a site that scores a B or better can embed a badge; it is served only for listed sites at that grade, so it certifies something. Ours is the format; the SVG's alt text carries the score and grade.
Be honest about what is a bet
Most of the rubric measures things a crawler can use today. One check does not, quite. C4, "machine endpoints and agent manifests", 5 points and High effort, looks for an agents.json at the root that parses as JSON, and for three patterns in the homepage HTML: a reference to an OpenAPI or Swagger file, a reference to an MCP manifest or the Model Context Protocol, and a link to API documentation. One of those scores 3; two score 5.
The scanner can tell you whether those files exist. It cannot tell you which agents consume them, because that is still moving. An OpenAPI spec is a settled standard with real consumers. MCP has a published specification and shipping clients. agents.json and WebMCP are proposals with less settled adoption. We publish an agents.json, an OpenAPI spec and an MCP server on our own site because the cost is low, and the implementation page says which are consumed today and which are speculative. Sell C4 the same way: as a cheap, public position on a standard that may or may not settle, not as a channel with a measurable return.
More generally, do not promise revenue or results from any of this. The rubric measures whether a program can read, understand, act on and trust a site. It does not measure what happens after it does, and nobody has that number yet. The claim you can make, and back, is that the site will score higher on a published standard and that the score will be public.
Check your own site
Start with your own agency's site, because a prospect will. Run the free scan, fix the Low effort list, and put the report in the pitch. The full definitions are on the methodology page from discovery and access through trust and freshness.