如果你最近看过关于 GEO 的建议清单，"在根目录加一份 llms.txt"出现的频率很高，有些审计工具会把它列成检查项。这项建议很少回答一个问题：加上之后，谁会来读。
有两份公开数据能回答这个问题，而且它们数的不是同一件事。一份数的是谁在读——Ahrefs 在 2026 年 6 月发布了对 137,210 个域名的服务器日志分析；另一份数的是里面写了什么——Common Crawl 在同年 8 月 31 日发布了对 584,107 份 llms.txt 文件的内容分析。两组数据指向同一个方向，但理由和多数人的直觉不一样：问题不在于做这件事的站点太少，而在于这份文件既缺少读者，也普遍没有被写成一份可用的索引。 判断该不该投入，需要把这两件事分开看——因为"被取用"和"被引用"本来就不是同一个量，这一点在 AI 可见度的诊断里已经反复出现（见《一次 AI 可见度诊断，到底应该诊断什么？》）。
先把这份文件是什么、不是什么说清楚
llms.txt 由 Jeremy Howard 在 2024 年 9 月提出，目前更新到 v2（规范页面更新于 2026 年 8 月）。按规范原文，一份文件里只有 H1 是必需项，后面可以跟一句摘要引用块、若干 H2 段落，每段是若干条带说明的链接；## Optional 是一个约定段落，供上下文紧张时代理跳过。它也可以放在任意子路径，覆盖该路径下的页面。
格式、放置和生成方式，本站此前单独写过一篇（见《llms.txt 实战：一份仍在演进的站点内容索引》），这里只补一句最关键的定性：规范说这份文件不授予也不阻止任何东西，没有任何爬虫有义务读它。它与 robots.txt 是两类东西——robots.txt 在表达访问许可，llms.txt 是在代理需要信息时按需读取的内容索引。这个区别看起来像教科书定义，但下一节会看到，它正是大量文件出错的地方。
第一个答案：谁在读
Ahrefs 的样本是它自家 Web Analytics 里在 2026 年 5 月有流量的全部 137,210 个域名。做法是对每个域名根目录请求 /llms.txt，确认真的是 Markdown 而不是 HTML 或错误页，再用机器人分析统计所有对 /llms.txt 路径的请求，按响应码、渠道和 user agent 分类。
结果的第一层是：28% 的域名发布了这份文件，其中 97% 在整个 5 月没有收到任何一次请求。
剩下 3%（约 1,100 个域名、约 22,000 次请求）的数据更有意思。这些请求里 96% 来自机器人，4% 来自人类。把四类 AI 相关客户端合起来，它们占 19.5%，是所有类别中最大的一块——看到这个数字很容易松一口气。但拆开是这样：
| 客户端类别 | 例子 | 请求数 | 占该批请求 |
|---|---|---|---|
| AI 代理与代理基础设施 | Claude-Code | 2,302 | 10.5% |
| AI 训练爬虫 | GPTBot、ClaudeBot | 1,179 | 5.3% |
| AI 助理 | ChatGPT-User、Claude-User | 559 | 2.5% |
| AI 检索机器人 | OAI-SearchBot、PerplexityBot | 233 | 1.1% |
真正在 AI 搜索产品里替用户的提问去取内容的那一类，也就是检索机器人，占 1.1%，233 次请求。占最大头的 10.5% 是编码代理一类的代理基础设施。Ahrefs 在原文里的小标题写得很直接：读到这份文件的机器人里有 77% 不属于 AI 工具——SEO 审计工具占 21.7%（其中 Ahrefs 自家爬虫贡献 10.6%），未识别客户端 14.9%，通用网页爬虫 13.1%，技术栈分析工具 11.6%。
如果只看到这里，结论可能还是"读的人少，但总归有人在读"。真正让判断变得清楚的是下一组数据。
在根本没有发布 llms.txt 的域名上，返回 404 的请求里有 98% 来自人类，AI 机器人的占比为零。 Ahrefs 对此的表述是：AI 工具不会去寻找它们不知道存在的文件。人类去请求一个不存在的 llms.txt，多半是在浏览器里手动敲这个地址，推测是在查同行。作为对照，存在且有效的文件收到了 96% 的机器人流量。
这条区别比 97% 本身更有信息量。robots.txt 之所以是通行约定，是因为每个爬虫访问一个域名时都会顺手探测它；llms.txt 没有这种待遇。它不会因为你没发布而少一次机会，也不会因为你发布了就自动进入任何 AI 的视野——按 Ahrefs 的说法，客户端是在链接、索引或用户指令提到这个文件时才会来取。
另一份来自 Otterly.ai 的单站实验（页面更新于 2026 年 2 月）给出了同方向的数字：该站在连续 90 天里收到 62,100 多次 AI 机器人访问，其中 84 次打到 /llms.txt，约 0.1%；同期该站平均每个内容页收到约 265 次 AI 机器人访问。这个口径要说清——它是一个站点的日志，属于单个数据点而非统计结论，要和上面的大样本放在一起看才成立。
这里也要交代 Ahrefs 自己列出的限制：它的样本比全网更技术向、更懂 SEO，所以 28% 这个采用率是上限；分类统计只覆盖收到请求的那 3% 文件；而"请求"是所有数字的天花板，请求数不等于被消费。
第二个答案：里面写了什么
读者少，但如果文件质量高、遇到一个读者就发挥一次作用，它仍然值得存在。Common Crawl 的分析测的正是这一面。
它在 2026 年 7 月的抓取批次（CC-MAIN-2026-30）里做了一次实验：把 /llms.txt 和 /llms-full.txt 加进一批可正常抓取主机的种子列表。最终得到 6,563,125 个 URL 的抓取记录，其中 69.8% 返回 404；19.61% 返回 200，而这部分里只有 45.63% 真的带了文本正文。最终进入内容分析的是 584,107 份文件。
然后是几组最说明问题的数字：
- 68.27% 的文件由模板或插件生成，仅 Wix 一家就占 41.34%。44.87% 的文件提到 MCP，绝大多数是因为 Wix 插了一行指向 API 端点的说明——也就是说，今天 llms.txt 占比最高的一种用法，是建站工具在告诉代理"别爬了，来调接口"。
- 22.56% 的文件里没有任何链接。 一份号称提供精选 URL 列表的文件，一条链接都没有。
- 只有 32.94% 按规范建议给链接写了一句说明；只有 9.71% 有
## Optional段落。 - 99.23% 是 Markdown，49.90% 具备规范要求的完整形态（H1 + 摘要引用块 + H2 链接列表）。
最后一行的对照最关键：结构合规并不是质量指标，因为规范只强制一个 H1。 Common Crawl 举了两个极端例子。GoDaddy 的域名停放页合规率是 100.00%，链接数为零——一份只写着"这个域名在出售"的文件能通过所有结构检查。另一头，All in One SEO 生成的 73,136 份文件里，写摘要的比例是 0.00%，但中位数有 138 条链接、8,772 个 token，它把 llms.txt 当成 sitemap 在用。同一个文件名下，两端对它的理解完全相反。
被写成政策文件的那 6.59%
还有 6.59% 的文件携带了规范从未提及的政策语言：限速声明 3.05%、版权声明 0.93%、要求被引用 0.46%。写法还分成四种互不兼容的方言——散文段落、YAML 权限块、robots.txt 行语法，以及把几种混在一起的。
同一方向的另一个数字更直白：10.61% 以 llms.txt 路径成功返回的响应，内容其实是 robots.txt。 有大量站点把 robots.txt 直接放在了 llms.txt 这个路径上，大概因为两者都是"给机器看的文本文件"，被当成同一类东西。
Common Crawl 顺手做了一次交叉验证：全库只有 0.27% 的文件点名了具体爬虫，其中有 32 份在里面表达了拒绝 CCBot 的意思。研究方在 2026 年 8 月 17 日去取这 32 个站点的 robots.txt，没有一个是真的在拒绝 CCBot。写在 llms.txt 里的"拒绝"，对真实抓取行为没有约束力。这是规范那句"不授予也不阻止任何东西"的实测版本。
一个安全侧的观察
Common Crawl 还想知道这些文件里有没有写给模型看的指令。用词表分级后筛出 3,793 份轻微引导、102 份带推广意图、10 份达到最高级别。10 份少到可以逐份读完，人工确认其中 4 份是真实的，作者判断都是懂技术的人故意放置的，包括一份明确标注为漏洞赏金研究的载荷收集器。
真正的发现不是"llms.txt 里塞满了注入"，而是：这个文件位于一个可预测路径上，代理框架被鼓励去取它，而基本没有安全工具检查它。 实务含义是不要把它当成指令通道。写进 llms.txt 的"要求"既不改变抓取行为也不会被执行，反而把自己变成了不受信输入的一部分。它是一份给读者看的内容文件。
那该怎么做
把两组数据合起来，判断会清楚一些。
如果你的目标是 AI 搜索答案里的引用和推荐，现有公开数据不支持把 llms.txt 当杠杆。 九成以上的文件无人请求，真正在替用户问答取内容的检索机器人只占被读文件流量的 1.1%，而占大头的编码代理解决的是另一类问题。一组受控实验也已经显示，"被引用"是可以被排版、位置和解码噪声重新分配的量，和"被收进来"是两件事（见《同一份证据，AI 只引用其中一份》）——这类文件即便被取用，也不落在引用增长的那个环节上。把"有代码代理在读"当成"AI 搜索会引用我"，是目前最常见的误读。
如果你的读者里确实有编码代理和文档工具，它有真实用途。 规范 v2 明确说软件文档是它被使用最多的场景，并在集成列表里列出了已能自动生成它的文档平台与 CMS；Common Crawl 从另一侧证实了这点——近七成文件出自模板和插件，而不是人手写。
不论哪种情况，先做的都不是决定"加不加"，而是用你自己的日志判断它现在有没有在工作。两步：
- 按客户端分类统计 /llms.txt 的请求，不要只看总数。 把 AI 检索机器人、AI 训练爬虫、AI 助理、编码代理、SEO 审计工具、llms.txt 扫描器分开统计。这个区分在 Ahrefs 的数据里差了将近 20 倍——审计类工具占 21.7%，而真正替用户问答取内容的检索机器人占 1.1%。如果你日志里对 /llms.txt 的请求全部来自审计和扫描类工具，说明它现在没有在为你工作——你看到的是别人在检查你，不是机器在用它。
- 逐条请求文件里的链接。 索引的价值全部落在链接上，而 22.56% 的文件一条链接都没有。这一步不需要额外工具，一条命令就能做完。
我们对自己的文件做了这件事。aigeo.guru 在根目录发布 /llms.txt。本文定稿于 2026 年 9 月 17 日，当天该文件包含 56 个站内 URL，逐条请求全部返回 HTTP 200；线上响应与本地构建产物 SHA-256 一致；文件结构为 1 个 H1、1 个摘要引用块和 8 个 H2 段落。我们保留它的理由是：它对人和机器都是一个可读的站点索引，成本只是一个静态文件。（这个索引由构建自动生成，本文上线后条目会随之增加，所以具体条数会随时间变化，重要的是它是否还能逐条打开。）
这里必须把限制写清楚。这不构成任何"它有效"的证据——我们没有可对照的抓取或引用数据，无法说明它带来了什么；56 条链接全部可访问，只说明索引里的链接当下打得开，不说明它们被任何 AI 客户端取用过。我们留着它是因为成本足够低，而不是因为它有用。同样直白的一点：我们自己的文件是 21.6 KB，而规范建议这份文件保持小到能装进上下文；它是否偏大，本文不下结论，这是我们要继续看的事。
本文由 AIGEO.GURU 官网日更流程整理：资料核验、初稿撰写与编辑校对过程有 AI 参与，发布前按本站编辑标准逐项自查；文中的事实、数字均标注来源，分析与判断部分属于 AIGEO.GURU。除对本站 /llms.txt 索引做的链接可访问性请求之外，我们没有对上述外部数据做二次测量。
如果你正准备花一个下午做 llms.txt，更划算的顺序可能是：先把日志拉出来，看有没有你真正在意的那类客户端来取过它；如果没有，把这个下午花在内容本身和可被引用的具体事实上。反过来，如果你在为文档和编码代理做内容，那就把它当成一份要维护的索引来做——写清每条链接的说明、定期检查链接是否还能打开，别把 sitemap 倒进去，也别把它当政策文件用。