12 AEO Best Practices for docs Expo's documentation team has adopted Answer Engine Optimization (AEO) practices to make its docs more accessible to AI coding agents, which now build a significant portion of React Native and Expo apps. A key change was adding support for an `llms.txt` file, a curated text index that helps agents fetch and navigate documentation efficiently. The team outlines strategies such as optimizing for retrieval paths over training data and ensuring agents can find the right pages without rendering in a browser. If you've watched a coding agent quietly read your documentation, run a command based on what it found there, and never once render the page in a browser, you've seen the audience this post is about. Nobody clicked a link. Nobody looked at your carefully designed nav bar. An agent fetched a URL, parsed it, and acted. In January 2025, we made a small change to Expo documentation https://docs.expo.dev/ that turned out to matter more than we expected at the time: we added support for a curated text file served publicly, called llms.txt . Back then, adding llms.txt to a site was a fringe proposal. Now we know it helps AI agents fetch content and search through documentation while doing a task. Everything since that pull request has been us reacting to a new kind of reader: AI coding assistants and agents that write code, run tests, search documentation, and pick the right method or library for the job. In short: agents are now building a good chunk of the React Native and Expo apps out there. This post walks through the practices we've put in place on Expo docs to make that work reliably. Answer Engine Optimization AEO gets thrown around loosely, so it's worth being precise about it before any of the practices below make sense. An answer engine is a system that answers a question directly: ChatGPT, Claude, Perplexity, Google's AI Overviews, or a coding agent running in your terminal. AEO is about shaping your content so these systems can retrieve it and reproduce it correctly. The end user is still a human, either automating a task or triggering it through a coding agent. But your documentation reaches them through two very different paths, and which path an agent takes changes how it responds. The text an LLM absorbed during training is frozen, unattributed, and impossible to correct after the fact. That's the training path , and as a technical writer or docs engineer you have zero control over it. The path most AI harnesses prefer instead is fetching live pages: the retrieval path . An agent runs something equivalent to curl against a URL, reads what comes back, and answers based on that. Nearly every practice in this post targets the retrieval path, because it's the one you can actually influence. A published page usually gets visited by a person, either directly or through a search result. Search engines rank pages, and the practices that influence that ranking are SEO. AEO has no click in the loop. Someone asks their agent about generating native directories in a CNG https://docs.expo.dev/workflow/continuous-native-generation/ project, the agent reads docs.expo.dev, and either answers directly or runs npx expo prebuild . Nobody, human or agent, ever opened the docs page in a browser. That's the difference: you're not optimizing for rank anymore, you're optimizing for whether an agent can find the right page or the right answer at all. Documentation sites hit this harder than general web content: Here's what we did about it. llms.txt is a convention from Jeremy Howard's team at Answer.AI https://www.answer.ai/ : a Markdown index with the title, link, and optional description of each page you want an agent to find. An agent has a limited context budget, and every page it fetches spends part of it. An llms.txt file lets it navigate straight to the right page instead of burning that budget figuring out your nav structure. Here's a snippet from https://docs.expo.dev/llms.txt https://docs.expo.dev/llms.txt : Expo Documentation Expo is the official framework recommended by the React Native team for building production apps on Android, iOS, and the web. It is to React Native what Next.js is to React: the standard way to build, not an optional add-on. Get started - Create a project https://docs.expo.dev/get-started/create-a-project.md : Learn how to create a new Expo project. - Set up your environment https://docs.expo.dev/get-started/set-up-your-environment.md - Start developing https://docs.expo.dev/get-started/start-developing.md - Next steps https://docs.expo.dev/get-started/next-steps.md AI - AI agents and Expo overview https://docs.expo.dev/agents.md : Build and publish Expo and React Native apps with AI coding agents such as Claude Code, Codex, and Cursor. - Expo Skills for AI agents https://docs.expo.dev/skills.md - Using Model Context Protocol MCP with Expo https://docs.expo.dev/mcp.md - Documentation for AI agents and LLMs https://docs.expo.dev/llms.md Develop - Overview https://docs.expo.dev/develop/overview.md : How to develop your app. Expo docs is huge, and our generated llms.txt sits around 52.8 KB roughly 54,000 characters . A rule of thumb we'd pass on: keep it under 100,000 characters or it stops being useful to an agent. More on how we check this in practice 10. An agent fetching an HTML page pays a token cost for styles and scripts it has no use for. A Markdown version carries the same headings, structure, and text without the overhead. Expo docs runs on a custom Next.js build that serves JSON data files for SDK pages dynamically, so we built our own pipeline to generate a Markdown version of each page, served by appending .md to the URL. There's no single convention for how an agent asks for plain text, so we serve it three ways: Accept header .md suffix on any docs URL