抓取排除文件按路径前缀匹配，写成通配或正则为什么不生效

抓取排除文件写成通配或正则不生效，根本原因是这套协议从一开始就没打算表达「模式」，它只做一件事：按请求路径的前缀判断要不要排除。协议里只识别两个字段，匹配规则也简单到只有「路径是不是以某串开头」。理解这一点，才能解释为什么很多看起来合理的写法会被抓取方原样当成一条普通前缀。

协议里到底认哪两个字段

这套抓取排除标准只用两项指令：User-agent 和 Disallow。User-agent 声明规则针对哪个抓取方，Disallow 声明排除哪条路径前缀。它甚至没有 Allow 这个放行字段——早期版本里「明确放行某子路径」这种需求是表达不出来的，只能靠别的手段绕。

正因为字段就这两个，规则的表达力被限制得很死：一条 Disallow 后面跟的，就是被当作路径前缀的一串字符，不是模式串。

匹配为什么只按前缀

协议明确写着：globbing（通配）和正则表达式在 User-agent 与 Disallow 两行都不被支持。也就是说，抓取方拿你写的 Disallow 值，直接和请求 URL 的路径部分做前缀比较，从头对齐，对上了就排除，对不上就不排除。

通配和正则写法会发生什么

写通配或正则不但不报错，反而更危险——它「看起来生效了」其实没有。你以为 /*-page-\d+ 挡掉了所有分页地址，抓取方实际在找一个以斜杠、星号、-page-、反斜杠、d、加号这一串字面字符开头的路径，几乎永远匹配不到。结果是：你以为排除的路径照常被抓取。

同理，想靠 ? 通配查询参数、想靠 [] 匹配字符集，在这套只认前缀的规则里都不成立。协议本身也提醒：抓取方可以选择无视这份文件，所以它从来不是安全边界，只是给守规矩抓取方的意向声明。

站内该按什么顺序写规则

实操上按三步走。第一步，把需求翻译成「前缀」而不是「模式」：想排除一个目录就写目录路径并以斜杠结尾，想排除一类命名规范就找到它们共同的路径开头。第二步，每条被排除的目录单独占一行，规则块之间用空行分隔，不同 User-agent 分组各自成块。第三步，站内配合伪静态规则把可控的动态地址变成长度稳定、前缀清晰的路径，再去排除会更准——因为伪静态后筛选页、列表页变成了规整目录，前缀匹配才表达得出来。AnQiCMS 后台可直接配置 Robots.txt，也支持自定义伪静态规则，两处配合就能把「该挡的路径」用前缀语言表达清楚。

常见问题

问：那我到底能不能只挡带某个参数的页面？ 答：靠这份文件不行。它只按路径前缀匹配，查询参数在前缀规则里没法精确表达，要改用别的机制或在服务端处理。

问：写了正则没报错，是不是就生效了？ 答：不是。没报错只代表格式被接受，正则会被当成字面量前缀，实际匹配不到目标路径。要核对匹配结果而不是依赖语法通过。

问：挡了抓取文件，内容就不会被抓了吗？ 答：不会。协议本身承认抓取方可以无视这份声明，它是意向不是强制。真正要保护的内容要落在服务端权限与限频上。