How to Make Product and Developer Documentation Easy for AI to Cite

Why does documentation matter so much for AI answers?

Developers and customers now ask assistants first. Stack Overflow's monthly questions, which peaked around 200,000 in about 2014, had fallen to early-2009 levels by May 2025. Its decline sped up after ChatGPT launched. When someone asks "how do I paginate results in [product]'s API?" or "why does [product] return error 429?", the answer is built from whatever the assistant can find. Ideally that is your documentation. Otherwise it is a forum post, an outdated blog or a competitor's comparison.

Coding agents raise the stakes further. They fetch a library's documentation to get an API call right, often in the middle of writing code. The updated llms.txt proposal says thousands of sites now publish an llms.txt file and documentation platforms generate one automatically. Chrome's Lighthouse checks for one in its experimental agentic browsing audits. Documentation that agents can read cleanly gets used in code. Documentation they cannot read gets guessed at, and a guessed API call is a support ticket waiting to happen.

What makes a documentation page easy to cite?

• One job per page or section. "Authenticate with OAuth", "Paginate list endpoints", "Error 1042: webhook signature mismatch". A page covering ten tasks forces the assistant to extract one, and it may pick the wrong one.
• The answer first. State what to do or what the thing is in the opening lines, then give detail, options and edge cases.
• Full names in the text. "In [Product] API v3, list endpoints return 100 items by default", not "By default, it returns 100 items". Passages are retrieved on their own, and a passage that says only "it" loses its meaning, as covered in how content chunking affects what LLMs retrieve and recommend.
• Versions and dates. Say which version a page applies to, and mark deprecated features clearly. Assistants mix versions when pages do not say.
• Code with explanation. Show a working example, then explain each part in prose. Code blocks alone give retrieval little text to match.
• Plain, server-rendered HTML. A 2024 study by Vercel and MERJ found none of the major AI crawlers rendered JavaScript. Docs whose content loads only by script are blank to them.
• Stable URLs and redirects. Assistants cite URLs they saw months ago. Keep old URLs redirecting to the current page.
• Crawler access. Check robots.txt and your CDN's bot settings for OAI-SearchBot, ChatGPT-User, Claude-SearchBot, Claude-User, PerplexityBot, Googlebot and Bingbot.

How to increase AI citations by rewriting a knowledge base as plain Q&A

Many knowledge bases are organised the way the company thinks, with pages such as "Workspace settings overview" and "Billing module". People ask in their own words, such as "How do I remove a user without deleting their files?". Rewriting around questions closes that gap:

1. Collect real questions from support tickets, chat transcripts, sales calls and site search logs. Keep the customers' wording.
2. Group them by task, and decide which deserve their own article and which belong as sections of a broader one.
3. Use the question as the heading, phrased the way customers ask it.
4. Answer in one to three sentences directly below, then give the steps, screenshots with text alternatives, and exceptions.
5. Name the plan or edition when the answer differs: "On the Business plan, admins can...".
6. Link related questions at the end, so the assistant, and the reader, can follow the task.
7. Retire or merge duplicates, so there is one current answer per question.

The format is not magic. What helps is that each question now has one clear, current answer, written in the words people use. That makes it easier to match to a question and safer to quote. Keep the rewrite honest. If the answer is "you can't do that on this plan", say so plainly, because an assistant that finds no answer will guess.

How to repurpose documentation into formats AI can parse and cite

Keep the HTML pages as the canonical version, since they are what search-based assistants cite. Then add formats that agents and tools can use:

Two cautions apply. None of these replaces the HTML pages, which are what AI search engines index and cite. And every copy must stay in sync. A stale llms-full.txt or an out-of-date OpenAPI file spreads wrong answers as fast as a stale page. Generate these copies from the same source in your build, rather than maintaining them by hand.

How do I make error codes discoverable in AI troubleshooting answers?

Error messages are among the most specific questions people ask assistants. They paste the exact text. To be the source the answer uses:

• Give each error its own page or anchored section, with the code and the exact message in the heading: "Error 1042: Webhook signature verification failed".
• Include the literal message as users see it, in text, including variants from different SDKs or versions.
• Explain the cause in the first sentence, then list fixes in order of likelihood.
• Show a failing and a working example where code is involved.
• Say which versions the error applies to, and what changed if the message was renamed.
• Keep the codes consistent across your API responses, SDKs, logs and docs. Where you can, include a documentation link in the error response itself, so the developer and any agent reading the log can go straight to the answer.
• Publish a single index of all errors, linked from each error page, so crawlers can find them.

Test by pasting your most common error messages into ChatGPT, Claude and Perplexity. If the answers cite a forum thread or guess, your error page is either missing, unreachable or not specific enough.

URL fragments for SaaS documentation: can AI engines cite the section behind a # URL?

They can link to it, but they cannot fetch it separately. The part of a URL after # is a fragment. Browsers do not send it to the server, so a crawler requesting docs.example.com/api#pagination receives the whole page. Google's URL guidance says Google Search generally does not support URL fragments, and advises against using fragments to change a page's content.

What this means in practice:

• Anchored sections on a long page are fine for navigation. An assistant can cite the page, and sometimes adds the anchor. But retrieval works on the page's text, so the section must make sense on its own.
• Single-page docs that load content by fragment are a problem. If #/pagination swaps in different content by JavaScript, crawlers see only the initial page. Use real URL paths instead, which Google recommends doing with the History API.
• Text fragments are different. Links containing #:~:text= ask the browser to scroll to and highlight a passage. Search engines have used them to point readers to the cited sentence. You do not create them; they work when the quoted text appears on your page exactly.
• Important topics deserve their own URL. If a section is asked about often, such as authentication or rate limits, give it a page, not only an anchor.

Does moving a help center into a subdirectory increase AI citations?

There is no evidence that it does. AI engines retrieve and cite pages, and a clear, current answer on help.example.com is as citable as one on example.com/help. Google's representatives have long said Google Search handles subdomains and subdirectories alike. No AI engine has said it prefers one or the other.

What moves can change, often for the worse:

• Every URL changes, so redirects must be complete and permanent, or assistants will cite broken links for months.
• Visibility can dip temporarily while search engines process the move.
• Platform constraints appear. Zendesk's host mapping supports subdomains of your own domain, such as support.example.com, not subdirectories. Intercom's documentation describes custom domains in the same way. Serving either under /help usually needs a reverse proxy, which adds a system to maintain.

Moving can be worth it for other reasons, such as one analytics setup, one navigation or a single design. But do it for those reasons, not in the hope of more citations. The same effort spent rewriting the fifty most-asked articles will usually do more.

Zendesk Guide vs Intercom Help Center for AI-citable support documentation

Both serve help articles as HTML that crawlers can read, so either can host citable documentation. The differences are in control:

For AI citations, the content matters far more than the choice between them. Check three things on whichever you use. Is indexing enabled? Are articles public rather than behind sign-in? Does the article text appear in the page's HTML source? If you need fine control of markup, templates or robots rules, a docs platform on your own domain gives more.

Mintlify vs Docusaurus for product documentation that AI assistants can cite

Both produce documentation that AI crawlers can read. They differ in who does the work:

Choose Mintlify if you want AI-facing features switched on without engineering work. Choose Docusaurus if you want full control and have engineers to maintain it. Either way, the page content decides whether you are cited. A well-written Docusaurus page beats a thin Mintlify page, and the reverse is equally true.

What is developer advocacy, and how does it help AI search engines cite a software company?

Developer advocacy, often called developer relations or DevRel, is the work of helping developers succeed with a product. That means writing tutorials, building sample projects, speaking at events, answering questions in community forums, and bringing developers' feedback back to the product team. It helps AI citations in three ways:

• It creates third-party evidence. Tutorials on other sites, conference talks, podcasts and community answers mention your product in context. Assistants lean on sources beyond your own site when deciding what to recommend.
• It produces working code in public. Example repositories and snippets on code hosting sites are material that assistants and coding agents learn from and cite. How repositories and curated lists earn citations is covered in whether GitHub repositories and awesome lists help earn AI citations.
• It finds the gaps. Advocates hear which questions developers cannot answer from the docs. Those are the questions assistants answer badly, and the pages worth writing next.

What it is not is posting links everywhere. Communities remove promotional posts, and inauthentic mentions are something Google's guidance warns against. The value comes from genuinely useful answers and code.

How can a developer check whether API documentation appears in Claude answers?

1. Use Claude with web search on, which the Claude apps offer. Anthropic says citations are always included when Claude uses web search, so you can see which pages it drew on.
2. Ask real developer questions, such as "How do I authenticate with the [product] API in Python?" or "What does [product] error 1042 mean?". Run each a few times, since answers vary.
3. Record whether your docs are cited, which pages, and what else is cited instead: forums, blogs, competitors' docs.
4. Check Brave Search for the same questions. Anthropic lists Brave Search as a subprocessor for web search. Profound's analysis of about 35,000 Claude citations found 79.2% came from Brave's top ten results.
5. Check your server logs for Claude-User, which fetches pages when a user asks, and Claude-SearchBot, which indexes pages for search. A 403 or challenge page for either makes it much less likely that Claude can read your docs, quote them accurately or cite them.
6. Test without search too. Claude's answers from its training knowledge show what it learned about your product, which may be out of date. Pages you publish now help future models, not this one.

Repeat the same questions in ChatGPT, Gemini and Perplexity, since each uses different sources. How to track whether coding agents pick your tool over competitors is covered in how to track whether AI agents choose your developer tool over competitors.

How do you keep documentation citable over time?

• Review the most-visited and most-asked pages each quarter, and check them against the current product.
• Update the changelog with every release, and link it from the pages affected.
• Add a page when support answers the same question three times.
• Watch for citations of outdated pages in AI answers, and fix or redirect them.
• Regenerate Markdown copies, llms.txt and OpenAPI files in every build.

What might an illustrative case look like?

Consider an illustrative payments API company whose documentation was a single-page app with sections loaded by fragment. Assistants answered questions about its webhooks by citing a three-year-old community thread. The company moved to a static docs site with a page per task and per error code, and added Markdown copies and an llms.txt index. It rewrote its thirty most-asked support articles as question-led pages with one-sentence answers. It also found that Claude-User requests were blocked by its bot protection, and fixed that. Two months later, Claude, ChatGPT and Perplexity cited its webhook and error pages for most of its test questions. Support tickets about signature errors fell by about a third.

What do people ask about documentation and AI citations?

Does llms.txt improve citations in AI search?

There is no evidence that it does for search-based answers, and Google says it does not use it. It helps agents and tools that look for it, which is a reasonable reason to keep one.

Should documentation be public to be cited?

Yes, for public answers. Pages behind sign-in are invisible to AI crawlers and web search, so they are much less likely to be cited in anyone else's answers; only a signed-in user's own assistant, through an authenticated docs connector or a browser agent, can read them. Keep reference material public and gate only account-specific content.

How long should a documentation page be?

As long as the task needs and no longer. One task or concept per page usually keeps them short enough to cite cleanly.

Should we write docs for AI or for people?

For people. Clear, specific, current pages serve both, and the extra formats for agents come from the same source.