Skip to content

field note

llms.txt v2: what changed, and does it help SEO?

AI search

Shahid AliAugust 27, 2026all posts

llms.txt v2: what changed, and does it help SEO?

The llms.txt proposal was revised on 10 August 2026, almost two years after the original. If you added a file to your site in 2024 and have not looked at it since, yours is a v1 file, and the thing v2 adds is the thing v1 was most criticised for.

I publish one on this site, so I checked mine while writing this. It is a v1 file. More on that below, because the honest version of this note includes my own gaps.

What llms.txt is proposing

The proposal is a markdown file at /llms.txt giving an agent a short description of the site and a curated list of links to detailed markdown files. The reasoning has not changed since 2024: an HTML page wraps its information in navigation, ads and JavaScript, converting that back to clean text is imprecise, and every wasted token costs time and money.

What has changed is the framing. The author, Jeremy Howard, is direct that in 2024 the idea of models routinely reading websites was “largely a prediction” and that today it is routine. Coding agents fetching library documentation are the use case the file was built for, and they are the use case it demonstrably serves.

The four changes in v2

The changes page sets them out plainly.

llms.txt v1 to v2, August 2026 TOPIC v1 v2
<text x="0" y="100" fill="var(--ink)" font-weight="700">Discoverability</text>
<text x="215" y="100" fill="var(--muted)">nothing</text>
<rect x="490" y="80" width="470" height="30" rx="5" fill="var(--volt)" opacity="0.16"/>
<text x="500" y="100" fill="var(--ink)">rel="describedby" and rel="alternate" type="text/markdown"</text>
<line x1="0" y1="122" x2="960" y2="122" stroke="var(--hairline)"/>

<text x="0" y="152" fill="var(--ink)" font-weight="700">Markdown URL</text>
<text x="215" y="152" fill="var(--muted)">page.html.md only</text>
<text x="500" y="152" fill="var(--ink)">page.html.md or page.md, both allowed</text>
<line x1="0" y1="174" x2="960" y2="174" stroke="var(--hairline)"/>

<text x="0" y="204" fill="var(--ink)" font-weight="700">Subpath files</text>
<text x="215" y="204" fill="var(--muted)">allowed, undefined</text>
<text x="500" y="204" fill="var(--ink)">covers pages under its path, most specific wins</text>
<line x1="0" y1="226" x2="960" y2="226" stroke="var(--hairline)"/>

<text x="0" y="256" fill="var(--ink)" font-weight="700">How it is read</text>
<text x="215" y="256" fill="var(--muted)">expansion tooling</text>
<text x="500" y="256" fill="var(--ink)">agent reads it, then follows the links</text>
<line x1="0" y1="278" x2="960" y2="278" stroke="var(--hairline)"/>
The Optional section loses its special meaning: it is a hint now, not an instruction to a parser. Source: llmstxt.org, changes page, v2 published 10 August 2026.

Discoverability is the substantial one. v1 gave an agent no way to get from a page it was already looking at to the markdown version of that page, or to the llms.txt file covering it, except by guessing at the root. v2 answers with two standard link relations: rel="alternate" type="text/markdown" for the page’s markdown version, and rel="describedby" for the llms.txt file, delivered either as HTML <link> elements or as an HTTP Link: header.

The subpath rule is the one that quietly widens who can use this. A file now formally covers the pages beneath its path, and the most specific file wins, which means a project on a shared host or a GitHub Pages path can participate without controlling the domain root.

Does it do anything for Google?

No, and nothing in Google’s documentation suggests otherwise.

Google’s AI features and your website page states there are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary. A file Google does not document reading is not going to be the exception to a sentence that broad. I went through what that sentence does and does not permit in do I need to optimize for AI Overviews, and the answer has not moved.

So treat llms.txt as a developer experience feature, not a ranking one. The population it serves is agents that fetch your documentation on purpose: a coding assistant pulling your API reference, an assistant reading your product pages because a user asked about them. That is a real and growing population, and it is not Google Search.

The proposal itself claims Chrome’s Lighthouse now audits for the file as part of its agentic browsing checks, which would be the strongest adoption signal in it. I have not confirmed that audit myself, so I am reporting it as the author’s claim rather than as a fact I have verified. It is the kind of detail worth checking before you put it in a client deck.

Where the file genuinely earns its place is control. Publishing one is how you choose which pages an agent reads and in what order, rather than letting it guess from your navigation. That is the same instinct behind deciding deliberately whether to block GPTBot in robots.txt, and it is the same class of decision: not a ranking lever, a question of what you let through and how you frame it. The newest entry in that family is WebMCP, which shipped in ChatGPT’s browser in August 2026 and gets read the same wrong way.

What my own file gets wrong

I fetched my own while writing this rather than assume. shahidali.co/llms.txt returns 200 and is 75 lines with 35 curated links, which is the right shape for a site this size: a heading, a one-paragraph summary, and sections pointing at the pages someone actually needs.

Three things are missing, all of them v2:

  • No rel="describedby" link on the pages and no Link: header. The only rel="alternate" on my homepage is the RSS feed. An agent landing on a post has no signal that the file exists.
  • No markdown versions. /index.html.md and /about.md both return 404, so every link in my file points at HTML that an agent has to strip itself.
  • The whole thing is a root file with no subpath variants, which is fine at 128 URLs and would not be at ten times that.

None of that is urgent, because none of it affects a single search ranking. It goes on the list as a small, cheap improvement for a specific audience, which is exactly the priority it deserves. I would give a client the same order: fix what Google can measure first, then do this.

It is cheap insurance rather than a lever, which is easier to accept once you can see what the levers actually are: how to improve brand visibility in AI search engines lists them in order.

Sources

  • llmstxt.org, the /llms.txt file, v2, Jeremy Howard, published 3 September 2024, modified 10 August 2026
  • llmstxt.org, changes in v2, the v1 to v2 differences, checked 27 August 2026
  • Google Search Central, AI features and your website, no additional requirements for AI Overviews or AI Mode
  • First-hand: shahidali.co/llms.txt fetched 27 August 2026, 200, 75 lines, 35 links, no describedby link or Link header on the site, no .md page variants