<!-- Generated from zh/blog/agents-do-not-look-for-llms-txt/index.html. The canonical document is the HTML page. -->

- [ 首页 ](/zh/) 
/
- [ 博客 ](/zh/blog/) 
/
- 一项研究发现，AI 机器人不会探测缺失的 llms.txt 文件            
# 一项研究发现，AI 机器人不会探测缺失的 `llms.txt` 文件

Ahrefs 的 2026年5月 日志提供了一个有用的否定结果：在该样本中，AI 机器人没有请求缺失的 llms.txt 文件。如果你发布了文件，仍需提供发现路径。

最近更新: 2026年8月12日

本页内容

- [ 研究发现 ](#the-finding)
- [ 这为何改变了任务 ](#why-it-matters)
- [ 如何将代理路由到该文件 ](#how-to-route)
- [ 不应得出的结论 ](#what-not-to-conclude)              

## 调查结果

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](https://www.rfc-editor.org/rfc/rfc9309.html) 中正式化，但它仍是抓取器约定，而不是访问控制。

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

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

## 如何将代理路由到该文件

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

**声明关系。** 在 HTML 页面上，为适用的文件添加 ` `；如果存在 Markdown 对应版本，则添加 ` `。相同关系也可以通过 HTTP `Link` 标头发送。子路径上的文件可以描述该部分，并由最具体的路径生效。

**从 HTML 链接到它。** 在页脚或文档导航中放置一个普通的 ` `，会把 URL 放入常规链接图，并为人们提供可见的后备路径。

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

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

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

## 不应得出的结论

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

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

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

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

## 来源

- [ Ahrefs，《我们分析了 13.7 万个站点：97% 的 llms.txt 文件从未被读取（2026年6月）》 ](https://ahrefs.com/blog/llmstxt-study/)
- [ Chrome for Developers，Lighthouse agentic 浏览审计：llms.txt ](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt)
- [ llmstxt.org，规范 ](https://llmstxt.org/)
