Document360's New llms.txt: What AI Discoverability Misses

llms.txt, knowledge-base, ai-support, document360

Document360 started auto-generating an llms.txt file for every knowledge base in June 2026, with release 12.6.1. It reads as a new capability if you only follow Document360's own changelog. It isn't: Plain shipped the identical thing for its Help Centers on 30 September 2025 — nine months earlier, on by default, no setup. Two vendors from different corners of the docs-and-support market landed on the same file within a year of each other. That's not a feature one of them invented. It's a category settling on an answer, and it's worth asking what the answer actually buys a team, and what it quietly doesn't.

What llms.txt is, and what it isn't

llms.txt is a plain Markdown file served at a site's root — /llms.txt — proposed by Jeremy Howard of Answer.AI in September 2024. The spec is narrow: an H1 with the site's name, a one-line summary, optional prose, then ## sections listing links with short descriptions — a curated index, meant to be read once by an agent deciding what a site contains.

It gets compared to robots.txt constantly, and the comparison is misleading. robots.txt is an access rule: it tells a crawler what it may fetch. llms.txt is a reading list: it tells an agent what's worth fetching, assuming the agent already chose to look. Nothing enforces it — it's a convention, not a gate.

It's also not an SEO lever, and Google said so directly. On 15 June 2026 Google added a section to its own AI-optimization guide stating that Google Search doesn't use llms.txt files at all: maintaining one "won't harm (nor help) your visibility or rankings in Google Search, as Google Search ignores them." Whatever llms.txt is for, ranking in Google isn't it.

How it actually works, at both vendors

Document360's version is generated from the workspace's published articles and their SEO/AI descriptions, and it updates automatically whenever an article is published, edited, or deleted — no manual authoring. Each entry links to the article's Markdown rendering rather than its HTML page, so a fetch gets the same text a person reads in the editor.

Plain's implementation reads the same way: "every Plain Help Center now has an llms.txt file by default and will be kept up to date automatically as you add or update articles," per its own changelog. Different products, same shape: publish an article, the file regenerates, and it stays stale until the next one.

What a generated file can't tell an agent

The honest limit is the word "generated." llms.txt is a snapshot taken at publish time, not a live answer. An agent that cached last week's file doesn't know about this morning's edit, and nothing in the format flags that the file might be behind — no version, no timestamp per entry, no "re-check this."

It also only ever reflects what's public. Document360 builds the file from published articles; a draft under review has no reason to appear in it, which is correct, but it means the file describes your public surface, not your whole knowledge base. And per Google's own guidance above, it buys none of the SEO benefit teams sometimes assume from a file with "AI" in the name. It's a convenience for agents that already know to look for it, and nothing more.

The other path: answer the question instead of indexing it

There's a second way to make a knowledge base legible to an AI client, and it doesn't involve a file at all: let the client call a tool that queries the actual database. We shipped that for our own tenants' knowledge bases as an MCP server (com.replium.articles.ArticleMcpTools, covered in more detail in our MCP write-up) — an articles_search tool that runs keyword and semantic ranking together, and an article_get that returns one article's live body. Every call runs against the current database, scoped to the caller's tenant by the token it authenticated with, not by an argument a model could get wrong.

The difference from llms.txt isn't "better," it's a different trade. A static file is one fetch, cacheable, and works for an agent with no tool-calling budget to spend. A live query costs a round trip per question, but it can never be a week stale, and — because the token behind it is issued from the workspace's own admin settings, at owner or admin level — it can see a draft that a public llms.txt was never going to list in the first place.

When a static file is enough, and when it isn't

• Public docs, low edit frequency, agents that just want an index: a static file is enough — both Document360 and Plain now give you one without asking.
• Content that changes daily, or an agent that needs the current state: a snapshot will eventually answer confidently and wrong. That's a case for a live query.
• Anything not meant to be public — a draft, a permissioned page: it has no business in a file crawled by anyone who finds the URL.
• An agent with no tool-calling budget, reading once and moving on: it wants the file, not a protocol to negotiate first.

Indexing decisions made once, at generation time, are also where a multilingual base runs into the same limit from a different angle — which language the file itself is written in, and whether it's the one your customer is asking in. We went through that trade-off in our piece on multilingual retrieval.

Where we stand, honestly

Same method, pointed at ourselves. We don't have an llms.txt route: com.replium.seo.SitemapController generates sitemap.xml and robots.txt, and nothing in the codebase writes a /llms.txt. If the checklist above is a box to tick, we don't tick it, today.

What we have instead is two live paths where Document360 and Plain ship one static file. The MCP tools above are the first, for a tenant's own external AI client. The second is a retrieval agent built into the widget itself (com.replium.agent.ConversationAgent), backed by OpenAI: it runs the same hybrid search the MCP tool does, answers a visitor directly from the workspace's own published articles, and stays silent rather than guess when nothing covers the question. It's gated three ways — a rollout flag, a plan check, and the workspace's own switch, off until an owner turns it on — so the code existing isn't the same as every workspace having it yet.

Four gaps under that, named plainly rather than smoothed over. The agent can take no action beyond writing a reply — no tool calls behind it, on purpose, for now. It answers in the widget only; email is deliberately out of this slice. There's no region-aware routing for where a call to the model actually runs — every workspace's call goes to the same place today. And there's no llms.txt, with no plan to add one on top of the two live paths above.

If you came here comparing discoverability files specifically, we're not a fair comparison — we don't have one, and this article is the reason we won't fake having one. If a support agent that answers from your own docs, plus a live tool your own AI client can call against the same knowledge base, is closer to what you actually need — start here. Self-serve, no card needed to look around, and nothing to cancel because there's no billing built yet either.