批量检查robots.txt文件时,不要逐条打开每个URL再手工判断。更可靠的做法是把问题拆成“规则层”和“抓取层”:先从robots.txt里抽取所有Disallow、Allow和Sitemap行,按路径前缀分组;再从服务器日志或抓取统计中抽样,看被限制的路径是否真的出现了抓取请求、返回状态是什么。抽样定位的目标不是证明某条规则对错,而是用尽量少的样本判断问题集中在哪一类路径、哪一条规则,还是集中在某个目录的写法上。
robots.txt的规则按路径前缀匹配,所以抽样单位应当是路径段,不是完整URL。例如同一目录下有几千个商品页,它们通常受同一条Disallow行影响。先做三件事:
User-agent、Disallow、Allow、Sitemap四类。/search/、/tag/、/*?sort=、/api/。这样做的代价是前期要整理规则,但收益是后续抽样只需覆盖十来个分组,而不是几千个URL。适用条件是站点路径有较稳定的目录结构;如果URL参数杂乱、路径没有规律,分组会变粗,需要改用参数维度抽样。
批量问题往往集中在少数几种写法上。抽样定位时,先检查这些位置,命中概率更高:
Disallow: /*.pdf$这类规则容易误伤或漏伤。抽样时取一个本应允许的PDF和一个本应禁止的PDF,分别看是否被规则覆盖。User-agent下,更长的路径规则通常优先。抽样时找一对“短Disallow + 长Allow”的路径,确认实际生效的是哪条。/admin与/admin/覆盖面不同。抽样时各取一个带斜杠和不带斜杠的URL,观察是否都被限制。Disallow: /会覆盖全站。抽样时先确认是否存在这一行,再判断其他规则是否还有意义。需要区分“可能原因”和“已经定位的原因”。看到某条规则写了通配符,只能说明它可能是原因;只有用具体URL验证过规则匹配结果,才能说问题已经定位到这条规则。
规则写得对,不等于抓取行为符合预期。抽样时从服务器日志或抓取统计中取一小段,按路径分组统计请求数。判断逻辑如下:
Disallow,但日志中仍有大量请求:可能是规则未生效、爬虫未重新读取robots.txt,或该请求来自不遵守robots.txt的抓取方。Disallow,但日志中几乎没有请求:可能是内链不足、站点地图未包含,或该路径本身不存在。robots.txt不是唯一解释。这里要明确一点:robots.txt的抓取限制不等于可靠的索引移除。即使某URL被Disallow,它仍可能因为外部链接等原因出现在搜索结果中。抽样定位时如果目标是“让页面从搜索结果消失”,应改用其他移除手段,而不是只改robots.txt。
批量问题最容易返工的地方是结论没有落到具体规则和具体样本上。交付时建议包含四项:
这样交付的代价是需要多花时间整理样本,但可以减少“改了规则后不知道有没有改对”的返工。适用条件是团队中有多人分别负责规则修改、日志分析和结果复核。
如果现在就要开始,先选三类路径:一类被Disallow的目录、一类被Allow放行的子路径、一类带参数的动态URL。对每类各取一个URL,分别核对规则匹配结果和最近抓取记录。三类结果一致,说明批量规则与抓取行为基本对齐;出现不一致,就把不一致的那一类作为下一轮扩大抽样的重点。站点地图不保证收录,HTTPS也不保证安全或排名,抽样结论只应覆盖robots.txt规则与抓取行为之间的关系。