A renewal call goes sideways one afternoon. A customer you have kept for years mentions that their procurement assistant shortlisted vendors for a sister team, and your product was not on the list. You check the obvious suspects: you rank first for the category on every search engine, and your API covers more of the job than either product the assistant proposed. Then you read your site the way the assistant did. The pricing page is an interactive calculator that renders as an empty frame without JavaScript. The capability matrix is a PNG exported from a slide deck, and the rate limits appear once, in a video walkthrough. Every fact a machine reader needed was on your site, and not one of them was readable.
The tool interface is the storefront: design actions agents choose designed the actions an agent calls once it chooses you. This chapter covers the step before the choice: whether the agent assembling the shortlist can find you and extract the facts it compares. Discoverability for machine readers is a different discipline from SEO, and a product can fail it without anyone noticing, because an agent that moves on leaves nothing in the logs you watch.
The path an agent walks
A person shopping for software wanders through ads, review sites, brand memory, and a demo call. An agent walks a short, repeatable path, and every stop on it is something you publish.
- The user asks for an outcome. The request is "get these invoices reconciled," not your product name; the category term you optimized for may never appear.
- The agent searches and reads. It pulls whatever machine-readable material it can reach: documentation, registry entries, manifests, structured listings; marketing pages mostly come through as noise.
- It builds a shortlist from structured facts. It compares capabilities, limits, authentication, and price basis, and a fact it cannot extract gets treated as absent, so the comparison covers only the facts each vendor made readable.
- It tries the docs. The pick stays provisional until the agent completes the task, or its first step, from public documentation. Where it stalls, it does not book a demo or file a ticket; it moves to the next candidate.
An agent cannot choose a product it cannot read: the shortlist is built from extractable facts, and a fact locked inside a screenshot, a video, or a rendered widget is absent from the comparison.
Every stop on that path is a page, a file, or a listing you control, so discoverability is product work rather than a marketing request.
Make every fact in your docs machine-readable
For a machine reader the documentation is the sales floor, and the test of a page becomes whether a parser can extract it, not whether a person can follow it. The moves are unglamorous.
- Serve clean text at stable URLs. Markdown or plain HTML that arrives complete from the server, not a page that renders its facts only after scripts run, at URLs that survive reorganizations, because cached answers and registry entries point at old paths for months.
- Free the locked facts. Every fact that lives only inside a screenshot, a video, a slide export, or an interactive widget needs a plain-text twin; pricing calculators and capability matrices are the usual offenders.
- Publish the one-pager. One page of structured text stating what the product does, which actions exist (endpoints, tools, operations), the limits that matter, and what things cost, on what basis. This is the comparison you want the agent to run, published before it assembles a worse one from fragments.
llms.txt: cheap insurance, not a ranking lever
A convention exists for exactly this reader: llms.txt, a plain-markdown file at the root of your site that gives machine readers a curated map of your documentation, the pages that matter with a one-line description each. Plenty of sites publish one, and documentation platforms generate the file automatically, but the reading side is uneven: none of the major assistants document fetching it. Treat it as cheap insurance, an afternoon of work that hands your best pages to any client that does read it, never a ranking lever or a substitute for docs that parse on their own. The adoption picture changes quarter to quarter, so the current state lives in the dated Interop Ledger.
Get listed where defaults get made
Readable docs decide how an agent compares you; a registry entry decides whether it finds you at all. An MCP server manifest (the file that tells any client speaking the Model Context Protocol which tools you expose and how to authenticate) is a storefront address, and a directory layer has formed around those manifests: an official protocol registry, connector directories inside the major assistant clients, and curated lists that agent frameworks pull from. Those directories are where default choices get made, because a client that already lists you offers your product before its agent searches the open web.
Treat the entries as distribution work, held to the bar of an app-store listing:
- Present. You are in the official registry and in the directories of the clients your customers run; each missing listing is a channel where your product does not exist.
- Versioned. The listed manifest matches the deployed server, and superseded versions get retired rather than left to mislead clients still reading them.
- Accurately described. The listing says what your tools do in the words a user's request would use, because the client matches your description against the outcome the user asked for.
Put a person's name on the entries and review them at every release, because a listing owned by "the team" drifts the way ungoverned docs do.
Write claims an answer engine can verify
SEO taught teams to win a ranking, earn the click, and let the site do the closing. An answer engine removes those steps: it does not return a page of links for a person to pick through; it reads the candidates, extracts what it can check, and recommends, often one product with reasons attached. Industry forecasts already show a meaningful slice of search volume moving to assistants; the hard numbers, which move quarter to quarter, live in the Interop Ledger.
That pipeline changes what counts as persuasive. Your comparison-page superlatives are invisible in it, because "blazing fast" and "enterprise-grade" cannot be extracted, checked, or compared, while your limits table travels whole: concurrency ceilings, data residency, and an honest price basis all quote cleanly.
Structured, verifiable claims beat adjectives: an answer engine can quote your limits table, and it can do nothing with "blazing fast."
The measure that replaces the ranking report is a completion test: an agent finishes one real task from your public docs alone, with no human filling gaps. And because agents re-run the comparison at every renewal, a stale public fact now costs sales rather than support tickets; an agent will find and compare the price basis you updated everywhere except one old page. Give every public fact an owner, a shelf life, and a recall path, starting with the pages that state limits and pricing.
Try it now
This drill takes about half an hour with the assistant you already use, and it produces your first list of discoverability bugs.
Pick your product. Use your own if you can change its docs, otherwise one you know well enough to catch errors about.
Draft the answer key. On one page, from your own head, write what the product does, which actions exist, the limits that matter, and the price basis. This is the machine-readable summary the public docs should be able to reproduce.
Hand an agent the docs. Start a fresh session, give it only the public documentation, and ask it to complete one real task end to end: the exact steps, requests, and parameters, plus every fact it relied on. Give it no hints and fill no gaps by hand.
Log every stall. Compare the run against your answer key and mark each place the agent stalled, invented a parameter, or returned a wrong or missing fact. Each mark is a discoverability bug with an owner: the fact exists, and an agent starting from your public docs cannot read it.
Scale it down: if a full task run costs more than you want to spend, ask the assistant only to reproduce your one-pager from the public docs; the gaps between its version and yours are the same bugs at lower cost.
Chapter Summary
- An agent cannot choose a product it cannot read: the shortlist is built from extractable facts, and a fact locked in a screenshot, a video, or a widget is absent from the comparison.
- The path an agent walks, from outcome request to search to shortlist to a trial of your docs, is made of pages, files, and listings you control.
- Serve docs as clean text at stable URLs, and publish one page stating what the product does, which actions exist, the limits, and the price basis.
- Publish an llms.txt map as cheap insurance, but no major answer engine commits to reading it, and it does not substitute for docs that parse.
- Registry and directory entries are where default choices get made; keep them present, versioned, and accurately described, with an owner and a per-release review.
- Answer engines quote and recommend instead of ranking links, so verifiable claims travel and adjectives vanish.
- A stale public fact now loses deals silently instead of raising tickets, so limits and pricing pages get the shortest shelf lives.
- The test that matters is completion: an agent finishes one real task from your public docs alone, run on a cadence because the failure leaves no trace.
- Once the agent picks you, it arrives carrying someone else's permissions, which is where Delegation: check whose authority the agent carries picks up.
Sources
- Answer.AI (2024). The /llms.txt file: a proposal for LLM-readable site maps (last verified July 2026).
- Anthropic (2025). Model Context Protocol Registry announcement and documentation (last verified July 2026).
- Gartner (2024). Press release predicting a decline in traditional search engine volume as consumers shift to AI assistants.
- Cloudflare (2025). Radar reporting on AI crawler and referral traffic.