📍 WDQWDWQD987AAAAA:216.73.217.22
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d4fa9aaa776e.html
📄

robots：出现异常时怎样确定影响范围

先做结论：确定 robots 异常影响范围，核心不是看 robots.txt 本身写了什么，而是把“规则覆盖的 URL 集合”与“实际抓取、收录、展示出现异常的 URL 集合”做交集。交集内的页面才是真正受影响的页面。判断顺序应当是：先确认异常现象属于抓取限制、索引移除还是展示变化，再按目录、参数、文件类型三个维度圈定规则覆盖范围，最后用日志和页面级检查验证。

先分清 robots 异常的三类现象

robots.txt 的抓取限制不等于可靠的索引移除。这是确定影响范围时最容易走偏的地方。需要先把现象归入下面三类之一，因为三类现象的影响范围判定方法不同。

• 抓取层面：爬虫不再请求某些 URL，日志中对应路径的请求量下降或归零。
• 索引层面：页面从搜索结果中消失，或长期不出现。注意这可能由抓取限制间接导致，也可能与 robots 无关。
• 展示层面：页面仍可被抓取，但摘要、缩略图或站点链接发生变化。

只有第一类能直接由 robots.txt 解释。第二类需要排除 noindex、 canonical、状态码、内容质量等因素后才能归因。第三类通常与 robots 无关。

按三个维度圈定规则覆盖的 URL 集合

打开 robots.txt，逐条读取 User-agent 与 Disallow、Allow 的组合。不要只读第一条规则，要按“最具体匹配优先”的原则逐条判断。然后从以下三个维度列出被覆盖的 URL：

1. 目录维度：例如 Disallow: /search/ 覆盖该目录下所有路径，包括子目录。
2. 参数维度：例如 Disallow: /*?sort= 覆盖所有带 sort 参数的 URL，可能横跨多个目录。
3. 文件类型维度：例如 Disallow: /*.pdf$ 覆盖全站 PDF 文件。

把这三个维度得到的 URL 集合合并，就是规则理论上覆盖的范围。这一步只回答“哪些 URL 被规则挡住”，不回答“哪些 URL 真的出了问题”。

用日志和页面检查验证真实影响

理论覆盖范围往往大于真实影响范围，因为部分 URL 本来就没有被抓取需求，或已被其他方式处理。验证时执行以下步骤：

1. 从服务器日志中筛出目标爬虫的请求记录，按状态码分组。被 robots 挡住的请求通常返回 200 但内容为空，或直接不出现。
2. 取规则覆盖范围内的 URL 样本，逐个用抓取测试工具检查。不同搜索引擎的抓取测试工具支持情况须分别核查，不能用一个工具的结果推断所有引擎。
3. 对比规则生效前后的日志请求量。如果某目录请求量下降但未归零，说明影响是部分的，可能只有部分 URL 匹配规则。
4. 检查站点地图中是否仍包含被挡 URL。站点地图不保证收录，但被挡 URL 留在站点地图中会造成信号冲突，可作为排查线索。

验收信号是：规则覆盖范围内、且日志中确实不再被请求的 URL 数量，与业务上真正关心的 URL 数量一致。如果前者远大于后者，说明规则写得过宽；如果前者小于后者，说明还有未发现的规则或缓存版本在起作用。

一个可执行的判断例子

假设某站点发现产品页从搜索结果中消失，robots.txt 中有一条 Disallow: /product/。按上述方法：

• 目录维度覆盖所有 /product/ 开头的 URL，包括产品列表和详情页。
• 日志显示该目录请求量下降但未归零，说明部分爬虫仍访问，可能因为规则是后来添加的，或存在多个 User-agent 分组。
• 进一步检查发现，消失的页面全部位于 /product/detail/ 子目录，而列表页仍在搜索结果中。影响范围可缩小到该子目录。

这个例子中，robots 规则覆盖了全部产品路径，但实际影响范围只是详情页子目录。如果不做日志验证，容易误判为全站产品页受影响，导致修复动作过大。

确认影响范围后的下一步

确定范围后，先不要急着删除整条规则。按影响范围最小的方式修改：如果只有某个子目录受影响，把 Disallow 收窄到该子目录；如果只有带参数的 URL 受影响，把规则限定到参数模式。修改后重新抓取受影响 URL 样本，观察日志中对应路径的请求是否恢复。恢复抓取不等于恢复收录，收录还需要页面本身可索引且内容合格，这两步要分开验证。