我审查了 70 家公司的 llms.txt 文件，大多数没有
所有人都在写 llms.txt 教程，但没人去检查这些公司真的做了没。我对 70 个理应有 llms.txt 的网站做了实测——AI 实验室、文档平台、开发基础设施巨头、大型 SaaS——只有 31 家有真文件。31 家里又有 12 家不符合社区自己定义的格式。下面是数据。
/llms.txt 这份提案是 2024 年底提出的。两年过去，每个 SEO 博客都写过它的教程；每篇讨论"GEO"（生成引擎优化）的文章都把它当成清单上的勾选项；WP Engine 在过去一个月发了五篇关于它的文章；Mintlify 为它做了产品功能。
只有一件事没人做：检查那些理应有 llms.txt 的网站到底有没有，以及它们做出来的东西到底像不像样。
所以我跑了个脚本，扫了 70 个站——AI 实验室、文档平台、开发基础设施大厂、当下热门 SaaS、WordPress 媒体——抓下它们的 /llms.txt。下面是我看到的。
结论先放这：70 家里 31 家（44%）有真 llms.txt。剩下 56% 要么 404，要么返回了 HTML（SPA 路由把这个路径吃掉了），要么干脆给爬虫 403。这 31 个真文件里，有 12 个（41%）不符合 llmstxt.org 自己定义的格式。文件体积从 648 字节到 280 KB，相差 432 倍。你以为会领跑的公司——OpenAI、Hugging Face、Google AI、Mintlify、GitBook、ReadMe——一个都没有。
测试方法
我从八个类别里挑了 70 个站：
- AI 实验室（Anthropic、OpenAI、Mistral、Cohere、Perplexity、Hugging Face、Google AI、Replicate、ElevenLabs）
- AI 编程工具（Cursor、Codeium、Windsurf、Claude、Aider）
- 文档平台（Mintlify、GitBook、ReadMe、Redocly、Docusaurus）
- 开发基础设施（Vercel、Supabase、Stripe、Cloudflare、Fly、Netlify、Railway、Render、Bun、Deno）
- 现代 SaaS（Linear、Notion、Retool、Raycast、Framer、Airtable、Segment、Amplitude、Mixpanel、PostHog）
- WordPress 生态（Kinsta、WP Engine、Yoast、ManageWP、Cloudways、WordPress.com、WP Tavern）
- llms.txt 提出方（llmstxt.org、fast.ai、AnswerAI）
- 社区 / 出版平台（dev.to、Hacker Noon、Substack、Indie Hackers、GitHub、GitLab）
对每个站，我用普通浏览器 User-Agent，不加特殊头，直接 GET https://<域名>/llms.txt。解析响应体看是不是真 markdown（开头是 # 标题）还是 HTML（SPA fallback 吃掉了路由）。
对每个真样本，量化了七个维度：
- 文件字节数
- 行数
- H2 章节数
- markdown 链接总数
- 深度内链 / 营销首页 / 外链 各占比
- 是否符合 spec 的
# 标题+> 简介引用格式 - 前 200 字符（用来漏检启发式没识别出的 HTML fallback）
就这些。没登录、没 API key、没特殊爬虫——任何 LLM 爬虫都会发出的同样的 HTTP GET。
发现 1：超过一半"应该有"的站根本没有
| 结果 | 数量 | 占比 |
|---|---|---|
真 llms.txt |
31 | 44% |
| 404 | 22 | 31% |
| HTML fallback（200 但 SPA 返回） | 9 | 13% |
| 403 / 530 / 超时 | 8 | 11% |
44% 这个数字已经够难看。但更难看的是，"理应有"那一群里最响亮的都缺席：
- OpenAI：根域名 403，platform.openai.com 404。世界上最被讨论的 LLM 是他们做的，但他们自家文档没有 llms.txt 帮 LLM 找到。
- Hugging Face：404。这个平台存在的全部意义就是托管那些"读文本"的模型。
- Google AI（ai.google.dev）：302 跳转，跳过去也没有 llms.txt。
- Mintlify——这家公司正在向客户卖"一键加 llms.txt"产品功能——自家营销站 404，自家文档站 530。
- GitBook、ReadMe：都 404。
- fast.ai：404。Jeremy Howard 的网站。llms.txt 这事就是他提出来的。
- WP Engine、Kinsta、WP Tavern、ManageWP：404 或 HTML fallback。同样这几家 WordPress 主机商，每个月发五篇关于 GEO 和 AI 搜索排名的内容系列。
可以反驳一句："llms.txt 只对那种 LLM 会在答案里引用的站有用；OpenAI 没必要为 ChatGPT 引用 OpenAI 做优化。" 行。但这解释不了 Mintlify——他们当下整个卖点就是"用我们的平台一键加 llms.txt"。如果他们自己都不吃自己的狗粮，你应该问问为什么。
HTML fallback 那一组（9 个站返回 200 但是 HTML 正文）也值得单独看。Cohere docs、Cursor docs、Codeium、Windsurf、Claude.ai、Kinsta、Notion、Segment、Deno 全在这组。这些站跑的是 Next.js / Vue / 同类 SPA 框架，框架默认的 catch-all 路由把 /llms.txt 当成应用路由，返回了 React 外壳。没人发现。没人监控。LLM 爬虫抓到的"llms.txt"是一坨 50 KB 的 <div> 和 JavaScript bundle URL，里面甚至没有"llms.txt"这个词。
这是最尴尬的一类。404 是明确的"我没有"。HTML fallback 是无意识的"我以为我有但其实没有"。你跑了个工具，从 CMS 里复制了一段，以为搞定了，结果没。
发现 2：存在的文件里 41% 不符合格式
llmstxt.org 自己定义的 llms.txt spec 简单到不行。结构上只有两个必选元素：
- 文件开头一个
# 标题H1。 - H1 后面紧跟一个
> 引用块，用一句话说这个站是干嘛的。
完了。剩下的章节、链接、## H2 分组——都是自由发挥。
去重后的 29 个独立样本里（cloudflare.com / www.cloudflare.com 和 cursor.com / www.cursor.com 是同一份）：
- 17 家（59%）符合 H1 + 引用块格式。
- 12 家（41%）跳过了引用块。 有的连 H1 都没。
不合格名单不是你以为的那种新手：
| 站 | 章节数 | 链接数 | 哪里错 |
|---|---|---|---|
| docs.anthropic.com | 3 | 1,415 | 没有引用块简介 |
| docs.stripe.com | 26 | 528 | 没有引用块简介 |
| render.com | 6 | 295 | 没有引用块简介 |
| bun.sh | 2 | 317 | 没有引用块简介 |
| netlify.com | 10 | 83 | 没有引用块简介 |
| developers.cloudflare.com | 9 | 103 | 没有引用块简介 |
| docs.mistral.ai | 1 | 75 | 单一章节，没有简介 |
| elevenlabs.io | 7 | 49 | 没有引用块简介 |
| cursor.com | 20 | 0 | 没有引用块，且零 markdown 链接——只是裸 URL 列表 |
| replicate.com | 7 | 1 | 没有引用块简介，链接几乎为零 |
| amplitude.com | 7 | 0 | 没有引用块，零链接 |
| supabase.com | 2 | 19 | 没有引用块简介 |
Anthropic——LLM 生态里字面意义上的标杆客户——发了 150 KB 的链接，开头没有任何一句引用块。Stripe 发了 90 KB 结构化文档索引，开头没有任何一句话告诉读者"这是 Stripe"。这些都不是新手网站，他们有专门的技术写作者。
这看起来像什么呢：平台团队某个工程师按 docs sitemap 自动生成了 llms.txt，发了，没看 spec。爬虫抓到这个文件，看到一片链接，不知道这个站到底是什么。
Cursor 的最怪。20 个章节，嵌套得很整齐，零 markdown 链接——每一行都是裸 URL：
## Get Started
- https://cursor.com/docs.md
- https://cursor.com/docs/get-started/quickstart.md
- https://cursor.com/docs/models-and-pricing.md
- https://cursor.com/docs/models/claude-4-6-sonnet.md
而且里面至少有一处拼接 bug：https://cursor.comhttps://cursor.com/changelog.md 直接写在那儿。如果某个 LLM 爬虫对 markdown 链接解析比较严格，Cursor 的文件可能有一半对它而言是隐形的。
发现 3：文件大小相差 432 倍，关于这个文件是什么没人达成共识
最小的真 llms.txt：648 字节。这是 llmstxt.org 自己——这份 spec 的发源地——指向三个文档。
最大的：279,743 字节。PostHog，看起来像是把整个文档站点 sitemap 都倒进去了，外加每个条目的散文式标注，54 个 H2 章节，2,555 个 markdown 链接，每个指向某个文档页面的 .md 版本。
中间隔着八个数量级的实操差异：
| 区间 | 数量 | 例子 |
|---|---|---|
| 极小（<1 KB） | 1 | llmstxt.org（648 字节） |
| 小（1-5 KB） | 8 | railway.app（1.4 KB）、supabase.com（1.3 KB）、amplitude.com（2.8 KB）、replicate.com（3.4 KB）、mistral.ai（4.9 KB）、cohere.com（4.8 KB）、hackernoon.com（4.9 KB）、answerai.com（1.8 KB） |
| 中（5-20 KB） | 9 | linear.app、cursor.com、framer.com、yoast.com、wordpress.com、cloudflare.com、elevenlabs.io、docs.mistral.ai、developers.cloudflare.com |
| 大（20-100 KB） | 9 | docs.perplexity.ai（22 KB）、github.com（28 KB）、bun.sh（33 KB）、render.com（36 KB）、netlify.com（20 KB）、stripe.com（64 KB）、cloudways.com（64 KB）、docs.stripe.com（93 KB）、redocly.com（98 KB） |
| 巨型（100 KB+） | 2 | docs.anthropic.com（152 KB）、posthog.com（280 KB） |
中位数：9.4 KB。平均：34.7 KB。平均值被两个巨型异常值拉高了——多数站的文件其实很小。
这个分布直接对应"llms.txt 到底是什么"的两种不同理念。spec 文本对此态度模糊，于是大家各自做了选择：
理念 A（spec 给的示例）：llms.txt 是一个微型指针文件。几百字节。一个标题、一句话简介、几个最重要页面的链接。LLM 自己去爬那些链接。llmstxt.org（648 B）、supabase.com（1.3 KB）、railway.app（1.4 KB）、answerai.com（1.8 KB）属于这一派。
理念 B（索引倾倒）：llms.txt 是给 LLM 用的全量 sitemap。每一个文档页面都列上。PostHog（280 KB）和 Anthropic 文档（152 KB）大致按这种方式把整个 docs map 倒进去。Stripe（90 KB）是稍微精简版的同样思路。
哪一种是对的，没有共识。Mintlify 的产品（能用的时候）输出的是理念 B。手写的多半趋向理念 A。280 KB 的文件对模型 context 来说想必负担不小；648 字节对模型来说想必信息又太少。
诚实的回答是：现在没人知道哪种更管用，因为没人公开发过数据，证明任何一种做法带来了更多 LLM 引用或流量。
发现 4：链接质量其实可以——但链接数量被几个大文件拉偏了
好消息：当各家网站真的在 llms.txt 里放链接时，那些链接基本都是有用的。
29 个样本累计 7,557 个 markdown 链接：
- 73.8% 是深度内链（路径有两段或更多——
docs.example.com/api/v2/something） - 23.3% 是外链（多数是引用标准、SDK、GitHub repo）
- 2.9% 指向营销首页（首页或顶级目录页——
/pricing、/about）
2.9% 这个数字让人松了口气。本来对 llms.txt 最大的担心是各家公司会把它当 SEO 漏斗——把 AI 引到首页和定价页。结果他们基本没这么干，链接确实指向有用的文档。
坏消息是这个总数被几个大文件严重拉偏。PostHog 一家就贡献了 7,557 个里的 2,555 个，三分之一。Anthropic、Redocly、Stripe、Cloudways 再贡献 3,000+。多数站的链接数其实在 0 到 100 之间。
四个站零 markdown 链接：amplitude.com、cohere.com、cursor.com、hackernoon.com。Cursor 和 Hackernoon 用裸 URL 字符串（某些爬虫能用，技术上不是 markdown）。Amplitude 和 Cohere 干脆用散文描述自家产品，作为上下文勉强算有用，但不是 spec 设计的用法。
发现 5：WordPress 生态几乎全军覆没
测试的 7 个 WordPress 生态候选里：
- Cloudways、Yoast、WordPress.com：有。✅
- Kinsta：HTML fallback（你以为他们有，他们没有）。❌
- WP Engine、ManageWP、WP Tavern：404。❌
这个结果特别刺眼，因为 WP Engine 最近一直在猛推"GEO"——生成引擎优化。一个月里发了五篇专文，包括《Technical GEO: Ensuring Sites are Machine Readable》。写这些文章的人服务的公司，自家营销站没有 llms.txt。
Kinsta 的 HTML fallback 更有意思。他们出内容教 agency 怎么把网站做得对 AI 友好。他们大概觉得自家已经有了 llms.txt——可能装了某个插件。插件没起作用——Next.js 路由把 /llms.txt 吃成了 React shell。他们团队没人检查过。
WordPress 生态里，"写关于 llms.txt 的文章" 和 "拥有 llms.txt" 之间的距离接近无穷大。
发现 6：HTML fallback 这个问题比表面看上去更大
那 9 个返回 200 OK 但响应是 HTML 的站，值得单独说，因为从任何监控工具的角度看，它们都是"成功"。
如果你 curl -I kinsta.com/llms.txt，拿到的是 200。你 CDN log 上看到所有访问 /llms.txt 的请求都拿到了数据。什么都没坏。
但响应体是 React 应用。把响应当 markdown 解析的 LLM 拿到的是 50 KB 的 <div class="..."> 加上一堆 JavaScript bundle URL。LLM 没办法知道这不是你的本意。
涉及的站：
- Cohere docs、Cursor docs（这俩公司的主域名有 llms.txt 但 docs 子域名 catch-all）
- Codeium、Windsurf、Claude.ai——AI 编程工具自己没有 llms.txt
- Notion（最有可能被 LLM 引用的 SaaS）
- Segment、Kinsta、Deno
它们多数跑现代 JS 框架，框架默认的 catch-all 路由处理了未知路径。修复就一行配置：要么让 /llms.txt 显式 404，要么真返回文件。没人去改。
如果你的站跑 Next.js / Nuxt / Astro / 类似框架，这是第一件该查的事。用 curl 访问自家 /llms.txt，读 body。如果看到 <!DOCTYPE html>，无论你本来有没有打算做 llms.txt，都有问题。
发现 7：没人有证据这玩意儿真的有用
这篇审计写到最后最难的部分，是承认：现在没有证据 llms.txt 干了什么有用的事。
我特意找过：
- 有没有公开数据显示，有 llms.txt 的站比没有的站，在 Perplexity / ChatGPT / Claude 答案里被引用得更多？
- LLM 爬虫真的在请求
/llms.txt吗？（Cloudflare 公开了部分 bot 流量数据，但不针对这个路径。） - 有没有任何经 A/B 测试的案例，证明加上 llms.txt 改变了引用份额、推荐流量、或任何可测量的东西？
三个问题，2026 年中的答案都是"基本没有"。有逸闻。有教程。有读起来像供应商营销的案例。但没有严肃的公开证据证明 llms.txt 真的影响了什么。
也可能——其实很可能——大 LLM 服务商把它当作 hint 在读，类似某些搜索引擎读 sitemap.xml 的方式。也可能他们没在读，整个围绕这个文件的讨论是 SEO 行业为了填补"AI 答案引擎到底怎么排名"这个谜团的沉默。
最有意思的事实是：连那些商业模型最直接受益于 llms.txt 真的有用的公司——模型提供商自己——多数都没给自家文档站写一份。这要么是因为他们知道一些 SEO 行业不知道的事，要么是因为他们和所有人一样困惑。
我觉得这意味着什么
几个谨慎的结论。不是建议——互联网上的 llms.txt 建议已经太多了。只是盯了 31 个真文件一天得出的观察。
1. llms.txt 是靠默认胜出，不是靠采纳率胜出。 这是这个领域唯一一个有公开拥护的提案。但"我听说过"和"我加到我站上了"不是一回事。多数站都没加。加了的，多数没加好。
2. 真正的开放问题是理念 A 还是理念 B，不是"该不该加 llms.txt"。 648 字节的指针文件和 280 KB 的 sitemap 倒卖，不可能同时是同一份 spec 的正确解读。在有人公开发出"哪种检索效果更好"的真数据之前，所有"最佳实践"文章都是在猜。
3. HTML fallback 是当下杠杆最高的修复点。 如果你用现代 JS 框架，且从来没检查过自家 /llms.txt 响应体——你大概率有一个沉默的漏掉。一行 curl 能看出来。一行路由配置能修好。
4. 遵守 spec 几乎免费，但几乎没人做。 41% 的存在的文件跳过了开头的引用块。爬虫读这些文件得从 URL 列表里猜这个站是干什么的。在 > 引用块里加一句话十秒钟搞定，可能比下面那一堆精致的结构更重要。可能。
5. "写关于 llms.txt 的文章"和"拥有 llms.txt"之间的差距非常大，在 WordPress 和主机商生态尤其明显。 这要么是机会（其他人都在睡觉），要么是信号（最贴近 SEO 的人已经算过了，决定跳过）。你自己挑。
关于样本数据
如果想看原始数据：我把 31 个真 llms.txt 文件、probe 脚本、分析输出都做了公开镜像。方法简单到你可以在 5 分钟内对自己的怀疑名单跑同样的审计。
至少值得对自家站跑一次。HTML fallback bug 是沉默的，spec 是短的，万一 llms.txt 真有用——一个格式正确的文本文件就够了。
如果有人跑出来的结论和我这个差得很远，我真心想看看。特别是有人能拿出引用份额数据证明这事真在起作用。在这件事上，目前观点的市场喧嚣，证据的市场沉默。
数据说明：70 个候选站点于 2026-05-16 用普通 HTTP GET + 桌面浏览器 User-Agent 探测。31 个返回真 llms.txt。去掉镜像域名（cloudflare.com / www.cloudflare.com、cursor.com / www.cursor.com）后 29 个独立样本。Probe 脚本、原始响应、单站分析均做了镜像。
方法局限：只探测了根路径 /llms.txt。某些站可能在子域名或带版本的路径下也有 llms.txt。没检查 spec 里可选的 /llms-full.txt（详细版）。按 IP 或 User-Agent 阻断自动请求的站（Reddit、部分 Indie Hackers）可能有看不到的真文件。HTML fallback 这一类是假阴性风险，估计低估了真实采纳率 1-3 个站。