一项研究发现，AI 机器人不会探测缺失的 llms.txt 文件

调查结果

Ahrefs 分析了 137,210 个在 2026年5月 获得流量的域名的服务器日志，然后对请求 /llms.txt 路径的每个用户代理进行分类。其中一个结果明显不同，但它不是标题所强调的那个结果。

他们另外查看了返回 404 的请求，也就是客户端请求了不存在的 llms.txt。在 2026年5月 的样本中，这些请求来自已识别 AI 机器人的比例为 零 。缺失文件获得了 98% 的人工流量，而被接受文件获得了 96% 的机器人流量。日志无法说明每个人为何请求该 URL。

换句话说，这项研究没有观察到 AI 机器人探测缺失的根文件。这是关于该样本和该月份的证据，并不能证明任何系统都不会进行发现。

这重新表述了同一研究的核心发现：在他们找到的大约 38,000 个有效 llms.txt 文件中，97% 在该月份完全没有收到任何客户端、机器人或人类的请求 。

这为何改变了任务

大多数人心中的隐含模型是 robots.txt 模型：把文件放在根目录，遵循机器人排除协议的抓取器就知道它的标准位置。该协议已在 RFC 9309 中正式化，但它仍是抓取器约定，而不是访问控制。

对于 llms.txt，这不是安全的假设。正如我们在llms.txt 实际做什么中说明的，这一约定由 Answer.AI 的 Jeremy Howard 在 2024年9月 提出，详见相关说明。v2 规范定义了发现关系和路径范围文件，但没有要求每个客户端抓取它们。Ahrefs 在其样本中没有观察到针对缺失根文件的推测性 AI 请求。

因此，发布文件大约是工作的一半，而且这一半本身不会带来一次抓取。另一半是让某个地方告诉代理文件的存在。

如何将代理路由到该文件

先从 v2 定义的发现机制开始，然后在有帮助的地方加入人类可见的路径：

声明关系。 在 HTML 页面上，为适用的文件添加 <link rel="describedby" href="/llms.txt">；如果存在 Markdown 对应版本，则添加 <link rel="alternate" type="text/markdown" href="...">。相同关系也可以通过 HTTP Link 标头发送。子路径上的文件可以描述该部分，并由最具体的路径生效。

从 HTML 链接到它。 在页脚或文档导航中放置一个普通的 <a href="/llms.txt">，会把 URL 放入常规链接图，并为人们提供可见的后备路径。

在文档中引用它。 如果你的产品有文档网站，那么一个明确写出 URL、标题为“面向 AI 助手”或“面向代理”的页面，就能在开发者询问 API 时给编码代理一个可采取行动的目标。Ahrefs 发现，AI 代理和代理基础设施是抓取这些文件的最大 AI 类别，占请求的 10.5%，远高于 1.1% 的 AI 检索机器人。Claude-Code 在其数据中抓取的文件多于所有检索机器人、所有助手和所有训练抓取器。这些都是开发者会指向某个 URL 的工具。

把它放在指令所在的位置。 只要用户或集成向代理提供关于你网站的上下文，例如 README、入门页面或 MCP 服务器描述，写出 llms.txt URL 就能把发布变成可发现的路径。

这些要求都不需要修改文件本身。如果你还没有写文件，如何创建 llms.txt介绍格式和各技术栈的部署，验证器则根据规范检查它。

不应得出的结论

Ahrefs 自己就说明了两个诚实的限定条件。

他们的总体偏向技术和 SEO，因为样本来自自己的分析客户。他们将 28% 的采用率标为上限 ，而不是整个 Web 的比率。我们自己的采用率样本追踪一份固定的重要主机列表，是对不同总体的不同测量，不应直接比较。

而且“抓取到”不等于“阅读过”。服务器日志中的一次请求只能证明客户端取得了字节，无法证明模型随后使用了它们。因此，该研究中的每个数字都是实际消费量的上限，而不是对消费量的估计。

这两个限定条件都不改变实际结论。如果发布 llms.txt 却没有声明关系、链接或其他通往它的路径，Ahrefs 的样本没有理由让人假设代理会自行发现它。添加基于标准的发现信号，是一个小而可测试的修复。