谁在请求 llms.txt？是智能体，而非 AI 搜索爬虫

实测明细

Ahrefs 对在 137,210 个域名中请求 /llms.txt 的每个用户代理进行分类，统计时间为 2026年5月，并将其分为 12 类。在大约 38,000 个被接受的文件中，只有 3% 收到过任何请求，也就是这个技术样本中的约 1,100 个文件。下面的明细描述的是这些请求，而不是完整总体，也不是模型最终使用了什么。

四个类别高于每个单独的 AI 类别：

| 类别 | 请求占比 | | ––––––––––– | —————– | | SEO 审计工具 | 21.7% | | 其他及未识别 | 14.9% | | 通用 Web 抓取器 | 13.1% | | 技术画像工具 | 11.6% |

具名 AI 机器人合计占 19.5% 。按用途拆分后，图景会清晰得多：

| AI 机器人类型 | 占比 | | ———————————— | —– | | AI 代理和代理基础设施 | 10.5% | | AI 训练抓取器 | 5.3% | | AI 助手 | 2.5% | | AI 检索机器人 | 1.1% |

另有 12% 来自研究这一约定而非消费它的行业：GEO 和 AEO 评分工具占 5.8%，专用 llms.txt 扫描器和目录占 3.6%，研究型抓取器占 2.7%。

一个对比就能看清规模：作为链接预览机器人的 Slackbot，抓取 llms.txt 文件的频率高于 PerplexityBot。

在已测量的 AI 抓取中，代理占主导

第二张表的最后一行值得特别注意。AI 检索机器人，也就是为回答 AI 搜索产品中的实时用户问题而抓取页面的爬虫，例如 OAI-SearchBot 和 PerplexityBot，占所有测量请求的 1.1% 。Ahrefs 报告称，OAI-SearchBot、PerplexityBot 和 Claude 的搜索爬虫合计只进行了几百次抓取。

与此同时，AI 代理及其服务基础设施占 10.5%，Claude-Code 抓取的文件多于数据集中的所有检索机器人、所有助手和所有训练抓取器。

这与 Google 的说法一致，而不是相互矛盾。正如我们在Google 是否使用 llms.txt中介绍的，John Mueller 公开表示没有 AI 服务说过自己使用该文件；他把它比作 keywords meta 标签：网站所有者关于自身的声明，而系统直接读取网站就能以更低成本验证。

训练抓取器是第二大的 AI 类别，占 5.3%，抓取 llms.txt 的频率接近检索机器人五倍。如果文件会产生影响，数据指向上游的语料构建阶段，而不是答案生成的时刻。

这对你所写内容意味着什么

如果预期使用者是代表开发者工作的编码代理，那么许多通常的直觉都是错误的。

营销页面不是正确条目。 被问到“如何向这个 API 进行身份验证”的代理，需要参考页面、错误代码和可运行示例。你的价格页面帮不上它。最佳实践说明了一般情形，而阅读数据让它变得具体。

结构胜过广度。 规范是经过整理的索引，不是站点地图。列出 40 个页面的文件并不会为代理节省什么，因为它仍然需要作出选择。12 个描述清晰的条目就能发挥作用。

描述承载信号。 每个链接的描述是代理决定是否花费一次抓取前唯一能看到的内容。“API reference”几乎毫无用处。“REST endpoints、auth headers、rate limits 和 error codes”才是路由决策。

如果文档就是产品，请考虑 llms-full.txt。 如果目标是把内容交给代理而不是给它一张地图，那么配套文件就是为此存在的；请参阅什么是 llms-full.txt。

正如我们在没有 AI 代理会主动寻找你的 llms.txt中介绍的那项发现一样，在有人告诉代理文件存在之前，这些都没有意义。

这里的每个数字都是上限

Ahrefs 对此说得很明确，不应把它埋起来而应重复说明：日志中的请求只能证明客户端取得了字节，无法证明模型阅读、使用或丢弃了它们。因此，他们 19.5% 的 AI 占比是对 AI 消费最宽松的解读，而不是消费量估计。

他们的总体也更偏技术，因为样本来自自己的分析客户，这正是他们把 28% 的采用率作为上限的原因。我们自己的采用率样本测量的是完全不同的总体，不能直接比较。