robots.txt（AI 语境） robots.txt for AI

robots.txt 是站长控制爬虫抓取的通行协议：放在域名根路径的纯文本文件，按 User-agent 分组声明哪些路径允许抓取、哪些禁止。AI 语境下它的角色扩展了——从“管搜索引擎”变成“分用途管 AI”：训练爬虫、检索爬虫、用户触发爬虫各自通向不同的产品入口，放行与禁止因此从一个问题变成一组问题。而协议本身没有强制力，遵守与否取决于各家政策。

它从来不是一个强制标准，而是一份行业公约：诞生于搜索引擎早期的善意约定，靠爬虫方自愿遵守运转多年。AI 爬虫兴起后，这份公约被推到新位置——出版方用它表达训练授权立场，站长用它分配 AI 生态的入场资格。工具没变，语义变厚了：同一份文件里，现在同时写着“给搜索的”与“给 AI 的”两组意图。

对从搜索时代过来的站长，最大的观念更新不是语法，而是对象：过去文件里写的是“给搜索的许可”，现在还要写“给训练的授权”与“给检索的门票”——三个用途、三组对象、三种立场，装在同一份文件里。

三条容易踩坑的语义铁律

第一，组间不继承。User-agent: GPTBot 组只看自己组内的规则，不继承 User-agent: * 组的任何 Disallow——想让一条禁令对全部爬虫生效，必须每个组都写一遍。这是最高频的配置事故：站长在通用组里加了禁令便以为万事大吉，具名爬虫其实一路畅通。

第二，UA 匹配大小写不敏感，GPTBot 与 gptbot 是同一个对象；但组名之外，路径写法与控制型 token 的名称要按各家文档精确书写，错一个字符整组规则就可能落空。

还有一条容易误会的规则：同一组内，当多条规则都能匹配同一路径时，以最具体（路径最长）的那条为准，而不是写在后面的赢。把通用 Web 服务器的“顺序优先”心智带进 robots，是配置错误的另一个高发来源。通配符与行尾匹配的写法各家支持程度不一，简单、显式、逐路径书写，永远比炫技的组合规则可靠。

第三，遵守是自愿的。robots.txt 是君子协定：训练与检索爬虫主流均声明遵守；用户触发型（ChatGPT-User 等）默认无视——用户让它去读哪个页面，它就去读，协议拦不住。三型爬虫的行为差异见爬虫三型术语卡。所以“robots 全禁等于不出现在 AI”是错觉：全禁只是退出索引与训练语料，拦不住用户触发抓取。

把高频事故汇成清单：在通配组写了禁令便以为对具名爬虫生效；组名拼写与官方 token 不一致，整组规则空挂；测试环境改完忘了同步生产；CDN 或 WAF 层另有爬虫规则，与 robots 语义打架却没人对账；以及最隐蔽的一种——文件本身放错路径或返回了错误状态码，爬虫按“无限制”处理。逐条对过，胜过任何理论上的精通。

按用途做三态决策，而不是一刀切

我们建议的决策框架是三态：全允许；允许检索、禁止训练；全禁。三态对应三种诉求——全面参与 AI 生态、只要 AI 搜索可见度而不贡献训练语料、彻底退出。逐组的配置矩阵见技术规范栏（P2 上线）。

三态没有普适答案，只有立场差异。媒体与专业出版方最常选“允许检索、禁止训练”——内容进了答案就保住了流量与署名，训练语料的贡献则留作谈判筹码。工具站与电商多数选全允许——AI 渠道的引流价值大于语料顾虑。选择“全禁”的通常是内容本身即产品（数据库、研究报告）的站点，且要接受随之而来的 AI 可见度归零。先想清楚自己属于哪一类，再动文件。

三态之外其实还有第四种操作：分目录取舍。整站一刀切经常过于粗暴——公开知识内容放行、付费报告目录禁训练、内部目录全禁，同一域名内按目录写不同立场，才是多数内容站的真实需求。robots 的分组机制天然支持这种写法，别浪费它。

选“全禁”的站长还要面对执行现实：具名组逐个列名是列不完的——新爬虫不断出现，通配组的全禁对遵守者有效、对无视者无效，而用户触发型一律拦不住。全禁因此更像一份立场声明而非技术屏障；把它当声明写，心态就对了，把它当防火墙用，失望是必然的。

教科书式的分层案例是Google-Extended：它是 robots.txt 里的控制型 token，只管 Gemini 训练与 grounding 用数，屏蔽它不影响 Google 搜索收录与 AI Overviews 出现——想保留搜索可见度、又不贡献训练语料，屏蔽它即可。反过来，OAI-SearchBot 这类检索爬虫是各自引擎引用池的入口，屏蔽即放弃对应的 AI 搜索可见度。每个 token 动笔前先问一句：它管的是哪一环。

还要破除一个期待：robots 只是许可，不是邀请。放行一只爬虫，不等于它会优先抓你、多抓你、快收录你——抓取预算、站点质量、链路可达性都排在许可之后起作用。把 robots 当成可见度开关，是把它高估了；把它当成入场券发放处，才是它的本分。

robots 也是一份会过期的文件。AI 爬虫的名单在扩，控制型 token 在增，各家的遵守口径也在调整——定期把文件对着各家官方文档过一遍，比对日志里出现的新 UA，是维持配置有效的最低维护量。见过太多站点的 robots 停在配置当时的心智：写的时候很认真，此后再没看过，直到某天发现新爬虫早已在通配组下自由通行。

一个最小可用的分层示例：

User-agent: GPTBot
Disallow: /private/

User-agent: OAI-SearchBot
Disallow:

User-agent: PerplexityBot
Disallow:

User-agent: *
Disallow: /private/

注意：* 组的禁令对上面三个具名组都不生效——想统一禁 /private/，四个组都要写。这正是铁律一在真实文件里的样子，也是“新加一条 Disallow 必须逐组补写”的原因。

robots 之外：验证、留痕与并行声明

写完 robots 不等于结束。验证层面，用日志确认各爬虫是否按声明行事：具名 UA 是否来自官方公示的 IP 段、被禁路径是否仍有请求。2025 年业界曾出现检索爬虫被指绕过屏蔽的风波（站内记录见PerplexityBot 术语卡），日志实证比厂商声明可靠。

验证有两条路：各引擎官方提供的 robots 测试工具，能模拟特定 UA 对特定路径的判定；以及你自己的日志——工具告诉你“规则应该怎么被解释”，日志告诉你“爬虫实际怎么做”。前者查语法，后者查行为，两个都对上，配置才算落地。

多语言或多区域站点还有一层管理成本：robots 常按域名或子路径分文件部署，AI 爬虫的名单与立场在每份文件里都要重复维护——漏一份，那部分站点就在计划外裸奔。配置管理的颗粒度要跟站点结构对齐，这是多站点团队最容易失守的地方。

留痕层面，AIPREF 草案提供了比“全允许/全禁止”更细粒度的 Content-Usage 声明，可逐项表达训练、AI 输出、搜索的偏好（见AIPREF 术语卡）；它与 robots 分组并行使用，作为善意表态与法务留痕，但别指望单靠它执行。另有 llms.txt 一类面向 AI 的站点说明文件，实测对被引用无效，定位是顺手棋而非控制手段（见llms.txt 术语卡）。

给本站用户的口径：robots 是入场券的发放处，不是保险箱。把票发对——逐组、分用途、可验证；再把内容侧做扎实——两件事缺一不可。

最后补一句法务视角：robots 的表态在一些讨论中已被当作授权痕迹对待——你写下的每一组允许与禁止，都是立场的书面记录。写之前想清楚立场，写之后保持一致，这份文件才有公信力；朝令夕改的 robots，对爬虫方与对法院一样难以取信。