给站点做 AI 爬虫治理，真正需要定下来的是三件事：谁能拿到内容、拿去干什么、以及你怎么验证对方真的是它自称的那个爬虫。llms.txt 一件都不解决——它是 2024 年 9 月 3 日由 Jeremy Howard 在 llmstxt.org 提出的内容分发约定，至今不是任何标准组织的产物。Ahrefs 2026 年 6 月 15 日基于 137,210 个域名日志的研究显示，97% 的 llms.txt 文件在 2026 年 5 月收到过零次请求。真正决定爬虫能不能进来的是 robots.txt（RFC 9309，2022 年 9 月，Standards Track）、你 CDN 上那个正在变化的默认值、以及网络层的实际拦截规则。这篇把各自的边界和会咬人的地方讲清楚。
llms.txt 的规格，和它实际被谁读
规格本身很小。llmstxt.org 描述的结构是：一个 H1 标题（唯一必需的部分）、一段 blockquote 摘要、若干非标题的 Markdown 段落，然后是若干由 H2 分隔的链接清单。其中 ## Optional 一节有特殊语义——当消费方上下文预算不够时，这一节里的 URL 可以整段跳过。文件是 Markdown，放在域名根目录。
先澄清一件事：网上有大量 2026 年的文章声称 W3C 在当年 6 月发布了 llms.txt 的标准化工作草案，还给出了「版本头行」「禁止子路径变体」这类具体条款。我在 w3.org 的 TR 索引里检索不到任何对应条目。这条不要引用，也不要按它去改文件格式。 截至撰稿时，llms.txt 没有 RFC，没有 W3C TR，没有任何标准组织背书。
日志数据说了什么
Ahrefs 的研究方法是：对 137,210 个域名探测根路径，确认返回 HTTP 200 且内容确为 Markdown（而不是被 SPA 兜底成 HTML），再回看这些路径上的全部请求。38,360 个域名（28%）提供了有效文件——注意样本偏向使用 Ahrefs 分析工具的站点，这个采纳率不能外推到整个 web。
2026 年 5 月，其中 97% 零请求。收到请求的那 3% 里，96% 来自 bot，构成是：SEO 审计工具 21.7%、无法识别 14.9%、通用爬虫 13.1%、技术画像工具 11.6%，以及围绕 llms.txt 这件事本身的行业方合计 12.1%（GEO/AEO 工具 5.8%、llms.txt 探测 bot 3.6%、研究型 bot 2.7%）。AI bot 合计 19.5%，拆开是 agent 10.5%、训练爬虫 5.3%、助手 2.5%、检索型 bot（也就是真正生成 AI 答案的那一类）1.1%。
最有信息量的是另一条：在没有 llms.txt 的域名上，AI bot 从来没有去探测过这个路径。 它们不会主动找。这意味着「先放着，万一以后有人读」这个假设不成立——没有任何一方在建立「这个站有没有 llms.txt」的先验。
厂商的实际立场
Google 的 AI features 文档（末次更新 2025-12-10）写得没有余地：「You don't need to create new machine readable files, AI text files, or markup to appear in these features.」同一页把 robots.txt 对 Googlebot 的指令定为站点方管理抓取的控制手段，把 Google-Extended 定为 Gemini 训练与 grounding 的退出开关，并推荐用 nosnippet / data-nosnippet / max-snippet / noindex 限制展示。整套控制面里没有 llms.txt 的位置。
这里有个容易被误读的现象：OpenAI 自己的开发者文档站提供 /llms.txt，并支持在 URL 后加 .md 取 Markdown 版本。但那是 OpenAI 作为发布方在给编码工具供料，不是 OpenAI 的爬虫作为消费方在读别人的 llms.txt。Anthropic 的爬虫说明页则完全没有提到 llms.txt。不要把某公司自己发布 llms.txt，当成其爬虫会读你的 llms.txt 的证据——这是目前流传最广的推理错误。
那什么时候该做
只有一个站得住的场景：你的读者是编码 agent。 文档站给 Cursor、Claude Code、Cline 这类工具一个干净的入口，让它们不必去解析你的导航壳、cookie 横幅和侧边栏。这个用途是真实的，也是上面数据里 agent 类占比 10.5% 的来源。
但要把重点放对：真正被消费的不是那个索引文件，是每个页面的 .md 孪生体。索引只是让工具知道去哪儿取。如果你只能做一件事，做 .md。
另外两点：从 sitemap 自动生成的 llms.txt 没有价值，因为规格的全部价值在人工筛选——把整站链接倒进去等于没做。以及 llms-full.txt 并不在 2024 年那份提案里，它是文档平台的下游约定，别当规范要求。
robots.txt：真正会咬人的地方
RFC 9309 是 Standards Track，2022 年 9 月发布。四个在生产环境反复出事的点：
1. 5xx 等于完全禁止抓取。 规范要求爬虫在 500–599 响应下 MUST assume complete disallow。robots.txt 由应用框架动态渲染的站点，一次部署事故就等于全站对所有合规爬虫消失。而缓存策略是 SHOULD NOT 超过 24 小时，所以你修好之后恢复也不是立刻的。规范给了 30 天后可降级处理的余地，但那个时间尺度对线上业务没有意义。
结论：robots.txt 必须静态托管，且要单独监控它的状态码，不能只监控首页。这条是本文里最容易换来真实损失的一条。
2. 4xx 等于完全允许。 400–499 下爬虫 MAY access any resources。404 不是「保守拒绝」，是放行。把 robots.txt 删掉不等于收紧。
3. 最长匹配胜出，不是先匹配胜出。 规范说最具体的匹配必须被采用，具体性按 octet 数算。很多人沿用旧解析器的「顺序优先」直觉写规则，结果 Allow 和 Disallow 的实际生效关系和预期相反。
4. 解析上限至少 500 KiB。 「至少」意味着爬虫可以只读前 500 KiB。自动生成的巨型 robots.txt 会被静默截断，后半段规则形同虚设。
还有一个不在 RFC 里的坑：错误页返回 200 + HTML 的站点，robots.txt 请求失败时会被解析成一堆无效行——效果等价于全放行，而且监控上完全看不出来（状态码是 200）。
按用途分段，不要按厂商分段
主流爬虫早就按用途拆开了 user-agent：
- OpenAI：
GPTBot（基础模型训练）、OAI-SearchBot（ChatGPT 搜索索引）、ChatGPT-User（用户触发的取回）、OAI-AdsBot（广告页安全校验，明确不用于训练）。IP 段分别发布在openai.com/gptbot.json等端点。 - Anthropic：
ClaudeBot（训练）、Claude-SearchBot（提升搜索结果质量）、Claude-User（用户提问时触发）。IP 列表在claude.com/crawling/bots.json，文档说明遵守 robots.txt 并支持Crawl-delay扩展。 - Google：
Googlebot与Google-Extended分离，后者只影响 Gemini 的训练与 grounding，不影响 Search 排名。
关键区分：ChatGPT-User 和 Claude-User 是用户触发的取回，不是爬虫。 OpenAI 文档直接写明 robots.txt 未必适用于 ChatGPT-User。屏蔽这一类，约等于屏蔽一个把你的链接粘进对话框的真人——你损失的是流量，换来的什么也不是。
同理，想在 AI 答案里被引用，就不能拦 OAI-SearchBot 和 Claude-SearchBot。典型策略是：放行 search 类与 user-triggered 类，拒绝 training 类。
User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
Content-Signal：便宜，值得加，但不是执行
Cloudflare 在 2025 年 9 月 24 日提出 Content Signals Policy，在 robots.txt 里加一行声明内容被取走之后可以被怎么用。三个信号：search（建索引、返回链接与短摘要）、ai-input（把内容实时喂给模型，即 RAG、grounding、生成式答案）、ai-train（训练或微调）。取值是逗号分隔的 yes/no。它是 user-agent 组内的指令——作用域限于它所在的那个组，所以 Cloudflare 的示例把它放在 User-Agent: * 里，上面那段配置也是这么写的。
没有全局默认值。 策略原文写明：站点方没写某个信号，就既不授权也不限制该用途。这一点和「不写等于拒绝」的直觉相反，也是它和 robots.txt 语义上最大的差别。
它相对 robots.txt 的真正增量是法律语义，不是技术强制：Cloudflare 把这些信号定位为「express reservations of rights under Article 4 of the European Union Directive 2019/790」，也就是欧盟 DSM 指令下的文本与数据挖掘保留声明。加上它的成本几乎为零——RFC 9309 的合规解析器会忽略这行未知指令，不会破坏既有规则。
但 Cloudflare 自己在同一篇里说清楚了：这是偏好表达，爬虫可以无视，要配合 WAF 规则和 Bot Management 才有强制力。把它当声明用，别当开关用。
你的 CDN 默认值正在你脚下改变
这是本文里唯一会在你不做任何事的情况下改变你线上行为的部分。
Cloudflare 从 2025 年 7 月 1 日起对新接入域名默认拦截 AI 爬虫，同日推出 pay per crawl 私有测试。机制值得一看：HTTP 402 Payment Required，配 crawler-price、crawler-exact-price、crawler-max-price 三个头协商价格，成交后在 200 响应上回 crawler-charged。爬虫身份靠 Web Bot Auth 的 HTTP 消息签名认证，请求需带 signature-agent、signature-input、signature。
2026 年 7 月 1 日的更新把流量按用途分成 Search、Agent、Training，以及 Transact、Data Collection、SEO、Ads Verification 等类别。从 2026 年 9 月 15 日起，所有新接入 Cloudflare 的域名默认：投放广告的页面上 Training 与 Agent 被拦截，Search 保持放行。 存量客户可以在该日期前从 Security 设置里退出这个默认。
必须知道的一条规则：混合用途爬虫按其全部行为判定 —— 一个既做 Search 又做 Training 的爬虫，在你关掉 Training 时会被整体拦截。Cloudflare 直接用 Googlebot 举了例子。也就是说，一个界面上看起来只是「不给训练」的开关，可能把你的自然搜索流量一起关掉。上线前先用 dry-run 或日志模式跑一段，确认被命中的 UA 清单，再切实际拦截。
同日 Cloudflare 还提出 Pay Per Use，理由是按抓取次数计价太粗——他们给的数字是「good bot 抓取流量里超过 50% 在重复取回没有变化的页面」（这部分本来就该被条件请求消掉，见API 的 ETag 与条件请求）。一次抓取可能被引用上千次，也可能一次都没被用。方向包括 Ceramic.ai 的 pay-per-query 和 You.com 的 pay-on-demand。这块还早，别写进架构假设。
标准侧：可以跟踪，不要建在上面
IETF 有两个相关工作组，都还没产出 RFC。
AIPREF（AI 偏好）：draft-ietf-aipref-vocab-06 发布于 2026 年 4 月 28 日，是 Active Internet-Draft，intended status 为 Proposed Standard，2026 年 10 月 30 日到期。它不是 RFC。 词汇表刻意做得很小，-06 文本里的使用类别是 train-ai（用于生成式模型的生产或微调）与 search（以选取资产并把用户导向其位置为主要目的的应用），取值为 allow（y）/ disallow（n），没写就是 unknown，而且规范明确不对 unknown 该取什么默认值表态。
更值得注意的是另一半：draft-ietf-aipref-attach-04 停在 2025 年 10 月 28 日，状态是已过期。这份才是定义「怎么把偏好挂到 HTTP 与 robots.txt 上」并会 update RFC 9309 的那一半。
所以现状是：词汇表在推进，挂载机制过期了。 你现在没有一个 IETF 共识的方式去表达 AIPREF 偏好（草案过期、厂商各写各的，Idempotency-Key 实现指南里是一模一样的局面）。这也解释了为什么 Content-Signal 这类厂商方案还会存在相当一段时间——标准侧留了一个洞，厂商去填了。
Web Bot Auth（webbotauth）：工作组已成立，datatracker 上有 10 份活跃 Internet-Draft、零 RFC，而且这 10 份全部还是个人提交——一份 draft-ietf-webbotauth-* 的工作组采纳文档都还没有。其中「HTTP Message Signatures for automated traffic」（draft-meunier-webbotauth-httpsig-protocol）在 2026 年 8 月 6 日更新到 -01。核心是拿 RFC 9421（HTTP Message Signatures，2024 年 2 月，Standards Track）做爬虫身份：运营方生成 Ed25519 密钥对，公钥以 JWKS 形式发布在自己控制的域名的 /.well-known/http-message-signatures-directory，然后逐请求签名（服务端怎么验这类签名、怎么卡重放窗口，见Webhook 签名验证与重放防护）。
为什么身份比声明更重要
2025 年 8 月 4 日，Cloudflare 指控 Perplexity 用未声明的爬虫绕过 no-crawl 指令：在声明爬虫被拦后切换成伪装 Chrome 的通用 UA，走无关 ASN 的 IP，日均 300–600 万请求覆盖数万域名。Cloudflare 随后将其移出 Verified Bots 计划。
这件事真正说明的不是「某家公司不守规矩」，而是：基于 User-Agent 字符串的治理在结构上就没有强制力。 UA 是自称，自称可以随时改。robots.txt 和 Content-Signal 都是声明层——它们的价值在于表达意图和保留法律权利，而不在于阻止。只有网络层拦截加上加密身份才构成执行。Web Bot Auth 的意义就在这里：它第一次让「这真的是 GPTBot」变成可验证的事实，而不是一个可以伪造的字符串。
在它落地之前，可用的最强手段是用已发布的 IP 段做验证：openai.com/gptbot.json、claude.com/crawling/bots.json 这类端点给了你一个可核对的事实来源。UA 匹配上但 IP 不在段内，就是冒充。
落地清单
- robots.txt 静态托管，独立监控状态码。 5xx 是全站级事故，不是配置问题。顺便确认你的错误页不会用 200 兜底。
- 按用途分段：拦 training 类，放行 search 类和 user-triggered 类。别按公司名一刀切。
- 加 Content-Signal，成本近零，当作 DSM 指令下的权利保留声明用，不要指望它拦住任何东西。
- 检查 CDN 上 2026-09-15 的默认变更，重点确认混合用途爬虫规则不会连带影响 Googlebot；先 dry-run 再切。
- 要强制就上网络层：WAF 规则 + 官方 IP 段校验，不信任 UA。
- llms.txt 只在一种情况下做：你的文档站服务编码 agent。重点做每页的
.md版本，索引文件次之。不要为「AI 可见性」做——数据不支持，Google 明确说不读，这条路真正有效的做法见GEO/AEO 实战指南。 - AIPREF 只跟踪。词汇表还是草案，挂载机制已过期，现在没有可落地的东西。
