Short answer
The problem is usually source selection, not a missing AI-search trick.
Before adding a new optimisation layer, I check whether an agent can reach the intended page, understand the question it answers, extract a passage that makes sense on its own, identify the canonical source, and follow the surrounding context. That brings the work back to familiar web decisions: clean URLs, a current sitemap, deliberate crawler rules, direct headings, descriptive links, accurate structured data, and a short llms.txt file when it is useful. I use AESO as shorthand for that combined check. The acronym matters less than making the intended source easier to retrieve and harder to misread.
01 · When to pay attention
I look for six signs that the answer exists but the wrong page is winning.
- 01
An AI answer links to an outdated version even though the current documentation exists.
- 02
A useful answer is buried under a vague heading, a long introduction, or navigation that only works after JavaScript runs.
- 03
Several pages define the same product, feature, or API with different names.
- 04
Priority guides appear in the sitemap but have no useful path from a pillar page or related documentation.
- 05
Structured data describes content that is incomplete, contradictory, or not visible on the page.
- 06
The team has published llms.txt as a large second sitemap without deciding which sources actually matter.
02 · Working method
My working model has four parts: route, structure, connect, test.
I start with the pages that should answer real questions. I do not begin by adding schema to every template or copying the sitemap into llms.txt. First I decide which sources deserve to be found and which page should win when several overlap. Commercial search work applies similar discipline to a wider market: an AESO agency may track which brands appear across answer engines, while this documentation model asks whether a defined question retrieves the intended technical source.
Foundation and routing
Check public access, server-rendered output, canonical and sitemap agreement, redirects, version handling, and orphaned pages. Classify each priority page as create, refresh, fix, defend, or ignore so technical work follows an editorial decision.
Answer structure
Give each important section a heading that names the question. Put the direct answer first, then the conditions, evidence, examples, and procedure. A passage should remain understandable when it is retrieved without the paragraphs above it.
Entities, links, and schema
Use stable names and identifiers for products, authors, APIs, versions, and concepts. Connect pillar, support, and sibling pages with descriptive anchors. Apply the schema type that matches the visible page instead of stacking unrelated types.
Context packaging and testing
Use llms.txt as a curated guide to the strongest canonical sources, not an inventory. Then run a repeatable prompt bank and record the answer, cited URL, wrong-version rate, and missing-source cases before deciding what to change.
03 · Comparison
robots.txt, sitemap.xml, structured data, and llms.txt solve different problems.
| Signal | Its job | What it does not prove |
|---|---|---|
| robots.txt | Communicates which URLs compliant crawlers may access. | It is not an access-control system and does not guarantee that a URL stays out of search results. |
| sitemap.xml | Lists canonical, indexable URLs that crawlers should know about. | It does not explain which page best answers a question or provide a compact context set. |
| Structured data | Adds explicit machine-readable information about the visible page and its entities. | It cannot repair weak, hidden, contradictory, or outdated content. |
| llms.txt | Proposes a concise Markdown guide to a site and selected detailed sources. | It is a proposal, not a universal discovery protocol or a ranking and citation guarantee. |
Practical sequence
Here is the sequence I would use on a real documentation set.
- 01
Choose the sources that should win
List the priority questions, intended canonical pages, current versions, owners, and evidence. Check access, rendering, canonicals, sitemap entries, redirects, and duplicate answers.
- 02
Route and rewrite priority pages
Classify pages as create, refresh, fix, defend, or ignore. Rewrite the highest-value sections with direct headings, first-sentence answers, consistent names, and passages that stand on their own.
- 03
Repair the graph
Connect pillars to support pages, supports back to pillars, and useful siblings to each other. Add breadcrumbs and accurate schema for the visible content. Remove generic anchors and dead ends.
- 04
Package and test the context
Publish a short llms.txt file if it serves the site, link to the best canonical sources, and test a fixed prompt bank across the answer engines that matter. Record a baseline before iterating.
What I would measure
The only useful test is whether the intended source is retrieved.
I would not call an extra file or a larger schema graph a result. I would look for a smaller wrong-source rate, fewer orphaned priority pages, clearer version selection, and more target questions answered from the page the team intended. Keep the prompts, retrieved URLs, and release date together. When the result changes, there is a record to investigate. For adjacent commercial work, this agent search optimisation agency uses an audit to map answer-engine visibility, cited sources, and the pages that should be strengthened.
Primary sources
Primary specifications and implementation guidance.
Questions
Questions I would settle before calling documentation AI-ready.
Is AESO an official standard?
No. I use AESO as a working audit name that combines established web practices with the llms.txt proposal and retrieval testing. Teams may use different names for similar work. The value is in the checks and measurements, not in presenting the acronym as settled industry terminology.
Does llms.txt guarantee that an AI engine will cite my documentation?
No. llms.txt is a proposal for giving models concise context and selected links at inference time. Support and retrieval behaviour vary. Publish it when a curated guide is genuinely useful, then test whether the tools your users rely on retrieve it and follow the intended sources.
Is structured data enough to make a page citeable?
No. Structured data can describe a page and its entities, but the visible answer still needs to be accurate, specific, current, and easy to extract. Markup should match the page. It should not be used to hide claims or invent completeness.
Should every documentation page have a Markdown copy?
Not automatically. The llms.txt proposal recommends clean Markdown alternatives for useful linked pages because they are compact and easy to parse. Start with the canonical sources selected for retrieval, confirm the copies stay synchronized, and avoid creating a second stale documentation system.
What should an AESO audit measure?
Track the target prompts, intended source, actual cited or retrieved URL, wrong-version cases, unsupported answers, orphaned priority pages, click depth, schema validity, broken links, and the freshness of curated context files. Record a baseline before changing the site.