Should I choose llms.txt or WebMCP?

Neither replaces the other. llms.txt describes what your site knows and is read over HTTP; WebMCP declares what your site can do and executes in the browser. Ask whether your value to an agent is something it needs to read or something it needs to do — most sites have both, weighted very differently.

Does publishing llms.txt help you get cited in AI search?

The published evidence says no. Ahrefs found 97% of llms.txt files received zero requests in May 2026, retrieval bots accounted for 1.1% of the requests that did arrive, and no AI bot probed for files that did not already exist. SE Ranking found no significant correlation with AI citation across roughly 300,000 domains.

Is WebMCP a W3C standard?

No. It is a Draft Community Group Report from the W3C Web Machine Learning Community Group. The document states plainly that it is not a W3C Standard nor on the W3C Standards Track. Chrome runs it behind an origin trial from Chrome 149.

Standards · 29 August 2026 · 11 min read

llms.txt vs WebMCP
One is read. One is executed.

Q: Is WebMCP the same as MCP?

No. WebMCP does not speak the Model Context Protocol wire format, has no server and no transport. It borrows the word 'tool' and nothing else. A page using WebMCP is MCP-shaped, not MCP-connected.

Both get pitched as "how you make your site ready for AI". They are not rivals, they are not alternatives, and only one of them can do anything on your behalf. Almost every real difference between them falls out of that one sentence.

llms.txt a file you write

# FastHTML

> A python library for creating
> server-rendered hypermedia apps.

## Docs

- [Quick start](/quickstart.md): the
  fastest path to a running app
- [Reference](/api.md): every
  component and its arguments

WebMCP a function you register

document.modelContext.registerTool({
  name: "add-todo",
  description: "Add an item to the
    user's active todo list",
  inputSchema: { type: "object",
    properties: { text: {type:"string"} },
    required: ["text"] },
  async execute({ text }) {
    await addTodoItem(text);
  }
});

1. Nouns and verbs

The two proposals get filed in the same mental drawer because they arrived on the same wave and use the same vocabulary. That drawer is wrong. They operate on different halves of the sentence.

llms.txt is a content convention: a Markdown file, served over HTTP, describing what a site knows — a curated index of the pages worth reading and what each one is for. It is a noun problem. Which of my 4,000 URLs actually carry the meaning?

WebMCP is a capability API: JavaScript, running inside a live page, declaring what a site can do — callable functions with typed inputs, invoked against the session the user is already logged into. It is a verb problem. How does an agent book the room instead of guessing which div is the button?

One is read. One is executed. Hold that and the rest of this article is mostly consequences.

2. What WebMCP actually specifies

WebMCP is a draft of the W3C Web Machine Learning Community Group. As of August 2026 it remains a Community Group Draft, and the document says outright that it "is not a W3C Standard nor is it on the W3C Standards Track". That is a real institutional home. It is not ratification.

The API is small. A page registers a tool with a name, a natural-language description, a JSON Schema for its inputs, and an async callback. Agents enumerate with getTools() and invoke with executeTool(). Annotations can mark a tool read-only, or flag that its output contains untrusted content. There is a declarative flavour too, which annotates ordinary HTML forms rather than writing JavaScript.

Name trap

WebMCP is not an implementation of the Model Context Protocol. It does not speak the MCP wire protocol, has no server, and no transport. It borrows the word "tool" and nothing else. A page using it is MCP-shaped, not MCP-connected.

The motivating argument is a swipe at both alternatives. Against screenshot-and-click agents: DOM actuation is brittle and slow, and a declared tool is neither. Against backend integrations: a server-side API duplicates state, loses the user's session context, and — in the spec's own phrasing — causes "disintermediation of web apps by backend integrations".

The non-goals sharpen the picture further. WebMCP explicitly does not target headless browsing, does not target fully autonomous workflows, does not replace backend integration protocols, and does not supersede human-facing interfaces. It is designed for a human sitting in front of a browser with an agent working beside them. Keep that in mind for section 5, because the entire safety story rests on it.

Where it runs today

Chrome runs a public origin trial from Chrome 149, with shipping targeted around Chrome 157. One migration scar already exists: the entry point moved from navigator.modelContext to document.modelContext, reflecting that tools belong to a document rather than to the browser. The navigator form is deprecated in Chrome 150, so real code today feature-detects both. Apple has logged concerns on the WebKit standards-positions tracker — API design, privacy and security, duplication, internationalisation — and has not taken a position.

3. Side by side

	llms.txt	WebMCP
What it declares	What the site knows	What the site can do
Artifact	A static Markdown file at a URL	JavaScript executing in a live document
Consumed by	Anything that can make an HTTP request	An agent inside a browser, on that page
Needs a browser	No	Yes, by definition
Session & auth	None — public content only	Runs in the user's authenticated session
Side effects	None. It is text.	Arbitrary. It is your app's code.
Governance	Community proposal on GitHub, no standards body	W3C Community Group Draft, not on the Standards Track
Who implements it	Docs and content teams, often auto-generated	Front-end engineers, per interactive surface
Cost to adopt	Near zero	Real refactoring of interactive flows
Cost of being wrong	Wasted tokens; a mildly misled reader	An unintended action under the user's cookie
Status, Aug 2026	v2 shipped. Widely published.	Origin trial from Chrome 149. Barely published.

4. The adoption numbers are the interesting part

This is where the comparison gets genuinely instructive, because the two proposals are failing to catch on in opposite directions.

llms.txt has supply and no demand. Ahrefs analysed 137,210 domains in 2026 and found 28% publish an llms.txt — an upper bound, since their customer base skews technical. And then:

28%

of 137K analysed domains publish an llms.txt file

97%

of those files received zero requests in May 2026

1.1%

of bot requests came from retrieval bots — the ones feeding AI search

Who actually requests llms.txt — share of bot traffic by requester

Non-AI toolingSEO audits, generic crawlers, tech profilers

77%

AI agents & agentic infrastructure

10.5%

Training crawlersGPTBot, ClaudeBot

5.3%

Assistants

2.5%

Retrieval botsthe ones feeding AI search

1.1%

Shares are of bot requests to llms.txt files that received any traffic at all — itself only 3% of published files. Bars are scaled to the largest category, not to 100%. Source: Ahrefs, 137,210 domains, May 2026.

Two further findings matter. Ahrefs recorded zero requests from AI bots probing for llms.txt files that did not already exist — nothing is out there hunting. And SE Ranking, across roughly 300,000 domains, found no statistically significant correlation between having the file and being cited by AI systems.

Google's position is consistent and frequently misquoted in both directions. No Google Search system reads or acts on llms.txt. John Mueller's framing was that it is "not done for search" — a temporary crutch to save tokens for AI coding tools parsing developer documentation.

WebMCP has the mirror-image problem: a demand-side gatekeeper before there is any supply. A major browser is shipping the API and Google has signalled its own in-browser agent as the first mainstream consumer. But no mainstream agent calls these tools today — the assistants people actually use still drive the DOM. Pilot participants have been reported among large travel and commerce brands, though those deployments are not independently confirmed, and registered tools round to zero outside demos and checker sites.

llms.txt was built bottom-up and got publishers without readers. WebMCP is being built top-down and has a reader with nothing to read.

Neither observation is a comment on technical merit. They are two different ways of losing the same bootstrapping game — and WebMCP's version is the more winnable one. A single browser vendor shipping a consuming agent can move the whole market. llms.txt would need every model provider to independently decide to fetch a file nobody has committed to reading.

5. Both are unverifiable claims. Only one is dangerous.

Structurally these specs do the same thing: a publisher asserts something about their own site, in natural language, to a model that has no way to check. llms.txt says "these are my important pages". WebMCP says "this function does what its description claims". Nothing enforces either.

The WebMCP spec is admirably blunt about its half:

There is no guarantee that a WebMCP tool's declared intent matches its actual behavior.
WebMCP Community Group Draft, security considerations

It goes on to enumerate metadata poisoning — hidden instructions inside tool descriptions that the model reads and the user never sees — output injection through malicious tool results, and privacy leakage via over-parameterised input schemas that quietly hoover up more than the task needs. Independent research adds lifecycle attacks that inject nothing at all: tool squatting, tool substitution, and unregister/re-register races that simply change which tools the agent can see, mid-session.

The asymmetry in consequence is the whole reason to hold these at different risk levels:

If llms.txt lies

An agent reads stale or self-serving descriptions
Output quality degrades; the user may not notice
Worst realistic case: keyword-stuffed "LLM SEO" spam, and drift as the file falls out of sync
No state changes anywhere

If a WebMCP tool lies

Code executes inside the user's authenticated session
The tool inherits every privilege the logged-in user has
Worst realistic case: a purchase, a transfer, a deletion, an exfiltration — performed by the site's own front end
Security assumes a human intended the action. With an agent in the loop, that assumption is gone.

Chrome's guidance leans on visibility and human confirmation: tools execute on the page where the user can see them, and sensitive actions can demand a confirmation dialog. That is a real mitigation and also a real ceiling — it is precisely why "headless" and "fully autonomous" sit in the non-goals. WebMCP's safety story depends on a human watching. Remove the human and the model is the only thing standing between a poisoned tool description and your checkout endpoint.

6. One is a concession, the other is a defence

Strip away the technology and these encode opposite bets about who owns the customer.

llms.txt is a concession to disintermediation. You hand a model a clean, curated, cheaply-parsed copy of your expertise and hope it cites you. The user's destination is the chat window, not your site. Every improvement you make to the file makes it easier for someone to get your answer without ever arriving.

WebMCP is an explicit defence against it. The goal is written into the spec: prevent disintermediation by adapting front ends for agents rather than replacing them. The agent comes to your page, runs your code, inside your session, under your business rules — including the ones about pricing, availability and terms that a scraped API would happily route around. Your analytics still see it. Your funnel still exists.

That difference explains the reported pilot roster better than any technical argument does. Travel and commerce platforms are exactly the businesses that lose most when an agent transacts elsewhere on their inventory, and exactly who benefits from a standard that keeps the transaction on their own page.

It also explains the incentive gap. Publishing llms.txt is cheap and speculative, so people do it and shrug. Implementing WebMCP is expensive and strategic, so it will arrive first where there is revenue to defend — not on documentation sites.

7. What to actually do

Ship it

You publish developer docs, an API reference, or a technical knowledge base.

Publish llms.txt, and go straight to v2 with the link relations. Serve Markdown twins of your pages. The payoff is real but narrow — coding agents fetch it mid-task and get your API right instead of hallucinating it. Most docs platforms generate it for you, so keep it in the build pipeline where it cannot drift.

Skip it

You are publishing llms.txt to get cited in AI search results.

The evidence says it does not work. 97% of files went unread, retrieval bots account for 1.1% of requests, nothing probes for a file that is not there, and there is no measurable citation lift across roughly 300,000 domains. It costs almost nothing, so publishing anyway is defensible — but budget it as a rounding error, not a channel.

Prototype

You run a transactional app — booking, cart, dashboard, configurator.

Join the origin trial and instrument your three highest-value flows, not your whole interface. Feature-detect both entry points. Treat it as a hedged bet on an agent landing in Chrome, not a committed roadmap item: the API has already moved once and the trial is time-boxed.

Design first

You are about to expose a tool that spends money or deletes things.

Keep it out of the first pass. Start with read-only tools annotated as such, put a confirmation step on anything that mutates, and keep input schemas minimal — every extra optional field is a privacy leak waiting for a model to fill it in. Never assume a tool call implies user intent.

And the framing to carry out of all this: if someone asks whether you should pick llms.txt or WebMCP, the question has already gone wrong. Ask instead whether your site's value to an agent is something it needs to read or something it needs to do. Most sites have both, weighted very differently — and that weighting, not the specs, tells you where to spend the sprint.

Where we come into this

We take an interest because we measured the last one. Our study of 30,091 UK business websites found llms.txt adoption at around a fifth of sites, and a real score gap between the sites that publish one and the sites that do not — which turned out to say more about the kind of team that ships an llms.txt than about the file itself.

We are running the same measurement for WebMCP across the same corpus, from the first month rather than the third year. We expect the first answer to be "essentially nobody", and a null result measured properly is still a result — it is the baseline that made anything useful sayable about llms.txt. See where sites stand today on our AI visibility breakdown. How we approach agent readiness →

Sources

Spec quotations, API names and the Chrome version were checked against the primary sources above on 29 August 2026, not against secondary write-ups — several of which report the wrong Chrome version and the superseded API entry point. Adoption figures are quoted from the published studies and are not our own measurements; where a claim could not be verified first-hand it is attributed or omitted.

llms.txt vs WebMCP One is read. One is executed.