llms.txt：28% 站点已发布，97% 全月零请求

llms.txt 的实证结论由三个数字连成闭环：据 Ahrefs 对 137,210 个域名的统计（2026-05），28% 的站点已发布 llms.txt，但 97% 的文件整个月零请求，而 AI 检索爬虫仅占这些站点全部请求的 1.1%。发布率不低、消费近乎为零——这份清单文件目前对“被 AI 引用”没有可测量的作用。我们的结论直说：部署成本近零可以顺手做，但 GEO 效果预算应为零。

13.7 万域名上的三层数字

先看样本。137,210 个域名来自 Ahrefs Web Analytics 的用户群——一个偏技术、偏 SEO 的群体，对新兴标准的采纳热情高于全网平均，因此 28% 的发布率应读作上界，普通行业站点的实际发布率只会更低。即便在这个最积极的样本里，消费侧仍是冰点：97% 的 llms.txt 全月没有任何请求，检索爬虫占全部请求的比例也只有 1.1%。研究档案见Ahrefs：13.7 万域名的 llms.txt 采纳与请求研究。

样本里还有一个颇具讽刺性的细节：Slackbot 的请求都多于 PerplexityBot。一个企业通讯工具的链接预览爬虫，比正牌 AI 搜索的检索爬虫更常来敲门——这直观呈现了检索爬虫请求盘子之小，与抓取量级侧的证据互相印证：四大 AI 爬虫月请求合计约为 Googlebot 的 28%，其中检索型仅占约 1.1%，口径见四大 AI 爬虫月请求合计约为 Googlebot 的 28%。

为什么它没被消费：机制上的三个原因

其一，它是提案不是标准。llms.txt 尚未进入任何主流引擎的官方抓取规范，没有厂商承诺读取它，更没有厂商承诺按它行事，文件格式的设计取向见llms.txt。其二，它没有解决引擎的痛点。检索型爬虫决定抓什么、信什么，依据的是可达性、内容结构与质量信号，这些信息 robots 协议、站点地图与页面本身已经承载，一份额外的 Markdown 清单没有提供引擎必需的新信号。其三，激励错位。对引擎而言，按自己的检索与排序逻辑选源是产品质量的核心，没有理由让站点的自我申报凌驾于自己的判断之上。

与 robots.txt 的对照能看得更清楚：robots 之所以被遵守，因为它表达的是禁止性指令，引擎不遵守要承担法律与舆论成本；llms.txt 表达的是推介性意愿——“希望你先读这些”——引擎没有对应的遵守义务。两者效力差异的根源在指令性质，展开见robots.txt（AI 语境）。

还可以从反面想：如果一份自我申报的清单真能左右被引，它会立刻成为操纵目标。引擎对任何可被站方单方面改写的信号都天然警惕——这是检索系统设计的基本约束，与当年元关键词标签的衰落一脉相承。零消费的状态与其说是技术懒惰，不如说是激励结构的必然。

那还要不要部署：把它放回正确的位置

我们的口径是“顺手做，零预期”。写一份 llms.txt 的成本以分钟计，把核心内容的结构化清单放上去，万一未来某家引擎开始消费，你已经在场；但任何以“提升 AI 可见度”为名的 llms.txt 咨询、审计与代理服务，目前都没有证据支撑。预算应当流向真正影响被引的环节：服务端渲染保证内容可达、即答段与切块友好的页面结构、持续的内容更新；爬虫类型的辨析与放行策略，见训练·检索·用户触发爬虫（三型）。预算的去向也有实证参照：目前与 AI 可见度相关性最强的信号是品牌提及而非任何站点侧文件，口径见品牌提及与 AI 可见度相关性 0.664，外链仅 0.218——分钟级的 llms.txt 部署完成之后，剩余预算应流向“被讨论、被转述”的经营，而不是围绕清单文件本身做深加工。这也是我们把它归为顺手项而非战术项的完整理由。

判断一项 GEO 投入值不值，本卡提供了一个样板问法：这个动作影响引擎决策的哪个环节？检索爬虫能不能抓到（可达性）、抓到后能不能切块匹配（结构）、匹配后能不能被信任（质量信号）——llms.txt 在三个环节里都不在场，这比 97% 零请求更根本地解释了它为什么无效。

顺带处理一个常见追问：llms.txt 与站点地图、robots 是什么关系？三者处在同一条谱系上——robots 管准入，站点地图管发现，llms.txt 想管理解。前两者已是事实标准，引擎有明确的遵守义务与稳定的行为记录；后者连被读取都尚未发生。部署顺序因此很清楚：先把站点地图与 robots 的基础做扎实，再谈 llms.txt——前者影响可达性这个真实环节，后者目前只是表达意愿。

一个诚实的补充：llms.txt 作为内部工程产物仍有价值。整理它的过程强迫团队盘点内容资产，把核心页面与摘要写成机器可读的结构，这份清单喂给自家接入的 AI 应用（站内问答、客服机器人）是可用的。把它当内部工程文档做，而不是当外部 GEO 神器卖，是这份文件当前的合理定位。内部使用的边界同样要清楚：喂给自家应用的是经过人工核对的结构清单，不是生成结果的排序依据——机器可读不等于机器可信。

自查与前景：日志比新闻诚实

自查动作给到具体：发布 llms.txt 后，在日志里为这个路径单独建一条过滤规则，按月看有没有请求、请求方是谁。一个月后绝大多数站点会看到零——这不是失败，只是确认行业现状；真有请求出现时，再分辨它来自检索爬虫还是扫描器。这个动作成本以分钟计，却能把“文件是否被消费”从猜测变成事实，也是对各家厂商说法最直接的复核。

对这份文件的前景，我们的判断是：即使将来被消费，大概率也先以建议性信号而非指令的形态出现——引擎可能用它辅助发现与理解站点结构，但不会把站点自我申报的重要性直接当排序依据。标准被采纳的一般路径是先有厂商小规模实验、再有行业跟进、最后沉淀为惯例；在那之前，任何“已支持”的说法都应要求对方给出可复验的请求日志。这个判断是定性的，跟踪方法很简单：盯自家日志里对这份文件的请求，它比任何行业新闻都诚实。

与相邻证据的合读

把 1.1% 放进整组数据，还能推出一个对策略排序有用的判断：AI 爬虫请求的大头来自训练型，检索型才是可见度的入场券——“日志里 AI 爬虫请求暴涨”不等于“AI 可见度在变好”，两个口径必须分开监测。本卡与量级卡、回流比卡构成一组互证：抓取很凶（合计约为 Googlebot 的 28%）、回流极悬殊（Anthropic 爬取回流比约 38000:1，口径见Anthropic 爬取回流比）、检索爬虫占比很小（1.1%）——站长面对的不是一种爬虫，而是一组动机与约定都不同的访客，治理必须分型展开。

最后给一个采购侧的提醒。如果服务商把 llms.txt 部署列为 GEO 项目的主要交付物，可以直接要求它回答：这个动作影响引擎决策的哪个环节？有什么日志证据表明文件被消费？答不上来的，交付价值就接近于零。证据分级里没有位置的东西，不该出现在报价单的核心项里。