The biggest weakness in llms.txt was never the file itself. It was discovery.
Version 2 of the llms.txt proposal now tackles that problem directly, giving websites a standardized way to tell AI agents where a clean Markdown version of a page lives and which llms.txt file describes that section of the site. The revised specification was published in August 2026, nearly two years after the original proposal appeared.
For developers, it closes a practical gap. For SEOs, it requires a more careful distinction.
LLMs.txt may be getting better at helping agents navigate websites. That still does not make it a Google Search ranking signal.
Agents No Longer Have to Guess Where the Markdown Lives
The central addition in llms.txt v2 is surprisingly small.
Websites can now use established web link relations to explicitly connect an HTML page to its Markdown equivalent:
rel="alternate" type="text/markdown"
That relation tells a client that an alternate Markdown representation of the current page exists.
A second relation, rel="describedby", can identify the llms.txt file that applies to the page. Both declarations can appear as HTML <link> elements or inside an HTTP Link: response header.
That matters because the original proposal left discovery largely implicit.
A site might publish /docs/product.html alongside /docs/product.html.md, but an agent arriving on the HTML page had no standardized signal telling it to check for the Markdown version. It could infer the URL, inspect an llms.txt file or simply parse the HTML.
V2 removes some of that guesswork.
The proposal even supports HTTP headers, which means publishers can expose these relationships through server or CDN configuration rather than editing the markup of every page individually. The same mechanism can also work with non-HTML resources.
For AI agents, that creates a cleaner discovery path: find the page, identify the machine-friendly alternative, then retrieve only the content needed for the task.
LLMs.txt Is Becoming a Map, Not a Giant Context File
The revision also clarifies what an llms.txt file is supposed to do.
It is not designed to contain an entire website.
The v2 proposal describes llms.txt as a relatively compact Markdown document containing background information, guidance and categorized links to more detailed resources. Agents can inspect or search that file, identify the relevant resource and follow its link when they need deeper information.
That model is closer to a curated map than a compressed copy of the site.
Version 2 formalizes that behaviour by dropping the earlier proposal's context-expansion tooling. The original specification discussed llms_txt2ctx, which could expand linked material into model context. V2 instead defines the expected agent workflow directly: consult llms.txt, find the necessary resource and retrieve it on demand.
The update also loosens one naming restriction.
Version 1 specified Markdown alternatives by appending .md to the original URL, such as page.html.md. In practice, some platforms adopted page.md instead. Both forms are now explicitly supported.
Subdirectory behaviour is clearer too. An /llms.txt file can cover an entire domain, while something like /docs/llms.txt applies to pages below /docs/. If more than one file could apply, the most specific path takes precedence.
Those changes make the proposal easier to implement on large sites, documentation platforms and projects that control only part of a domain.
Two Years of Agent Adoption Changed the Specification
The first llms.txt proposal arrived in September 2024.
At the time, its premise was largely anticipatory: language models and automated assistants would increasingly need cleaner ways to consume websites.
By August 2026, the proposal's author, Jeremy Howard, said thousands of sites were publishing llms.txt files, documentation platforms were generating them automatically and coding agents were using them in practice. The new version reflects lessons from that adoption rather than simply expanding the original format.
The integrations listed by the project now include documentation systems and website tools such as Mintlify, GitBook, Yoast SEO, AIOSEO and Wix. The specification also points to llms.txt files published for developer documentation from OpenAI, Anthropic and Gemini.
That gives llms.txt a different position from the one it occupied when the proposal first appeared.
It remains an open community proposal, not a formal web standard mandated by browsers, search engines or AI companies. The project itself describes it as a proposal and continues to solicit community input.
Still, its focus is becoming more concrete.
The problem is no longer simply "How should a website make information easier for an LLM to read?" V2 addresses a more operational question: "How does an agent reliably discover the machine-friendly representation once it reaches a page?"
Better Agent Discovery Still Does Not Equal Better Google Rankings
The distinction between agent usability and search visibility is where the SEO conversation can quickly go wrong.
Google has already said llms.txt is not required for Google Search and provides no ranking advantage. TechWyse covered that position when Google clarified that llms.txt does not help Search rankings.
Google's Search team has also pushed back against the broader idea that converting webpages to Markdown creates a special AI SEO advantage. HTML remains the primary web format for Search, while Markdown may have narrower value once an agent is already interacting with a website. TechWyse examined that distinction in its coverage of HTML versus Markdown for AI optimization.
Nothing in llms.txt v2 changes Google's stated position.
The revised proposal is about machine discovery and agent consumption, not rankings. It does not document a Google crawler requirement, an AI Overview eligibility signal or a special citation advantage.
That difference also matters for generative engine optimization. Google has repeatedly tied visibility in its generative Search products back to conventional crawlability, indexing, content quality and existing Search systems rather than requiring a separate AI-only technical layer.
LLMs.txt sits beside that infrastructure, not above it.
The Practical Case for LLMs.txt Is Getting Narrower and Stronger
For marketers and technical teams, v2 makes the strongest case for llms.txt on sites where autonomous agents have a reason to retrieve precise information directly.
Software documentation is the obvious example. An agent looking for an API method, configuration option or product instruction can spend fewer tokens parsing navigation, scripts and surrounding interface elements if a clean Markdown version is explicitly available.
The same principle could apply to structured product documentation, institutional policies, technical support material or other information that agents may need to retrieve while completing a task.
That is an agent-experience decision rather than a conventional technical SEO tactic.
Publishers considering implementation now have a clearer specification to work from: keep llms.txt concise, point it toward useful machine-readable resources, expose Markdown alternatives through recognized link relations where appropriate and avoid treating the file as a replacement for HTML, robots.txt or XML sitemaps. The proposal explicitly describes those standards as complementary rather than interchangeable.
The update does not settle whether llms.txt becomes a lasting part of the web's AI infrastructure.
It does settle several of the ambiguities that made the first version difficult for agents to discover consistently.
V2 was last modified on August 10, 2026. Its most consequential change is not a new content format or an AI ranking mechanism. It is a standardized signpost telling an agent exactly where the cleaner version of a page can be found.
