识别 robots.txt 配置冲突,核心是找出“同一路径在不同规则下得到相反结论”的地方。最直接的方法是:把每条规则按 User-agent 分组列出,对每个需要判断的 URL 逐一比对,看它是否同时被 Allow 和 Disallow 覆盖、是否被更长或更短的前缀命中、是否落在不同分组的适用范围里。只要同一 URL 在不同分组或同一分组内得到“可抓”和“不可抓”两种结果,就属于冲突,需要人工裁定。
robots.txt 的冲突大致分三类,处理方式不同:
* 分组给出相反结论。具体分组优先,但写错分组名会导致预期落空。多人协作时,先把冲突归类,再决定谁改、改哪一层,能减少反复返工。
要查什么:User-agent 行的拼写、大小写、是否存在空行分隔错误。
怎么查:逐行阅读文件,确认每个 User-agent 行下面是同组的规则,组与组之间有空行;把爬虫名与目标搜索引擎官方文档中的名称对照。
结果说明什么:如果爬虫名拼错,该分组不会被对应爬虫采用,规则会回落到 * 分组,形成“以为限制了、实际没限制”的冲突。
要查什么:对每个关键目录,列出所有可能命中它的规则。
怎么查:取一个具体 URL,例如 https://example.com/shop/private/,在文件里找所有前缀能匹配它的规则。假设文件里同时有 Disallow: /shop/ 和 Allow: /shop/private/,两者都命中。
结果说明什么:当 Allow 与 Disallow 长度不同时,通常以更具体、前缀更长的规则为准,但这个判断依赖具体搜索引擎实现。出现这种写法就应视为需要人工确认的冲突点,而不是默认某个结果。
要查什么:* 和 $ 的使用位置。
怎么查:把带通配符的规则还原成它实际覆盖的路径集合。例如 Disallow: /*.pdf$ 只匹配以 .pdf 结尾的 URL,而 Disallow: /*.pdf 会匹配任何包含 .pdf 的路径。
结果说明什么:如果一条规则本意是限制某类文件,却因为漏写 $ 覆盖了更多路径,就会和其他 Allow 规则冲突。不同搜索引擎对通配符的支持程度需要分别核查。
要查什么:robots.txt 允许抓取的页面,是否带有 noindex;robots.txt 禁止抓取的页面,是否又指望通过 noindex 移除。 怎么查:抽取一批 URL,分别记录 robots.txt 的判断结果和页面 head 中的 meta robots 值。 结果说明什么:robots.txt 的抓取限制不等于可靠的索引移除。如果页面被禁止抓取,爬虫可能看不到 noindex,页面仍可能以其他方式出现在结果中。这类冲突要靠统一策略解决,不能只改一处。
要查什么:测试环境、预发环境、生产环境的 robots.txt 是否内容不同,是否有人把测试规则带到了线上。
怎么查:分别请求各环境的 /robots.txt,逐行对比差异,重点看 Disallow 是否整站屏蔽。
结果说明什么:如果线上出现 Disallow: /,而站点地图和内链仍在正常输出,就是典型的环境配置冲突,会直接阻断抓取。
协作交付时,建议为每个争议 URL 建一行记录,字段包括:URL、命中的 User-agent 分组、命中的 Allow 规则、命中的 Disallow 规则、按最长前缀判断的预期结果、页面级 noindex 值、最终裁定。填写后由规则所有者和内容所有者共同确认。这样返工点会集中在“裁定”一列,而不是反复争论文件里哪行写错了。
需要提醒的是,站点地图不保证收录,HTTPS 也不保证安全无漏洞或排名提升,这些都不能用来反推 robots.txt 的配置是否正确。判断依据只能是规则本身和实际抓取表现。
选一个当前有争议的目录,按上面五项清单逐条填写对照表。填完后如果仍存在 Allow 与 Disallow 同时命中的行,就把该行单独拿出来,确认目标搜索引擎对最长前缀和通配符的处理方式,再决定保留哪条规则,并同步更新站点地图与页面级指令,避免只改 robots.txt 造成新的不一致。