旺格子SEO：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7ed5f18500ea.html
📄
旺格子SEO：一次全站扫描被中断后怎样判断已覆盖范围
扫描中断后，不要先看“完成了多少百分比”，而要先固定中断时正在处理的那一批URL，再拿它和任务日志、导出文件、站点地图三处记录交叉核对。能对上的部分才算已覆盖，对不上的部分按“未确认”处理。下面以一个假设的抓取任务为例，说明怎样把手里残缺的记录转成可执行的处理方案。
先确定中断点落在哪一批，而不是落在一个数字上
全站扫描通常按队列分批推进。中断发生时，最后一批可能只写了一部分结果，也可能已经抓完但没来得及写汇总。判断覆盖范围的第一步，是找到日志里最后一条“开始处理”记录和最后一条“完成处理”记录，比较两者之间有多少条URL。
- 如果最后一批的开始与完成数量一致，说明这批大概率已进入结果文件，可以作为已覆盖候选。
- 如果只有开始没有完成，这批只能算“处理中”，不能计入已覆盖。
- 如果日志本身按时间滚动、旧记录被覆盖，就要改用导出文件的最后修改时间作为辅助线索。
这里要提醒一点：抓取量突然归零，既可能是任务真的停了，也可能是写入被缓冲、日志级别被调高，或者目标站点对同一来源做了限速。单看数量变化不能证明覆盖到哪里，必须回到URL级别的记录。
用三份可核对材料交叉验证覆盖边界
假设你手上有一份中断后导出的结果文件、一份任务日志、一份站点地图。把三者放在同一张清单上比对，比只看导出文件更可靠。
- 从导出文件中提取全部已出现的URL，去重后记为集合A。
- 从任务日志中提取所有“已完成”的URL，记为集合B。
- 从站点地图或站内链接清单中提取本次任务的目标URL，记为集合C。
集合A与集合B的交集，是证据最充分的已覆盖部分；只在A中出现、不在B中的URL，需要确认是否是上一轮遗留结果；只在B中出现、不在A中的URL，说明写入环节可能中断，应重新处理。集合C减去已覆盖部分，就是本次真正需要补扫的范围。
这个比对动作会直接影响下一步：如果A与B高度一致，补扫只需从断点继续；如果A明显小于B，说明导出环节有问题，应先修复写入再重跑，否则补扫结果仍然不完整。
区分“未覆盖”和“覆盖了但没写入”这两种情况
两者在清单上都表现为“缺记录”，但处理方式不同。可以用一个短例子说明：假设目标清单有1000条URL，导出文件里有620条，日志显示已完成780条。
- 620条属于已写入，可直接纳入覆盖范围。
- 日志里另外160条属于“已处理但未写入”，需要先检查导出配置或存储空间，再决定是否重跑。
- 剩余220条从未出现在日志中，属于真正的未覆盖，按原队列顺序补扫即可。
判断依据不是数字本身，而是每条URL在日志和导出文件中的出现状态。如果无法逐条核对，至少抽取中断点前后各一批做人工比对，确认写入延迟是否存在。这个假设例子只用于说明比较方法，实际数量以你的任务记录为准。
把判断结果转成补扫方案
完成核对后，补扫范围应当写成明确的URL清单或队列区间，而不是笼统地“重跑全站”。具体动作可以按下面的顺序执行：
- 导出未覆盖清单，并按原任务的批次顺序排列，避免打乱优先级。
- 对“已处理未写入”的部分，先单独重跑导出或修复写入，再决定是否重新抓取。
- 补扫时保留新的日志，并在每批完成后立即导出一次，减少再次中断造成的损失。
- 补扫结束后，用同一套集合比对方法复核，确认A、B、C三者差异收敛到可接受范围。
需要说明的是，不同工具的日志字段、导出格式和断点续跑能力差异较大，具体入口和当前功能需要以你实际使用的版本为准，不能照搬这里的字段名。判断覆盖范围的核心始终是：用URL级别的证据说话，而不是用完成百分比或抓取总量下结论。
哪些情况下这套判断不成立
如果任务没有保留日志，或者导出文件只存了汇总数字，那么逐条核对就无从谈起，只能以站点地图和站内链接作为近似目标清单，重新跑一轮并全程记录。另一种情况是目标站点在扫描期间发生了结构变化，旧清单本身已经失效，此时补扫前应先更新目标URL集合，否则核对结果会把已删除页面误判为未覆盖。明确这两个前提，再决定是继续补扫还是重新开始。
