robots.txt 是抓取入口的第一道闸门，也是最容易被忽略的一道。它写得越复杂，越容易出现“以为放行、实际被拦”的情况。这类问题通常不报错，只在抓取日志里表现为某个目录的请求量悄悄归零。下面梳理通配符与 Allow/Disallow 优先级导致的高频误配，以及可以逐条执行的核对顺序。

先弄清匹配优先级

以 Google 公开的说明为参考，主流实现按“最长匹配优先”处理：某条规则中与 URL 路径重叠的部分越长、越具体，就优先于更短的规则；当 Allow 与 Disallow 的匹配长度完全相同时，Allow 一般获胜。

需要注意的是，这是 Google 的规则，其他搜索引擎爬虫的实现不一定完全一致；而且只有在长度相同时才去比较 Allow 与 Disallow，长度不同时一律以更长的那条为准。很多误屏蔽就出在“目录级 Disallow 一定能盖住子目录”这种直觉判断上。

高频误配形态

目录规则被更长的规则反超

• Disallow: /search/
• Allow: /search/help/

第二条更长，因此 /search/help/ 下的页面会被放行。如果本意是整目录屏蔽，这种写法就漏了一条口子。反向的例子更常见：本意只想放行某个静态资源，结果写了一条更长的 Disallow，把整个栏目一起关掉。

通配符位置不当

例如只拦带排序参数的 URL，写成 /*sort= 会把 /help/sorting-guide 这类正常路径一并拦掉。通配符越靠前，误伤范围越大，建议尽量贴着具体的参数名写。

结尾符 $ 的边界

/*.pdf 会拦掉路径中含 .pdf 的地址，而 /*.pdf$ 只拦严格以 .pdf 结尾的地址。对于带参数的 PDF 链接（形如 /a.pdf?v=2），加了 $ 反而拦不住。

规则堆积导致无法推断

当 robots.txt 累积到几十条上百条，人眼已经很难推出某条 URL 的最终结果。建议定期合并同类规则、删除已经失效的条目。

核对清单

1. 确认全站只有一份生效的 robots.txt，HTTP 与 HTTPS、带 www 与不带 www 的入口返回同一份内容，不存在内容不一致或兜底 404。
2. 检查 robots.txt 本身的响应状态：返回 404 通常表示全站放行，返回 5xx 则可能让部分爬虫暂时放慢甚至暂停抓取。
3. 把现有规则按路径长度排序，逐条自问：这条是想放行还是想屏蔽，实际结果是否一致。
4. 重点排查 Disallow 目录下是否存在更长的 Allow，以及 Allow 目录下是否存在更长的 Disallow。
5. 检查通配符与结尾符的组合，尤其是带参数 URL、静态资源目录和多语言路径。
6. 确认没有误把 Sitemap 地址、CSS/JS 目录、分页路径写进 Disallow，这些会连带影响渲染结果与入口发现。
7. 确认没有用 robots.txt 去解决本该靠登录墙或页面级指令处理的问题。

验证与观察

改完之后不要只靠肉眼读一遍。在搜索蜘蛛的抓取日志里，观察此前被拦目录的请求量是否回升；如果仍然只有零星请求，说明屏蔽规则还在生效，或者该目录本身就缺少内链入口，需要回到内链结构上找原因。

同时把 robots.txt 与 Sitemap 一起看：Sitemap 提交的 URL 若被 robots.txt 屏蔽，两者会互相打架，表面上提交量很大，实际抓取量却上不去。

robots.txt 只影响抓取，不决定收录。被 Disallow 的 URL 依然可能因为外部链接出现在结果页里，需要屏蔽展示时应改用页面级指令。

小结

把 robots.txt 当成一份需要评审的配置而不是随手写的文本：规则尽量少、尽量具体，改动后结合抓取日志做一次回看。抓取入口这件事，能少一层歧义就少一层。