为什么 robots.txt 值得单独排查
在抓取路径的链条里，robots.txt 是最靠前的一环。蜘蛛到达站点后，通常先取这份文件，再决定哪些路径可以继续请求。它不负责收录，也不保证抓取，但一旦规则写错，后面的 Sitemap、内链、目录结构再合理，也可能因为入口被挡住而失去被请求的机会。实际运营中，robots.txt 引发的误伤往往不是“整站被封”这么明显，而是某个栏目、某类参数页或某个子目录被悄悄排除，日志里表现为蜘蛛对该目录的请求量长期为零。
先确认问题是否真的出在 robots.txt
不要一看到抓取量下降就改规则。更稳妥的顺序是：先用服务器日志或抓取日志确认蜘蛛最近是否请求过 robots.txt，返回状态是否为 200；再确认被怀疑的目录是否曾经有抓取记录。如果该目录此前有稳定请求，某次改版或规则调整后归零，robots.txt 的嫌疑才比较大。如果蜘蛛根本没有取过这份文件，或者返回 404、403、5xx，那问题可能出在服务器可达性、WAF 或 DNS 环节，需要另开排查线。
日志里可以看的几个信号
- robots.txt 的请求频率和返回码是否稳定为 200。
- 被怀疑目录的抓取量是否在某个时间点之后突然归零。
- 同目录下部分 URL 仍被抓取，说明不是整段屏蔽，而是规则匹配范围过宽或过窄。
- 蜘蛛是否频繁请求被 Disallow 的路径但未继续深入，可能只是规则解析结果与预期不同。
常见误伤点与对应规则
通配符位置不当
robots.txt 只支持前缀匹配和有限通配符，其中 * 表示任意字符序列，$ 表示路径结束。写法稍不注意就会扩大范围，例如想屏蔽带排序参数的分页，却写成 Disallow: /*sort，可能把包含 sort 的正常栏目也一起挡住。更稳的做法是把通配符限制在参数段附近，并配合 Allow 放行必要路径。
Allow 与 Disallow 同时命中
当同一路径同时命中 Allow 和 Disallow 时，通常按最长匹配决定，长度相同时 Allow 优先。很多人以为“后面的规则覆盖前面的”，于是把 Allow 写在 Disallow 之后，却发现没有生效。排查时应把相互冲突的规则列出来，逐条比较匹配长度，而不是凭书写顺序判断。
User-agent 组别被空行拆开
多行 User-agent 连续书写时属于同一组，中间出现空行则分组结束。若把 User-agent: * 和针对某蜘蛛的规则混在一起，再插入空行，规则可能挂到错误的组上。尤其当站点同时声明多个蜘蛛名称时，建议每组之间留出清晰空行，并避免在组内随意插入注释以外的内容。
目录前缀与大小写
路径匹配区分大小写。Disallow: /Search 和 /search 在规则层面并不等价。另外，用目录名做前缀时容易误伤，例如 Disallow: /doc 会同时挡住 /document 和 /docs。如果只想屏蔽某个目录，写成 /doc/ 更稳妥。
Sitemap 指令的位置
Sitemap 是全局指令，不属于某个 User-agent 组。它放在文件任意位置通常都能被识别，但如果被夹在某个组中间，维护时容易被误读为只对该蜘蛛生效。为了减少交接成本，可以把 Sitemap 统一放在文件末尾，并保证地址可访问、返回 200 且为 XML 内容。
修正与验证的落地步骤
- 先备份当前 robots.txt，记录修改时间和修改人。
- 把冲突规则逐条列出，标注匹配路径、允许或禁止、命中长度。
- 用最小范围改写，尽量用目录结尾斜杠限定范围，避免裸前缀误伤。
- 修正后先在小范围验证，观察目标目录是否重新出现蜘蛛请求。
- 把 Sitemap 中真实可抓的 URL 与 robots.txt 允许范围做交叉核对，避免提交了却被规则挡住。
- 稳定一段时间后再评估是否需要继续收紧，不要一次改动过多变量。
robots.txt 不承诺收录，也不直接决定排名。它的作用是表达抓取意愿，真正发现 URL 仍然依赖内链、Sitemap 和服务器稳定性。
保持规则简洁可读
很多误伤来自“为了精确而堆叠大量通配符”。对中小站点来说，规则组越少、路径越明确，后续排查成本越低。建议给每个被屏蔽目录写一句原因注释，定期复核是否仍有必要。若某目录已经重新开放，就把对应 Disallow 及时删除，避免规则与站点结构长期脱节。抓取路径的恢复通常需要观察一段时间，期间可以结合日志中的状态码分布和入口请求量，判断蜘蛛是否重新走回了被误挡的目录。