Standard vs technical llms.txt: what's the difference?

Best move: read what the file points at, not the fact that a file exists.

Why it works: A content index and a machine-facing endpoint share a filename but prove different things. One says you want to be read, the other says you built something for agents to operate.

Key takeaways

• llms.txt is a voluntary llmstxt.org convention served at the site root, not an official web standard.
• A standard llms.txt is a content index: an H1, a summary blockquote, and curated markdown links that give language models a clean reading path through your docs.
• A technical llms.txt is machine-facing: it points agents at API specs, MCP endpoints, schemas, and .well-known descriptors so they can act.
• Only the machine-facing flavor counts toward Bassethound’s shipping verdict. A standard llms.txt fires one signal group and lands at experimenting.
• Bassethound classifies the flavor from the file’s structure and targets, and reports it as a gap when a keyless crawl cannot reach it.

What does a standard llms.txt contain?

The llmstxt.org proposal defines a plain markdown file at your site root. It opens with an H1 naming the project, a blockquote that summarizes what the site is, then sections of curated links. Each link points to a readable version of a key page: docs, guides, API references written for humans. An optional section holds secondary material a model can skip when context runs tight. Some sites also publish /llms-full.txt, which inlines every doc into one file for a single fetch. The intent is reading, not action. You hand a language model a clean, curated map so it cites and summarizes your content from source instead of scraping rendered HTML and guessing. That makes a standard llms.txt an answer-engine-optimization move. It signals editorial care about how models represent you. It says nothing about whether you run a vector store, an agent, or an inference pipeline. Treat it as a publishing signal: strong on intent, silent on infrastructure.

What makes an llms.txt technical?

Structure and targets. A technical llms.txt stops pointing at prose and starts pointing at machinery. Instead of guide links, it references OpenAPI specs, an MCP endpoint, tool manifests, .well-known descriptors, or agent instructions that tell a client how to authenticate and call you. The file reads like a wiring diagram, not a table of contents. The distinction carries weight because a machine-facing endpoint implies you built something for agents to operate, not just something for them to skim. Bassethound classifies an llms.txt as technical when its contents look machine-facing (programmatic endpoints, schemas, MCP references) rather than a human-readable content index. In the verdict logic, a technical llms.txt is a machine-facing endpoint, so its presence alone pushes a domain to shipping. A standard llms.txt does not clear that bar by itself. You can publish a hybrid, and plenty do. The classifier reads what the links resolve toward. A file that mostly hands agents specs and endpoints reads technical, even when it also carries a summary block up top.

Why does the distinction change your AI-readiness score?

Because the two flavors prove different things. Bassethound’s ai_readiness score counts distinct signal groups that fire, out of six, capped at 1.0, then maps to a verdict. A standard llms.txt fires the llms.txt group. One group is enough for experimenting, not for shipping. Bassethound treats a technical llms.txt as a machine-facing endpoint, one of two independent routes to shipping (the other is three or more groups firing). So the same filename, classified differently, can move a domain across the verdict boundary. This is deliberate. Publishing a content index is cheap and says you care about how models read you. Exposing a machine-facing endpoint costs engineering and says you built for agents to act. Bassethound derives the icp_signal (hot, warm, cold) from the same evidence, so a technical llms.txt pushes it hotter than a standard one. If you sell to companies that ship AI, that boundary is the line you want to sort on. A curated docs index is a nice-to-have. An agent-facing endpoint is a buying signal.

Can Bassethound tell them apart reliably?

Mostly, with honest edges. Bassethound runs a static crawl plus optional JavaScript rendering, keyless and read-only. When a site serves /llms.txt as plain text at the root, the fetch comes back clean and the classifier reads the whole file. It sorts standard from technical by what the content points to: human-readable docs versus programmatic endpoints, schemas, and MCP references. Two failure modes exist, and the dossier names them. First, access. A file behind auth, geofencing, or a full proxy stays invisible to a keyless crawl, so Bassethound reports absence as a gap rather than a confirmed none. Second, ambiguity. A short or unconventional file can point at both docs and endpoints, and the classifier makes a call you can inspect rather than a verdict you must trust. The design choice is to under-claim. If Bassethound cannot reach or cannot confidently classify the file, it says so in the dossier’s gaps instead of inflating your readiness. You get a signal you can act on and a clear note where the crawl could not see.

Does a standard llms.txt mean a company ships AI?

No, and reading it that way is the common mistake. A standard llms.txt proves editorial intent. Someone curated a content map for language models, which means the company thinks about answer engines. That is a marketing signal, not evidence of an inference pipeline, a vector store, or an agent. Plenty of static marketing sites publish a tidy llms.txt and run zero AI in production. The inverse also happens. A company can ship heavy AI (server-side model calls, a private RAG stack, an internal agent) and publish no llms.txt at all, because none of that infrastructure faces the public crawl. This is why Bassethound never scores on one signal. It correlates the llms.txt classification with model providers, AI SDKs, orchestration frameworks, vector stores, observability, and machine-facing endpoints across the five-layer dossier. A standard llms.txt nudges you toward experimenting. Only machine-facing evidence, or several groups firing together, earns shipping. Read the whole trail, not the one file that is easiest to publish.

Bassethound perspective

Most AI-readiness tools treat any llms.txt as a green check. That is lazy, and it inflates scores for companies doing nothing but publishing a markdown file. A standard llms.txt is a content decision, not an engineering one. It costs an afternoon and proves that someone read a blog post about answer-engine optimization. We hold a harder line: a plain content index is experimenting, full stop, and it does not earn shipping no matter how well-formatted it is. The signal we respect is machine-facing. When your llms.txt points agents at MCP endpoints, API specs, and .well-known descriptors, you built something for machines to operate, and that costs real work. Competitors who collapse the two flavors into one boolean will tell you a marketing site is AI-ready. It is not. The gap between reading and acting is the whole game, and any scorer that ignores it is selling you a vanity metric. Bassethound sorts on what you exposed for agents to do, not on what you published for them to skim.

Sources

• llms.txt proposal and format: https://llmstxt.org
• Model Context Protocol: https://modelcontextprotocol.io
• Anthropic documentation: https://docs.anthropic.com