Google Says llms.txt Does Nothing for Rankings

Google says llms.txt does nothing for your Search rankings, and on June 15, 2026 it wrote that down in its official documentation. The same week, every site owner who runs a Chrome Lighthouse report started seeing an llms.txt audit appear automatically. The two facts look like a contradiction, and a lot of SEO coverage has treated it as one — but it is not.

The reason both can be true is that they come from two different Google product teams pointed at two different futures. Google Search ranks crawlable HTML and openly ignores llms.txt. Chrome’s Lighthouse measures whether a site is ready for AI agents to browse it — a separate question with a separate answer. The file is relevant to one and invisible to the other.

This guide separates the two cleanly. We cover exactly what Google said and quoted it; why Chrome audits a file Search ignores; who actually reads your llms.txt today versus who skips it; and a site-type decision table so you know whether to build the file or spend the hour elsewhere. The short version: build it for the AI coding assistants that genuinely consume it, and skip it if your only goal is Google Search visibility.

Google published its first official AI optimization guide on May 15, 2026, titled “Optimizing your website for generative AI features on Google Search,” filed under a new Generative AI fundamentals section of Search Central. One month later, on June 15, it added a dedicated subsection —€” “Clarifying guidance on llms.txt files” —€” after, in Google’s own framing, questions from the community made it clear that misinformation was circulating.

The wording is unusually direct for Google. The guide tells site owners they do not need to produce special machine-readable files to appear in Search, and then specifically addresses people who keep an llms.txt anyway: maintaining the file is fine, but it neither helps nor harms Google visibility, because Search ignores it. That is the whole ruling. There is no nuance to read between the lines.

Two things are worth holding onto here. First, this was not a policy change — Google has never used llms.txt as a ranking input, so nothing flipped overnight. The update is retroactive context-setting: a correction of an industry misunderstanding that had been sold, in places, as a must-have. Second, the same guide reaffirms that the foundations have not moved. Google explicitly debunked a cluster of so-called AI SEO hacks — content chunking, exact-keyword obsession, artificial brand mentions — and landed on a blunt summary that answer engine and generative engine optimization are still, at bottom, SEO.

Here is the source of the confusion. On May 7, 2026, Chrome Lighthouse 13.3.0 promoted its “Agentic Browsing” audit category from experimental into the default configuration. From that release on, anyone running a standard Lighthouse report — and shortly after, PageSpeed Insights and Chrome DevTools — gets agent-readiness signals automatically, including a check for whether an llms.txt file exists. No opt-in required.

That timing is what made it look like Google was quietly endorsing llms.txt as a ranking factor right as Search documentation said the opposite. The Agentic Browsing category does not evaluate ranking at all. It evaluates four distinct areas of how ready a page is for an AI agent to operate it.

Notice what is missing from that list: any notion of search ranking. Lighthouse is a developer diagnostic tool. Its Agentic Browsing category is, in effect, a readiness checklist for a future where people delegate browsing to AI agents — and llms.txt is one item on that checklist because it can help an agent orient quickly. That has no bearing on how Google Search crawls and ranks your pages today.

The cleanest way to resolve the apparent contradiction is to stop treating “Google” as a single actor. Google Chrome and Google Search are separate product teams with separate missions and separate systems. Chrome’s Lighthouse audits agentic readiness for a world where users browse through AI agents. Google Search runs its own independent crawl and ranking pipeline, which has never consulted llms.txt and, per the June 15 documentation, still does not. The file is relevant to one team and invisible to the other.

Jeremy Howard — co-founder of Answer.AI and fast.ai — proposed llms.txt on September 3, 2024, and his original framing supports this split. The spec was never designed to help systems discover content. It was designed for inference: to give an AI a curated, LLM-friendly map of a site at the moment a user is actively asking about it.

Read that intent against the two missions and the design makes sense. A file built to help an assistant answer a question well, at the moment of asking, maps neatly onto Chrome’s agent-readiness audit. It maps onto nothing in Search’s discovery-and-ranking job, which is exactly why Search ignores it. The standard was never an SEO mechanism in the first place — it got recast as one by an ecosystem hungry for the next ranking lever.

John Mueller, a Google Search Advocate, gave the most useful frame for why Search will not use llms.txt: he compared it to the keywords meta tag — the self-reported signal search engines abandoned over a decade ago. The reason is the same in both eras. A signal that site operators write about their own site cannot be trusted as a way to tell good sites from bad ones, because operators are not objective about their own quality.

Mueller also drew the discovery boundary explicitly. The foundational first step — how a system finds a website at all — stays bound to crawlable HTML, not to supplementary text files an operator can author at will. A self-described navigation file simply does not sit anywhere in that pipeline.

He has been careful, though, not to call the file useless. On developer-documentation sites, where AI coding assistants already know the site and just need help navigating it, an llms.txt can make genuine sense. For non-developer sites, in his view, it does not. That distinction — discovery versus functionality, ranking versus navigation — is the line the rest of this guide turns into an actionable decision.

“Does llms.txt work?” is the wrong question because it assumes “AI” is one thing. It is not. The AI systems that might touch your file behave very differently, and the gap between them is the entire story. The table below maps the real landscape against what each system actually does with the file — and whether any of it moves Google rankings.

The pivot is right there in the two group headers. Crawlers — the systems that feed search and AI answers — almost never read the file; an analysis of more than 500 million LLM bot traffic events found they skip /llms.txt and crawl HTML directly. Coding assistants and on-demand retrieval, by contrast, genuinely use it. Mintlify’s internal data even indicates agents reach for llms-full.txt at over twice the rate of the standard file. So the file works — for the second group, on documentation, and nowhere near Google rankings.

Generic “should you use llms.txt?” advice is useless because the answer is entirely site-dependent. The table below collapses Mueller’s developer-versus-non-developer distinction, the crawler-versus-assistant data, and Google’s foundational-SEO-first guidance into one decision matrix. The Lighthouse column is the same for every row — an absent file is N/A, never a penalty — so the real call is whether the AI audience that reads the file is one you care about reaching.

The adoption data backs the table’s shape. A Rankability scan of the top 1,000 most-visited global sites found just three llms.txt files — about 0.3% — with no implementation on Google, Facebook, or Amazon. A broader SE Ranking study of 300,000 domains reported around 10% adoption, nearly uniform across traffic tiers and driven largely by developer platforms and speculation. The named early adopters tell the same story: Anthropic, Stripe, Cloudflare, Vercel, Supabase, Pinecone, LangChain — developer infrastructure, almost without exception. If your site is not in that family, the file is not where your AEO hour should go. If you do decide to build one, it pays to get the surrounding plumbing right — see our markdown-first content architecture and the llms.txt spec for how to structure the file, and the complete reference for robots.txt and meta robots directives for the crawl-control rules it sits beside. If you want help drawing that line for your own stack, our agentic SEO engagements start with exactly this kind of triage.

If you do run the Lighthouse audit, it helps to know precisely what it grades — because the loudest misreading is that Lighthouse now penalizes sites without an llms.txt. It does not. The audit uses a three-state result, and an absent file is the neutral state, not a failure. Crucially, the whole Agentic Browsing category does not produce a weighted 0–100 score the way Performance or Accessibility do; the spec team chose pass/fail signals and fractional counts on purpose, because the standards for the agentic web are still emerging and the goal right now is actionable data, not a verdict.

Read the bars carefully and the design intent is obvious. The only way to fail is to misconfigure your server so it throws an error when the file is requested — a genuine bug worth fixing regardless of llms.txt. Simply not having the file is N/A, because the file is currently optional. And if you do publish one, quality matters: the audit flags files that lack an H1, are too short, or contain no links, so a token file you never maintain can read as low quality.

That single line is the honest case for the file, stated by the team that built the audit. It is about agent efficiency — saving a browsing AI the work of reverse-engineering your structure — not about ranking. Which is precisely why the audit lives in Chrome’s diagnostic tooling and not in Google Search’s ranking systems.

Here is the signal most llms.txt coverage misses while it argues about a text file. The second item in Lighthouse’s Agentic Browsing audit is WebMCP — the Web Model Context Protocol — and that, not llms.txt, is where Google is putting its weight for agent-to-website interaction. WebMCP was announced in Chrome Canary in February 2026, featured at Google I/O 2026, and is running an origin trial in Chrome 149. It lets a site declare structured tool contracts in HTML attributes or JavaScript so an agent can act on a live session directly, instead of scraping the DOM or driving the UI with screenshots.

The difference in approach matters. llms.txt is a static map an agent reads to orient itself; WebMCP is a live interface an agent calls to get things done. One describes a site; the other lets an agent operate it. If the agentic web plays out the way Chrome is provisioning for, a structured action layer beats a flat description file — which is part of why llms.txt sits as one modest item on the audit while WebMCP anchors the next one.

Our read of the next 12 months: the llms.txt debate fades as Google’s documentation settles the ranking question, and the real action moves to structured agent interfaces. WebMCP’s vendor-reported preview numbers — sharply fewer errors and better task completion than screenshot-based automation, plus large token-efficiency gains — are early and not independently audited, so we would not bank a roadmap on them yet. But the direction is clear enough that teams building for an agentic future should learn WebMCP now and treat llms.txt as the minor, optional artifact Google has just confirmed it to be. For more on the broader shift, see our guide to answer engine optimization in 2026, and the robots.txt vs llms.txt decision matrix for AI crawlers for how these files fit alongside your crawl-control setup.