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

seo工具：一次全站扫描被中断后怎样判断已覆盖范围，先确定用什么作为“应覆盖全集”

全站扫描被中断后，不能凭“已经跑了多久”或“抓了多少条”判断覆盖范围，而要把中断前留下的输出整理成一份可核对的已覆盖清单，再决定是续跑、重跑还是只补缺口。核心动作是：把扫描日志或导出结果按URL分组，和站点当前可发现URL集合做一次差集，差集之外的部分才算已覆盖。

先确定用什么作为“应覆盖全集”

判断覆盖范围，前提是先有一个参照集合。中断后的扫描结果本身不能当全集，否则会得出“已抓到的就是全部”的循环结论。可用的参照通常有三类：

• 站点地图文件里列出的URL，适合结构清晰、维护及时的站点；
• 从首页出发的内部链接爬取结果，适合目录层级不深、导航完整的站点；
• 服务器访问日志中近期被请求过的URL，适合有稳定抓取行为的站点。

这三类参照各有盲区：站点地图可能遗漏新页面，内链爬取可能进不去登录后或参数复杂的页面，访问日志只反映被请求过的部分。因此实际操作中建议至少取两类求并集，作为“应覆盖全集”的近似值，并明确记录这个近似值是怎么来的。

假设某站点地图列出1200个URL，内链爬取得到1350个URL，两者并集为1420个。中断时的扫描输出里有900条记录。这时不能直接说“覆盖了900/1420”，因为还要看这900条是否都落在并集内，以及是否有重复、重定向、错误页混在其中。

把中断输出清洗成可核对的URL清单

中断产生的原始输出往往混杂多种状态，直接计数会高估覆盖。需要先做几步清洗：

1. 去掉重复URL，同一地址因参数、大小写或末尾斜杠不同可能被记成多条；
2. 区分成功抓取、重定向、客户端错误、服务器错误，只有成功返回内容的才算真正覆盖；
3. 把重定向的最终落点归并到目标URL，避免把中间跳转当成独立覆盖；
4. 剔除明显不属于内容页的静态资源或接口地址，除非本次扫描目标本就包含它们。

清洗后得到的清单，才是可以拿去和参照集合做差集的“已覆盖清单”。这一步的结果会直接影响下一步：如果清洗后发现成功记录远少于原始条数，说明中断前的大量输出其实是错误或跳转，续跑的意义就大于补缺口。

用差集判断缺口性质，而不是只看缺口数量

把已覆盖清单和应覆盖全集做差集，得到未覆盖URL。但缺口数量本身不足以决定行动，还要看缺口的分布特征：

• 如果缺口集中在某个目录或某类模板页面，可能是扫描队列按顺序推进，中断点之后的整段都没跑到；
• 如果缺口零散分布在各目录，可能是部分URL被规则排除、超时或抓取失败，而非单纯中断导致；
• 如果缺口里包含大量高价值页面，即使数量不多，也应优先补跑；
• 如果缺口主要是低优先级的分页、标签或参数页，可以接受暂不覆盖。

这里要提醒一点：抓取量归零或某段输出为空，不能单独证明“那部分没被处理过”。它也可能是队列尚未到达、并发被限制、或输出写入被中断。要结合时间戳、日志顺序和错误类型一起判断，而不是只凭数量下结论。

把分歧转成可核对的项目

多个角色对“扫了多少”有不同理解时，争论往往停留在各自看到的数字上。更有效的做法是把分歧拆成几个可以逐项核对的项目，例如：

• 参照集合用的是哪一份，生成时间是什么时候；
• 已覆盖清单是否经过去重和状态过滤；
• 重定向和错误页是否计入覆盖；
• 中断点前后是否有时间戳可以定位。

把这些项目写下来逐条确认，分歧通常会从“覆盖了多少”收敛到“按哪个口径算”。口径一旦统一，续跑还是重跑的决定就变得可执行：若参照集合稳定、已覆盖清单干净，只需从缺口补跑；若参照集合本身已过期或已覆盖清单混杂严重，重跑一次反而更省核对成本。

一个可复用的判断顺序

综合来看，中断后判断覆盖范围可以按这个顺序走：先固定应覆盖全集并记录来源，再清洗中断输出得到已覆盖清单，然后做差集并观察缺口分布，最后根据缺口性质选择补跑、续跑或重跑。每一步的结果都会改变下一步的选择，而不是一次性给出结论。具体使用哪款工具、它的当前功能和数据上限，需要以你实际使用的版本和官方说明为准，本文只提供通用的核对方法。