Is llms.txt a good measure of AI-readiness?

Best move: treat llms.txt as one signal among many, and weight the technical flavor above the standard one.

Why it works: a standard llms.txt is a publishing choice any team can make in an afternoon. A machine-facing (technical) llms.txt implies an operational endpoint, which is harder to stand up and pointless to fake.

Key takeaways

• llms.txt is a root-level file that maps a site’s content for LLM readers. It shows a company markets to AI, not that it builds with it.
• Bassethound classifies llms.txt as standard (a curated content map) or technical (a machine-facing endpoint) and weighs the two differently.
• A technical llms.txt contributes to the “shipping” verdict. A standard one on its own does not clear that bar.
• The ai_readiness score counts distinct signal groups hit out of six, capped at 1.0. llms.txt is one group, not the whole score.
• llms.txt lives at a known path and returns as plain text, so detecting it needs no JavaScript rendering.

What does an llms.txt file prove?

llms.txt is a markdown file at the site root that lists links to documentation, formatted for LLM consumers. The llmstxt.org proposal frames it as a way to help models find and read your content. That is a real, useful thing, and it tells you something narrow: this company thought about LLMs as an audience for its words. It says nothing about whether the company runs a model in production, stores vectors, or orchestrates agents.

A company can publish a clean llms.txt and ship zero AI. A company can run a full retrieval stack and never publish one. The file measures intent to be read by machines, not capacity to build with them. Read it as an answer-engine-optimization gesture first and an engineering signal second. When you see llms.txt and nothing else, you have found a content decision, not a product. That is the whole reason Bassethound refuses to let this one file drive a verdict. It records the file, classifies it, and then goes looking for the load-bearing signals that would make the claim credible.

Standard vs technical llms.txt: why Bassethound splits them

Bassethound classifies every llms.txt it finds into two buckets. A standard llms.txt is a content map: curated links to docs, guides, and pages, written for a model to read. It is a publishing decision. A technical llms.txt points at machine-facing surface, structured resources a client would call at runtime, not prose a human wrote for an LLM to summarize.

The technical flavor sits in the same tier as an MCP endpoint or a .well-known AI file, because all three imply something a machine consumes at runtime rather than reads once. That difference drives the verdict. A technical llms.txt is enough on its own to push a domain to “shipping,” because a machine-facing endpoint costs real effort to expose and returns nothing to a company that fakes it. A standard llms.txt counts as a single experimenting-tier signal and no more. If you collapse the two, you reward the cheap artifact at the same rate as the expensive one, and your score stops meaning anything. Keeping them separate is the point.

How much should llms.txt move an AI-readiness score?

The ai_readiness score is the count of distinct signal groups a domain hits, divided by six, capped at 1.0. The groups span model providers, AI SDKs, orchestration frameworks, vector stores, LLM observability, and the machine-facing/standards group where llms.txt, MCP endpoints, and .well-known AI files live.

llms.txt sits inside one of those six groups. Hitting it moves a cold domain from “none” to “experimenting,” roughly one-sixth of the way up. On its own it does not clear “shipping” unless it is the technical flavor. The verdict logic is explicit: shipping when a machine-facing endpoint is present or when three or more groups fire, experimenting when at least one fires, none otherwise. An icp_signal (hot, warm, cold) layers on top for prioritization.

So a lone standard llms.txt lands a domain at experimenting and warm at best, not shipping and hot. That is the honest weight, and it is deliberately small. A single content file should not outrank a loaded vector-store client or a running orchestration framework. Bassethound reports the group that fired and the reason, so you can audit the score instead of trusting a number.

What beats llms.txt as evidence a company ships AI?

Anything that has to run. A loaded model-provider SDK (Anthropic, OpenAI, Gemini, Cohere, Mistral). An orchestration framework (LangChain, LlamaIndex, Haystack, CrewAI). A vector-store client (Pinecone, Weaviate, Qdrant, Chroma, Milvus). An observability shim (Helicone, LangSmith, Langfuse). Those signatures live in shipped code, cost money to operate, and break if faked.

The hierarchy Bassethound applies runs from runtime infrastructure down to content gestures. Runtime infrastructure (SDKs, vector clients, orchestration) is the strongest tell. Machine-facing endpoints (MCP, technical llms.txt, .well-known AI files) come next. Content gestures (a standard llms.txt) sit at the bottom. Bassethound correlates all five dossier layers in one call, so llms.txt never stands alone. When a standard llms.txt shows up next to a Pinecone client and an Anthropic SDK, the story is consistent and the score reflects it. When llms.txt is the only thing firing, you have a marketing artifact. The honest limit: a purely server-side stack behind a proxy can leave no client trail, so a domain can ship real AI and still score low. Bassethound reports that gap rather than guessing past it.

Can an llms.txt file be faked?

Yes, in minutes. It is a text file at a known path, so anyone can copy a good one, drop it at the root, and ship it. That is exactly why it is a weak standalone measure and a fine corroborating one. Bassethound treats a standard llms.txt as a claim of AI-readiness and then looks for the signals that would back the claim. When the SDKs, vector clients, and orchestration are present, the claim holds. When llms.txt fires alone, you are looking at intent, not implementation.

A technical llms.txt resists faking better, because it has to point at surface that behaves like an endpoint, and a bluff there leaves inconsistencies a crawl can catch. Even so, Bassethound does not overclaim. Detection is a static crawl plus optional JS rendering, and components that stay fully server-side or sit behind a proxy can remain invisible. When that happens, the dossier records the gap instead of inventing a signal. You get what the outside view can prove, labeled as such.

Bassethound perspective

llms.txt has become the answer-engine checkbox everyone games, and any tool that reads its mere presence as an AI-readiness score is measuring marketing, not engineering. Here is the claim a competitor would dispute: a standard llms.txt should count for almost nothing. Some vendors will stamp a domain “AI-ready” the moment they find the file at the root. That is backwards. A curated content map is a publishing decision a marketing team makes in an afternoon, and it survives with zero AI running behind it.

Bassethound splits standard from technical and lets only the machine-facing flavor touch the shipping verdict. A file that lists your docs is not the same as an endpoint a machine calls, and pretending they carry equal weight corrupts the whole score. Real evidence is code that has to run and costs money to run. We rank a loaded vector-store client and an orchestration framework far above any text file, and we say so in the dossier, with the reason attached. If that makes our scores look conservative next to the tools that reward the checkbox, good. Conservative and correct beats generous and gamed.

Sources

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