Getting your API docs cited when someone asks an AI about your product
People are asking assistants what your API does before they visit your site. What gets quoted back is decided by how your docs are structured, not by a file at your root.
A developer evaluating your API in 2026 often does not start on your website. They ask an assistant whether your product does the thing they need, and they get an answer with citations. If your documentation is not in that answer, you were not in the evaluation.
This has produced a lot of advice about publishing llms.txt, and that file is worth having. It is also not the mechanism. A file listing your pages does not make a model quote them any more than a sitemap makes Google rank you. What decides whether you get cited is whether a retrieval system can find a passage in your docs that answers the question on its own.
That is a structural property, and it is mostly the same property that makes documentation good for humans in a hurry.
Retrieval reads passages, not pages
The thing to internalise is that your page is not the unit. A chunk of it is.
Retrieval systems split documents, embed the pieces, and pull back the ones that match a query. What gets quoted is a section, lifted out of its page and away from its navigation, its breadcrumbs, and everything above it on the page.
Which means a section that only makes sense in context does not get cited, because out of context it does not answer anything.
Bad: ## Configuration
Set this to `true` to enable it. The default is `false`.
Good: ## Enabling webhook signature verification
Set `verifySignatures` to `true` in your webhook settings to reject
payloads whose HMAC does not match. The default is `false`, which
accepts any payload. Enable it before going to production.The second one survives being extracted. The first one is meaningless the moment it leaves the page it was on.
The practical rule: every heading should name the question it answers, and the first sentence under it should answer that question without depending on the sentence before the heading.
Write the answer before the argument
Documentation often builds up to the answer. Context, then reasoning, then the resolution. That is fine reading and it is poor retrieval, because the chunk that gets embedded may be the context rather than the resolution.
Lead with the answer, then explain. It helps the model and it helps the person scanning at 2am, who is the same reader with less patience.
The things that actually get asked
If you want to know which pages to invest in, the questions assistants get asked about APIs are boringly consistent:
- Does it support X?
- How do I authenticate?
- What are the rate limits?
- Is there an SDK for my language?
- How much does it cost?
- Why am I getting this error?
Every one of those should have a page whose heading is roughly that question and whose first paragraph answers it. The pricing one is worth calling out because it is the question most often answered with a marketing page that does not contain a number, which means the model has nothing to quote and either says it does not know or infers something wrong.
The errors one is the highest leverage and the least done. An errors page listing your actual error codes with what each means and what to do is the page most likely to be retrieved, because "why am I getting invoice_not_payable" is a query with exactly one correct source.
Freshness is a ranking signal here in a way it is not in classic search
An assistant that reads your live documentation gets what you published today. An assistant working from training data gets your API as it was whenever the crawl happened. The gap between those two is your exposure.
The practical consequence is that a changelog is not a courtesy page, it is the artifact that tells a retrieval system your API has moved since whatever it remembers. Date the entries, mark breaking changes explicitly, and keep it on the same host as your docs so it is retrieved alongside them.
Stable URLs matter for the same reason. A citation is a link, and a link that 404s after a docs restructure costs you the citation and the trust. If you reorganise, redirect.
What structured data does and does not do
Marking up your docs with schema.org types is worth doing and is not magic. It helps a machine understand what kind of thing a page is, which improves retrieval precision at the margins. It does not make a thin page quotable.
The two that earn their place for documentation are TechArticle on guides and BreadcrumbList for the trail, because the trail is what tells a system where a page sits in a hierarchy it cannot see from the URL alone. If you publish an FAQ, FAQPage is still worth emitting even though it no longer earns a rich result in Google, because assistants read structured data directly.
The honest position on llms.txt
Publish it. It costs an afternoon, it is a reasonable map of your site, and the cost of not having one if adoption grows is higher than the cost of having one if it does not.
Do not expect it to move anything on its own. Adoption sits somewhere in the single-digit-to-mid-teens percent of technical sites, Google has said plainly that Search does not use it, and no major crawler has committed to it as a standard. It is a pointer, and a pointer is worth exactly what it points at.
The work that pays is the structural work above: sections that answer questions on their own, real numbers on the pages where people expect numbers, an errors page, and a changelog that proves the docs are current.
Where generation helps and where it does not
Generated reference pages are already well suited to this. Each endpoint is a self-contained unit with a stable URL, a complete parameter list and a response shape. It is close to the ideal retrieval chunk, and it stays accurate without anyone maintaining it.
What generation cannot give you is the page that answers "should I use this API" or "what do I do when it fails". Those have to be written, and they are the ones that get cited when the question is not about a specific endpoint.
So the split is the same one that has always applied: generate the reference so your writing budget goes to the guides. What belongs in API docs that OpenAPI cannot generate covers which guides are worth the budget, and your changelog is part of your API covers the one most people skip.
If you want the reference half handled so you can spend your time on the rest, that is what Octri does with your spec: reference pages, per-page metadata, breadcrumb structured data and an llms.txt that stays in step with your navigation, all rebuilt when the spec changes.
Sources: llms.txt guidance and adoption, 2026 · What Google has said about llms.txt
