Skip to content

GEO best practices for documentation sites and developer products

Short answer

AI tools quote docs they can fetch as plain text and match to the right version. Allow search and user-fetch crawlers, serve every page as server-rendered HTML with a Markdown twin, keep one canonical URL per version, and treat llms.txt as a cheap convenience rather than a ranking lever.

This guide is for people who run a documentation site, an API reference or a developer product. Developers now ask ChatGPT, Claude, Perplexity and coding assistants before they open your docs. The goal here is that those answers quote the current, correct page. Most of the work is a one-off engineering task of a few days, followed by habits in the release process.

  1. Let AI search crawlers and user-triggered fetchers reach the docs.
  2. Put the full text of every page in the server HTML.
  3. Offer a clean Markdown version of each page.
  4. Give each docs version one canonical URL and make “latest” obvious.
  5. Write code examples and reference pages that survive being quoted out of context.
  6. Publish changes in a dated, linkable changelog and keep sitemaps honest.
  7. Add llms.txt if your platform makes it cheap, and don’t expect it to move rankings.

Docs sites often sit behind the same bot protection as the app. That is the most common reason a good page never shows up in AI answers. Two kinds of bots matter: search crawlers that index pages ahead of time, and user-triggered fetchers that load a page when someone asks about it.

Many docs frameworks render navigation and content in the browser. A crawler that does not run JavaScript then sees an empty shell.

Check with curl -s <url> and search the output for a sentence from the body and a line of a code sample. Tabs, accordions and “copy” widgets should keep their content in the HTML, hidden with CSS rather than fetched on click. More in JavaScript rendering and AI crawlers and JavaScript sites (Next.js, Vue and others): making sure AI crawlers can read your content.

Markdown removes navigation, scripts and layout, so an assistant gets only the content. Several docs platforms now generate it automatically.

If you build your own site, follow the same pattern: page-url.md returns the source Markdown with headings and fenced code blocks intact. Keep it identical to the HTML page. A Markdown copy that drifts from the HTML is a second, stale version of your docs. Add a “Copy as Markdown” or “Open in ChatGPT/Claude” button only if it uses the same file.

Versioned docs create near-duplicate pages: /v2/auth, /v3/auth, /latest/auth. If an assistant quotes the wrong one, users copy deprecated code.

  • Pick one stable URL for the current version (for example /docs/auth) and point rel="canonical" there from /latest/ aliases.
  • Keep old versions online if users need them, but say so in the page title and first line: “Version 2 (deprecated). Current: v3.”
  • List only current-version pages in the sitemap and in llms.txt.
  • Put the version number and “last updated” date in visible text, not only in a dropdown.

Background: Canonical URL signals.

AI answers lift a paragraph or a code block and drop the rest. This section is our editorial advice, based on how docs get quoted, not on any platform’s documentation.

  • Make every code example complete: imports, package name, install command and version.
  • State prerequisites and the version near the top of each page, not only on an intro page.
  • Use one name per concept. If the SDK method is createClient, don’t call it “the init call” elsewhere.
  • Give each error message its own heading or table row, with the exact error string. Developers paste errors into assistants.
  • Write a one-sentence description under each H1 that says what the page is for.

The general writing guidance is in For content editors: writing articles AI answers can quote and Claim: content must be chunked and rewritten for AI search.

6. Date your changes and keep sitemaps honest

Section titled “6. Date your changes and keep sitemaps honest”

When an API changes, the old answer lives on in assistants until the new page is crawled again. A dated changelog with one URL per release gives crawlers and users a single place to learn what changed.

  • Give each release note its own anchor or page, with the date and affected versions.
  • Link from the changelog entry to the updated reference page, and back.
  • Set <lastmod> only when the content changes, not on every build. See XML sitemaps and XML sitemaps vs IndexNow.
  • When you deprecate something, edit the old page to say so. Don’t just delete it.

7. llms.txt: useful, but not a ranking lever

Section titled “7. llms.txt: useful, but not a ranking lever”

llms.txt is a proposed index file for language models. For docs it is a reasonable convenience, especially when coding tools or users load it on purpose. It is not a way to rank in AI search.

If your platform generates it, leave it on. If you build it by hand, generate it from the same source as the sitemap so it can’t go stale. Full evidence: Claim: llms.txt improves AI search visibility.

  • Don’t block all bots at the docs CDN. Search and user-fetch crawlers are separate from training crawlers (Configure robots.txt for AI crawlers).
  • Don’t serve different content to AI bots. Keep the HTML, Markdown and llms.txt in sync from one source. Google treats creating separate content mainly to game AI answers as risky (Scaled content abuse).
  • Don’t let /latest/ and /vN/ compete. Choose a canonical (section 4).
  • Don’t put examples only in images or interactive sandboxes. Keep a text version on the page.
  • Don’t treat llms.txt as the GEO project. It is one small item (Claim: llms.txt improves AI search visibility).
  • Prompt panel: keep 20–30 real developer questions (“how do I paginate with the X SDK”) and run them monthly. Check whether answers cite your docs and use the current version (Measuring AI visibility by sampling prompts).
  • Support tickets: tag tickets where the user followed an outdated AI answer. A falling count is the outcome that matters.
RecommendationEvidence
Allow search and user-fetch crawlersOfficial (OpenAI, Anthropic, Perplexity)
Server-rendered HTMLOfficial (Google) and observed (Vercel/MERJ, 2024)
Markdown version of each pageOfficial platform features (Mintlify, GitBook); effect on citations untested
One canonical per versionOfficial (Google canonical signals)
Self-contained code examples and error pagesHypothesis (our editorial advice)
Accurate lastmod and dated changelogOfficial (Google sitemaps) for lastmod; changelog structure is our advice
llms.txtOfficial: ignored by Google Search; observed: no measurable effect in one study

Sources

  1. Overview of OpenAI crawlersOpenAI · official · ✓ 2026-10-25
  2. Does Anthropic crawl data from the web, and how can site owners block the crawler?Anthropic · official · ✓ 2026-10-25
  3. Perplexity crawlersPerplexity · official · ✓ 2026-10-25
  4. Understand JavaScript SEO basicsGoogle Search Central · official · ✓ 2026-10-25
  5. The rise of the AI crawler (17 Dec 2024)Vercel & MERJ · industry · ✓ 2026-10-25
  6. How to specify a canonical URL with rel="canonical" and other methodsGoogle Search Central · official · ✓ 2026-10-24
  7. The /llms.txt filellmstxt.org · proposal · ✓ 2026-10-24
  8. Optimizing your website for generative AI features on Google SearchGoogle Search Central · official · ✓ 2026-10-24
  9. 你的公司还在 AI 的答案里吗:企业 GEO 行动指南 · 2026DATA17 AI Research Lab · 解数智能 · unpublished · 33 pp. · unpublished report, not publicly available; readers can't check it · ✓ 2026-10-26
  10. llms.txtMintlify · official · ✓ 2026-10-28
  11. LLM-ready docsGitBook · official · ✓ 2026-10-28
  12. Build and submit a sitemapGoogle Search Central · official · ✓ 2026-10-25
  13. AI Performance report (Bing Webmaster Tools help)Microsoft Bing · official · ✓ 2026-10-24