seo常用工具：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /94a5cac363e2.html
📄
seo常用工具：一次全站扫描被中断后怎样判断已覆盖范围
中断后不要凭感觉重跑，先判断“已覆盖范围”是完整可用的数据，还是只够当作线索。判断依据不是扫描了多久，而是工具是否留下了可核对的已完成单位、失败单位和未开始单位。只有这三类边界能对上，覆盖范围才可信。
先区分两种中断：可续跑与只能重来
同样是中断，代价完全不同。可续跑的前提是工具把进度写成了持久记录，例如已完成的 URL 清单、分页游标或批次状态；只能重来的情况是进度只存在内存里，进程一停就全部丢失。
判断方法很直接：中断后重新打开任务，看它是否显示“从上次位置继续”之类的明确状态，或者能否导出已完成清单。若只能从头开始，就必须放弃“已覆盖多少”的追问，转而评估重跑成本。
- 有持久进度：先导出已完成单位，再核对数量与顺序，确认断点位置。
- 无持久进度：把本次结果整体标记为不完整，不要拿它当全站结论。
用已完成清单反推真实覆盖范围
不要用“扫描时长 × 平均速度”估算覆盖量，这个数字在中断场景下几乎必然失真。可靠做法是拿到已完成单位清单，再与站点自己的 URL 来源做比对。
具体动作：从工具导出已完成 URL，与 sitemap、站内链接抓取结果或日志中的访问路径合并去重，得到一份基准清单。然后做集合差，差集就是未覆盖部分。这个动作的结果会直接决定下一步——如果差集集中在某个目录或某种页面类型，说明中断恰好截在边界上，续跑价值高；如果差集零散分布，说明顺序本身不稳定，续跑后仍需二次核对。
这里要说明一个容易误判的现象：抓取量或请求量归零，不能单独证明扫描已经结束或覆盖完整。它还可能来自限速触发、目标站点临时拒绝、网络中断或工具自身队列清空。看到归零先查这三类原因，再谈覆盖范围。
两种条件下的不同选择
条件一：站点规模可控、URL 来源清晰
如果站点 URL 总量不大，且你能从 sitemap 或日志拿到接近完整的基准清单，建议选择“续跑 + 差集核对”。代价是要多花一轮比对时间，收益是最终覆盖范围可以量化到具体 URL。
实施时先确认续跑是否真的从断点开始，而不是重新排队。若工具无法保证顺序一致，续跑后仍要重新导出清单再比对一次，否则两次结果混在一起会掩盖缺口。
条件二：站点规模大、URL 来源本身不全
如果基准清单本身就不完整，续跑得到的“覆盖率”只是相对某个不完整分母的比例，参考价值有限。此时更合理的选择是放弃精确覆盖率，改为按目录或模板分层抽样验证。
做法是选取若干有代表性的目录，分别检查其中已覆盖与未覆盖的比例，用这些比例描述整体覆盖的大致分布。代价是无法给出一个全站百分比，收益是避免被一个虚假的完整分母误导。
一个注明假设的短例子
假设某站点有 5000 个 URL，中断时工具显示已完成 3000 个，但导出清单只有 2800 条，差额 200 条可能来自失败重试或状态未落盘。此时不能直接说覆盖了 60%。
下一步动作是：先查这 200 条差额属于哪一类。若属于失败单位，它们需要单独重试；若属于状态未落盘，则 3000 这个数字本身不可信，应以导出清单为准。这个动作的结果决定了续跑时是从第 2800 条之后开始，还是必须整体重跑。
续跑之后必须补的一步核对
无论选择哪种方式，续跑完成后都要做一次收尾核对：把最终已完成清单与基准清单再做一次差集，确认没有因断点衔接而漏掉中间段。这一步常被跳过，但恰恰是中断场景下最容易出问题的地方。
如果工具提供失败单位重试记录，优先核对失败单位是否已全部处理。失败单位往往集中在特定状态码或特定模板页面，漏掉它们会让覆盖范围看起来完整，实际却缺失关键类型。
最后，把本次扫描的覆盖范围、未覆盖部分和判断依据一起记录下来。这样下次中断时，你不需要重新推理，直接对照上次的边界即可。具体工具是否支持持久进度、能否导出已完成清单，需要以你实际使用的版本为准核对。
