老的排除协议里没有 Allow 字段，白名单式放行怎么表达

想只对某类爬虫放行，在爬虫排除协议的原始文档里确实找不到对应字段——该文档明确说明协议没有 Allow 字段，只提供排除式指令。这不是遗漏，而是协议设计取向：它诞生时解决的问题是「告诉抓取方不要取哪些路径」，正向允许是后来各抓取方在自己的实现里补上的扩展。所以白名单式放行要靠表达方式绕出来，而不能指望协议给出一个允许清单。

原始文档只有排除式指令

原始文档定义的记录结构是：一组记录指明适用于哪些爬虫，随后逐条给出排除的路径前缀，组与组之间用空行分隔。指令名只有排除向的那一个，文档里对这一点写得很直白：目前没有 Allow 字段。

这意味着「默认全部可取，只放行某几个目录」这种白名单思路，在协议层面无法直接写出。能写的只有反过来的东西：默认可以取，某些前缀别取。

星号在字段里只表示任意爬虫

一个常见误解是把爬虫名里的星号当成通配符。原文的定义是：爬虫名取值为星号，表示这组记录适用于所有爬虫。它是集合的含义，不是模式匹配的含义。

同一份文档还专门说明，爬虫名与路径排除行都不支持通配与正则表达式。也就是说，指望用模式写法表达「除这几个前缀外全部禁止」，在原始协议里不成立。路径匹配按前缀处理，这也是为什么实操里要把前缀写完整，而不是写半截目录名。

扩展规则由谁定义

现实中常见的 Allow 行、路径里的星号通配、结尾的美元符号等写法，来自各抓取方自己的实现，而不是协议规定。这带来两个后果：同一段配置在不同爬虫上的解析结果可能不同；匹配优先级与冲突处理也要按对应爬虫的说明来判断。

处理方式因此要分成两层：写配置时以协议里的排除式指令为基础，确保任何实现都能读懂；需要更细的匹配时，去查具体抓取方公开的说明，并把扩展写法当作「锦上添花」，而不是「生效前提」。

实操上的三种表达

一是反向排除。把后台目录、内部接口、参数化地址、草稿预览地址这类不该被抓取的前缀逐个列出，其余不写。这是在原始协议下表达「只公开内容路径」的方式，也是维护成本可控的一种。

二是按爬虫分组。给需要精细控制的抓取方单独一组记录，其余爬虫归到星号组，通过分配不同的排除清单实现松紧差异，而不是试图写一个允许清单。

三是把判断交给服务端。真正敏感的地址不应只靠配置文本来保护，而要靠访问控制。内容管理系统在站内侧可以提供两类支持：一是把配置文件纳入后台管理，AnQiCMS 支持在后台配置 robots.txt，改动随站点设置一起维护，避免手工上传遗漏；二是用伪静态规则统一地址形态，让「哪些前缀属于内部地址」这件事有稳定的判断依据，AnQiCMS 的伪静态规则管理支持自定义地址规则，排除清单因此更好写。

顺序上还要注意：不要依赖多行之间的先后关系来抵消彼此，协议没有规定这种覆盖逻辑，能靠写清前缀解决的，就不要留给解析方去猜。

常见问题

写了 Allow 行会不会有害？ 支持它的抓取方会按扩展语义处理，不支持的会直接忽略该行。风险在于把 Allow 当成生效前提，一旦对方不识别，实际的放行范围与预期不一致。

路径前缀要写到多细？ 写到能区分公开与内部的最小完整前缀。半截目录名容易连带匹配到公开路径，这类问题在按前缀匹配的规则下尤其常见。

多站点共用一套后台时怎么处理？ 按站点分别给出配置文件，逐站列出各自的内部前缀，不要让不同地址形态共用一份清单。

改完怎么验证？ 用抓取方的站点诊断工具看解析结果，同时抓一份实际响应确认文件内容与预期一致，两处一致才算生效。