An agent asked whether a product does something, what it costs, or how to get started fetches three pages: the documentation, the pricing page and the signup form. Everything else on a software company's site is context for those three. The rubric's crawler makes the same assumption, ranking /pricing first and /docs third when it chooses which five pages to fetch after the homepage. This post covers what each of the three has to do, which checks score it, and why C4, the check most sites score zero on, is the cheapest differentiator a SaaS has, because the thing it asks for already exists.
How a SaaS gets typed, and what that changes
Site type is read from the homepage's raw HTML. A SoftwareApplication in the JSON-LD types the site SaaS directly. Failing that, the word "pricing" followed on the same line by "per month", or the phrase "free trial" or "start free", does the same. Either way the shop tests run first, so a homepage that mentions a cart or "add to cart" is typed e-commerce before the SaaS tests are reached.
Once typed SaaS, C5 is marked not applicable and its four points are spread across C1 to C4 in proportion to their weight. The effect is that C1 and C4 are each scored out of 6.11 rather than 5, and C2 and C3 out of 4.89 rather than 4; how C5 redistributes has the arithmetic. For a SaaS the practical consequence is that a machine endpoint and a usable signup form each carry a little more weight than they would on a shop.
B2 changes with the type too. Two points for an Organization or WebSite anywhere in the crawl, and three points if the set of types found contains SoftwareApplication, Article, FAQPage or Service. A SoftwareApplication on the homepage does double duty: it settles the type and earns the three points in one block. Give it applicationCategory, operatingSystem and, where the price is public, an offers value carrying the monthly price.
Pricing
The pricing page is where an agent reads a number and decides whether to keep going. Two things matter, and neither is the design of the tier cards.
The first is that the prices are in the raw HTML. Pricing pages are the most common place for a client-side component to fetch a plan list and draw it after load, often with a currency or a billing-period toggle that only works once JavaScript has run. An agent doing a plain fetch gets the tier names and none of the figures. A7 measures this gap on the homepage only, as of v1.0.1, so a pricing page that renders empty does not show up in that check; it shows up when a prospect's assistant reads the page and reports that the pricing was not stated. The two fetches shows how to compare the raw and rendered versions of any URL with curl.
The second is a FAQPage block on the pricing page. Pricing pages almost always carry a list of questions about billing, seats and cancellation, and that list is exactly what an agent is asked about. Marking it up scores under B2 and gives an agent a question-and-answer structure instead of prose to parse.
Signup
The signup form is scored by C1, which is worth 6.11 points on a SaaS report after redistribution. Every input needs a label, an aria-label or an aria-labelledby; a placeholder is not a label. An input whose name or id mentions email must be type="email", and one that mentions phone must be type="tel". The form needs a real submit button, a button with type="submit" or no type at all, or an input type="submit". Forms an agent can fill covers each rule and the evidence fields.
One detail specific to SaaS. The crawler fetches same-origin pages only. If signup lives at app.example.com and the marketing site has no other form, the crawl finds no forms at all, C1 awards partial credit of 3 out of 5, scaled to 3.67 out of 6.11, and the report says form usability could not be assessed. That is not a penalty, but it is not the points either. A signup or a contact form on the marketing origin, built to the rules above, is how a SaaS earns the full check.
Documentation
Documentation is the page an agent fetches most, because "does it do X" and "how do I do Y" are the questions people ask assistants about software. Two things decide whether it can be read.
Parity again. Documentation built as a single-page application, with a shell in the HTML and the content fetched by a script, gives a plain fetch a sidebar and nothing else. Most documentation tools render to static HTML by default, and the ones that do not usually offer a mode that does. Check the raw fetch of a docs page yourself, because if the docs are on a subdomain the scan never fetches them and A7 does not see them. Agent readiness for documentation sites goes through the common tools one at a time.
Dates. A changelog, or a dateModified on each docs page in an Article block, is the visible-date signal under D4, and a docs section that updates with each release keeps the 90-day window comfortably.
C4, the cheap differentiator
C4 is worth 5 points, 6.11 after redistribution, and accepts four surfaces: a valid JSON agents.json at the root, or any of three patterns in the homepage's raw HTML. An href containing /docs, /doc or /api-docs, or a hostname beginning developer. or developers., counts as an API documentation link. The string openapi.json, openapi.yaml or openapi.yml, or a swagger equivalent, counts as an OpenAPI spec. /.well-known/mcp, mcp.json or modelcontextprotocol counts as an MCP manifest. One surface scores 3 points; two or more score the full 5. The evidence field is found, listing which surfaces the crawler saw.
Most sites score zero here because they have no API and nothing to describe. A SaaS has an API. It usually has developer documentation and often has an OpenAPI document already, generated by the framework or maintained for the SDKs. What it typically lacks is a reference to either from the homepage. The scan tests the homepage HTML, not the docs site, so an OpenAPI document that lives at developers.example.com/openapi.json and is linked from nowhere else scores nothing, while a footer link on every page labelled "API reference" pointing at /docs/api plus a link to the spec file scores 5.
For a SaaS whose product has no public API, publishing an OpenAPI spec for a site that has no API describes a read-only document over the plan list, which is the data an agent asks about most. Our own spec at /api/v1/openapi.json and the human-readable /docs are the two surfaces on our homepage.
Fixes in order of effort
| Order | Fix | Checks | Effort |
|---|---|---|---|
| 1 | Add footer links to the API documentation and to the OpenAPI document, on every page | C4 | Minutes |
| 2 | Add a SoftwareApplication block to the homepage JSON-LD, with applicationCategory, operatingSystem and offers |
B2 | Under an hour |
| 3 | Label every signup input, use type="email", make the submit a real button |
C1 | Under an hour |
| 4 | Add a FAQPage block to the pricing page |
B2 | Under an hour |
| 5 | Publish an agents.json pointing at the spec and the docs |
C4 | An hour |
| 6 | Render prices into the HTML rather than fetching them after load | A7 | Template work |
| 7 | Move documentation to a static or server-rendered build | A7 | Depends on the tool |
The first five are an afternoon and take C4 from zero to full marks. The last two are where a client-rendered marketing site spends real engineering time, and they decide whether the three pages an agent wants can be read at all.
Check your own site
The free scan records the detected site type, the found list under C4, the schema types collected for B2 and the raw and rendered text lengths under A7. The SaaS leaderboard shows other software companies on the same checks, and the definitions are on the methodology page under understanding, actionability and discovery and access.