SEO综合查询工具：一次全站扫描被中断后怎样判断已覆盖范围

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

SEO综合查询工具：一次全站扫描被中断后怎样判断已覆盖范围

先不要重新点一次全站扫描。中断后判断覆盖范围，靠的是这次任务留下的可核对痕迹：任务开始时间、中断时间、已完成的页面清单或日志、以及扫描配置在中断前后是否被改过。把这几项固定下来，再决定是续跑缺口还是整体重跑。下面按“有可导出的完成清单”和“只有进度数字或状态”两种条件分别说明。

先固定事实：中断不是覆盖范围的证据

很多分歧来自把“进度条走到某处”当成“前面都已覆盖”。进度数字通常只表示任务调度到哪一步，不等于每个URL都拿到了完整结果。可核对的事实至少包括四类：任务启动与中断的准确时间；中断前是否有人改过抓取配置（并发、超时、排除规则、User-Agent）；已产出结果是逐条列表还是只有一个汇总数；以及中断是发生在抓取阶段、解析阶段还是写入阶段。

一个实际动作：让所有相关角色各自写下“我看到的覆盖范围是多少、依据是什么”，再逐条对照上面的四类痕迹。结果通常会暴露两种分歧——一方看的是已写入结果，另一方看的是已调度队列。这一步不解决覆盖问题，但决定了下一步该查缺口还是查重复。

条件一：能导出已完成URL清单时，按差集续跑

如果工具在中断后仍保留了逐条结果（例如可导出的URL列表、日志文件或接口返回），判断覆盖范围就变成一次集合运算，而不是猜测。做法是：先导出本次任务已完成的URL集合，再导出你期望覆盖的URL全集，两者相减得到缺口。

关键前提有三个。第一，导出的是“已完成且结果完整”的记录，而不是“已请求”的记录；被请求但超时、被限流、被拦截的URL往往也在列表里，必须按状态字段剔除。第二，期望全集本身要明确来源——是站点地图、内部链接抓取结果，还是上次已知的页面清单。第三，中断后配置没有被改动；如果排除规则或抓取深度变了，差集就没有可比性。

一个假设的短例子：假设期望全集是1000个URL，导出显示已完成620条，其中40条状态为超时或错误，那么可视为完整覆盖的是580条，缺口为420条。此时续跑只需针对缺口和错误项，而不是重跑全部1000条。这个动作的结果直接决定下一步：如果错误项集中在同一目录或同一模板，先排查该模板的响应问题，再续跑，否则续跑会重复产生同样的错误。

条件二：只有进度数字或状态时，用抽样反推边界

如果工具只给出“已完成约60%”这类汇总，没有逐条清单，就不能把百分比换算成具体覆盖了哪些URL。这时可行的办法是抽样核对，而不是相信数字。

  1. 从期望全集中按固定间隔抽取若干URL，逐个在已产出结果里查找是否存在完整记录。
  2. 记录每个抽样URL的状态：有完整结果、有记录但不完整、完全缺失。
  3. 观察缺失是否呈规律分布——集中在某个目录、某个时间之后、还是随机散布。

如果缺失呈规律分布，说明中断点或配置边界大致可定位，可以按该边界续跑。如果缺失随机散布，说明写入或解析环节可能不稳定，此时续跑的可信度低，更稳妥的做法是重跑，并在重跑前把结果改为逐条落盘，避免下次再遇到同样问题。这里要说明：抽样只能给出覆盖范围的估计，不能证明全部覆盖；抽样数量越大、分布越均匀，估计越可靠，但它始终是估计。

把分歧转成可核对的项目

多个角色对同一事实理解不同时，与其争论“到底扫了多少”，不如把判断拆成一张可勾选的核对表，每项都指向一个能打开看的证据：

每一项都要求附上来源，而不是结论。这样做的结果是把“我觉得覆盖了大部分”变成“这420条没有完整结果，其中300条集中在同一模板”。下一步的取舍随之明确：缺口集中就先修再续，缺口随机就重跑并改落盘方式。

例外：这些情况下不能按缺口续跑

有三种情况应放弃续跑、选择重跑或先修配置。第一，中断发生在解析或写入阶段，已产出的记录可能部分缺失字段，差集看起来完整但内容不可用。第二，中断后站点结构或URL规则发生了实质变化，旧全集已经失效。第三，工具本身没有稳定保存中间结果，续跑实际上会从零开始，此时“续跑”只是名义上的。

还要注意一个反常现象：请求量、抓取量或某项统计归零，不能单独证明覆盖正确。它也可能是任务被限流、被拦截、配置写错或日志未落盘造成的。遇到归零，先核对配置和错误日志，再判断是覆盖完整还是任务根本没跑起来。

无论选哪条路，最后都要留下这次判断的依据和缺口清单，作为下一次扫描的对照基线。没有基线，下一次中断还会回到同样的分歧。

图1 图2
nginx