llms.txt v2 Adds Standard Link Relations So Agents Can Find Markdown Versions and the Covering llms.txt
After two years of adoption, the llms.txt proposal was revised to add rel="alternate" and rel="describedby" discovery, define the scope of subpath files, and drop context-expansion tooling and the mechanical meaning of the Optional section.
llms.txt is a Markdown index file a site serves at its root or a subpath so AI agents can quickly find LLM-friendly content. Version 2, published in August 2026, adds standard discovery via HTML link elements or HTTP Link headers and states explicitly how agents are expected to consume the file.
On August 10, 2026, Jeremy Howard, author of the llms.txt proposal, published v2 on llmstxt.org. He says the revision reflects two years of adoption: thousands of sites publish an llms.txt, documentation platforms generate one automatically, Chrome Lighthouse audits for one as part of its agentic browsing checks, and OpenAI, Anthropic, and Gemini publish llms.txt files for their own developer docs.
The headline addition is discovery. v2 recommends standard link relations: rel="alternate" type="text/markdown" points to a page's Markdown version, and rel="describedby" points to the llms.txt that covers it. These can be HTML link elements or an HTTP Link response header; the header form also works for non-HTML resources such as the Markdown files themselves and can be added in web server or CDN configuration without modifying pages.
v2 also blesses diverging practice. Markdown URLs may be either page.html.md or page.md; an llms.txt in a subpath covers the pages under that path, with the most specific file applying, so a site that controls only a path, such as a GitHub Pages project site, can participate fully. Consumption is now stated directly: agents view or search the llms.txt, then follow relevant links. Context-expansion tooling such as llms_txt2ctx is no longer part of the proposal, and Optional sections remain allowed but lose their mechanical meaning.
Caveats matter: llms.txt is still a community proposal, not a W3C or IETF standard, and there is no public evidence that it raises citation rates in AI search. Its clearest value is helping coding agents and developer tools reliably reach the right documentation.
Another important shift in v2 is that it stops predicting how agents might use websites and describes how they actually do. v1 envisioned llms.txt as input that tools could expand into one large LLM context; v2 states that agents view or search the llms.txt and then follow relevant links, so the linked content itself must be LLM-friendly Markdown. The maintenance focus therefore moves from making the llms.txt exhaustive to making every link target clean and directly readable, which raises the bar for how API references and product documentation are structured.
What to watch is whether major agents and browser tooling start auto-discovering llms.txt through rel="describedby", and whether documentation platforms emit v2 Link headers by default.
Enterprise AI platforms that already publish llms.txt and OpenAPI (for example X Cube's /v1/llms.txt) can check three things against v2: whether API documentation pages point to their llms.txt with rel="describedby", whether Markdown versions exist and are declared with rel="alternate", and whether subpath file scope matches the real documentation tree. All of this can be done with Link headers at the CDN or web-server layer.
