检查 robots.txt 之前,至少要准备四类信息:检查目标、当前文件内容、站点结构与关键路径清单、以及修改与验收方式。目标决定你判断什么算“对”,当前内容决定你从哪里改,路径清单决定你能否发现误屏蔽,验收方式决定改完以后怎么确认没有把该抓的页面挡在门外。缺少任何一项,检查都容易变成只看语法、不看后果。
robots.txt 是给爬虫看的抓取规则,不是让页面从搜索结果中消失的可靠手段。如果目标是“不让搜索引擎抓取某个目录”,robots.txt 可能适用;如果目标是“让已经收录的页面尽快消失”,单靠 robots.txt 往往不够,甚至可能因为页面无法被抓取而影响后续处理。检查前先写下目标属于哪一类:
目标不同,准备的信息也不同。若目标是恢复收录,还需要准备被屏蔽 URL 的清单和这些 URL 当前的 HTTP 状态;若目标是限制抓取,则需要准备允许抓取的路径白名单,而不是只列禁止项。
检查前把当前 robots.txt 原样保存下来,包括所有注释和空行。不要只看后台编辑器里的显示结果,要以实际返回的文本为准。需要记录的信息包括:
User-agent 分组下有哪些 Allow 和 Disallow 规则。Sitemap 声明,声明地址是否可访问。如果站点有版本控制或发布记录,找出最近一次修改时间和修改人。没有历史版本时,至少保存一份当前副本,并记录保存时间。这样修改后可以对比,判断问题是不是由本次改动引入。
只有规则、没有路径清单,就无法判断某条 Disallow 是否误伤。检查前准备一份关键路径表,至少包含:
同时准备近期的爬虫访问日志。日志能帮助判断某条规则是否真的影响了抓取:如果日志中某类爬虫对某目录的请求量在规则生效后明显减少,可能是规则在起作用;如果请求量没有变化,则要检查规则是否被正确解析、爬虫是否支持该语法。这里要区分“可能原因”和“已经定位的原因”:日志减少可能是规则导致,也可能是站点结构变化、爬虫预算调整或服务器响应异常,不能只看一个现象就下结论。
检查 robots.txt 往往需要改文件。改之前要确认:谁有权限修改,修改后通过什么方式发布,发布后多久生效,出错时怎么回滚。需要准备的信息包括:
如果 robots.txt 由应用动态生成,还要准备生成逻辑的代码位置和测试环境。动态生成时,一次代码发布可能影响所有规则,回滚也要对应到代码版本,而不是只恢复一个静态文件。
修改或检查完成后,用同一份路径清单逐项验证。可以按下面的顺序执行:
User-agent 分组分别测试关键 URL,判断规则是否按预期匹配。noindex 或其它方式,而不是只依赖 robots.txt。判断结果时注意适用条件:不同搜索引擎对通配符、Allow 优先级和 Sitemap 声明的支持情况可能不同,需要分别核查。HTTPS 只说明传输加密,不代表站点没有漏洞,也不保证排名。站点地图提交不保证收录。把这几件事分开,验收标准才不会跑偏。
下一步,把上面提到的当前文件副本、关键路径清单和回滚步骤放在同一个位置,先完成一次只读检查:不改任何规则,只记录现状和疑点。确认疑点对应的目标后,再决定是否修改。