GEO for Documentation: Getting Your Docs Cited by AI Answers

Generative engine optimization (GEO) is the practice of structuring content so that AI systems — ChatGPT, Perplexity, AI Overviews, coding assistants — retrieve it, ground their answers in it, and cite it. Where SEO competed for position on a results page, GEO competes for presence inside the answer itself. The unit of competition has changed: not the page, but the passage; not the click, but the citation.

For documentation teams this is not a marketing curiosity. Developers increasingly ask an AI assistant instead of opening your docs, and the assistant answers whether or not your content is retrievable. If it answers from stale training data, users configure deprecated endpoints. If it answers from a competitor's content or a five-year-old forum thread, users learn workarounds you fixed two releases ago. You get the support tickets either way — GEO is the discipline of making sure the answer people receive about your product is the one you wrote.

Generative engines are RAG systems at web scale. The pipeline is recognizable to anyone who has built one: retrieve candidate passages for the query, rank them for relevance, then synthesize an answer from the passages that survive — and cite them. Every stage is a filter your content must pass. It must be crawlable and cleanly parseable to enter the index; it must match the query semantically or lexically to be retrieved; it must read as relevant when a reranking model examines the question and the passage together; and it must be extractable and self-contained enough that the synthesis step can quote or paraphrase it without dragging in the rest of the page.

This selection process rewards different properties than link-ranking did. A page can rank #1 in classic search — strong domain, heavy backlinks — and still be uncitable, because its actual answer is smeared across six paragraphs, locked inside a screenshot, or dependent on context established three sections earlier. Conversely, a modest page whose second heading asks exactly the user's question and answers it in the first sentence beneath is a citation magnet. Authority still matters at the margins; extractability decides the outcome.

What makes a documentation page win citations is mostly writing discipline, applied with retrieval in mind:

Two files decide how AI systems treat your site at the door: robots.txt and llms.txt. The older one, robots.txt, says which crawlers may fetch which paths, and the major AI vendors document that they follow it. The catch is that each vendor now runs several crawlers for different jobs, and blocking the wrong one costs you citations.

Each rule is independent. You can allow search crawlers and block training crawlers, or allow both. For public documentation, allowing both is a reasonable default: training is how a model learns your product exists, and search is how an engine cites your current page instead of what the model remembers. Check your CDN and firewall too, because a bot rule there can block a crawler that your robots.txt allows. kelu.dev allows both groups and names each crawler in its robots.txt. The vendors' own crawler docs sort them into three groups:

llms.txt is newer and less settled. It is a proposed markdown file at the root of a site that summarizes what the site is and links to the pages that matter most, so a language model can find them without parsing navigation. Support for it varies by engine. Google says Google Search, including AI Overviews and AI Mode, doesn't use llms.txt or other special AI files. The crawler documentation from OpenAI, Anthropic and Perplexity doesn't mention it.

It is cheap to publish and does no harm, so many docs sites ship one. kelu.dev publishes its own at /llms.txt. Just don't expect it to move citations on its own. Clean, crawlable pages that answer real questions still do most of the work.

The most common objection is that optimizing for machines will degrade the docs for people. The opposite is true, and it is worth seeing why: the properties above — answer-first sections, question-shaped headings, self-containment, text over screenshots — are exactly what a hurried human skimming your page at 2 a.m. wants too. GEO is not a new genre of writing; it is the old technical-writing virtues, now enforced by an unforgiving reader. The retriever is simply the least charitable audience your docs have ever had: it will not infer, backtrack, or squint at an image. Writing that survives it is writing that serves everyone.

The second objection is that citations without clicks are worthless — if the AI answers from your docs, nobody visits them. But for documentation the goal was never traffic; it was correct users. A developer whose assistant cites your current auth guide integrates correctly and never files the ticket. The docs did their job invisibly, which is what docs at their best have always done. The metric that matters is not sessions; it is whether the answers circulating about your product are yours.

Classic keyword research fails here, because people phrase questions to an AI differently than they type search queries — longer, more conversational, more specific, full of their own vocabulary rather than yours. The best source of real question phrasing is a grounded assistant running over your own docs: every question users ask it is logged verbatim, and the knowledge-gap analytics show which of those questions your content failed to answer. That log is GEO research of a quality no external tool can produce — actual users, actual words, actual failures.

Use it in both directions. Questions your assistant answers well but that use unexpected vocabulary tell you which synonyms and phrasings your headings should absorb. Questions it cannot answer at all are pages that do not exist — gaps that open-web engines will fill with someone else's content if you do not fill them first. Doc proposals generated from recurring gaps give writers a running start on exactly the pages retrieval demand has already voted for.

This creates a practical priority order for a GEO program. Do not begin with a site-wide rewrite; begin with the twenty questions users ask most, verify that each has a page whose heading matches the question and whose first sentence answers it, and fix the ones that fail. Then work down the ranked list. GEO rewards coverage of real questions far more than polish of arbitrary pages, and the question log is the only honest ranking of which pages those are.

GEO on the open web is influence, not control — you can improve your odds but never guarantee the citation, and you cannot stop an engine from blending your passage with a wrong one. On your own surfaces you can do better. Run a grounded assistant over your docs on your site — widget, sidebar, or Cmd+K — so the users already on your pages get answers from hybrid search and reranking over your live index, with enforced abstention instead of improvisation when the docs do not cover a question. On the surface you control, every citation is yours.

Then extend the same control into the tools where developer questions now live: expose your knowledge base as an MCP server, so Cursor, Claude, and other MCP-capable clients call its search and ask_question tools against your current documentation instead of guessing from training data. One authenticated endpoint in your getting-started guide turns every AI-native tool your users run into a distribution channel for your docs.

The strategy converges on a single investment. Docs written to be retrieved — answer-first, question-headed, self-contained — serve your own RAG assistant, your MCP endpoint, and the open generative engines with the same words. You are no longer writing pages and hoping people find them; you are publishing the corpus that every answer engine, including your own, will quote. That is what documentation is becoming: not a destination, but the source of record for machines that answer on your behalf.