旺道seo软件一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fce9fd770572.html
📄
旺道seo软件一次全站扫描被中断后怎样判断已覆盖范围
中断后的第一步不是重跑，而是判断中断前已经覆盖了哪些页面、哪些页面只是排队未处理。只有把“已抓取并写入结果”和“已进入队列但未完成”分开，才能决定是续跑剩余部分还是整站重扫。
先区分三种状态，而不是只看进度条
全站扫描被中断时，最容易误判的是把“已发现链接”当成“已处理页面”。假设一个情境：某站点约八千个可访问 URL，扫描进行到大约四成时进程被终止。恢复后如果只看总数，会以为已完成四成，但实际可能包含三类不同状态的记录。
- 已完成：页面已请求、已解析，结果已写入输出文件或数据库。这类记录才计入覆盖范围。
- 已入队未处理：链接已被发现并加入待抓列表，但尚未发起请求或请求被中断。这类不能算覆盖。
- 已请求未落盘：请求发出过，但结果还在内存缓冲中，进程终止后丢失。这类最隐蔽，需要靠日志或写入时间戳识别。
判断动作：打开输出文件，按“最后写入时间”排序，找到中断时刻附近的记录边界。如果输出是逐条追加的，边界之后的记录基本可以视为未完成；如果输出是批量写入的，则要看最后一批是否完整落盘。这个动作的结果直接决定下一步：边界清晰就续跑，边界模糊就缩小范围重扫。
用可复现的样本反推覆盖边界
当输出文件没有可靠时间戳时，可以抽取一批已知 URL 做对照。做法是从站点地图或栏目页取若干条链接，逐条在输出结果中查找是否存在对应记录。
这里要注意适用条件：样本成立不代表整体成立。如果抽取的样本恰好集中在扫描早期处理的栏目，会高估覆盖范围；如果集中在后期栏目，会低估。因此样本要跨栏目、跨层级抽取，并记录每条样本属于哪个栏目，再按栏目分别统计命中率。
假设抽查了五个栏目各二十条链接，其中三个栏目命中率接近全部，两个栏目命中率很低。合理的解释不是“扫描覆盖了六成”，而是“扫描在进入后两个栏目之前被中断”。这个推断会改变下一步：只需针对低命中栏目重扫，而不必整站重来。
中断原因会影响能否安全续跑
同样是中断，原因不同，续跑的安全性也不同。需要先看中断是外部终止还是内部异常。
- 外部终止（手动停止、进程被系统回收、机器重启）：已写入的结果通常可信，续跑时只需避免重复处理已完成 URL。
- 内部异常（程序报错、内存耗尽、目标站点返回异常）：已写入的结果可能包含不完整解析，续跑前应检查错误日志中出现异常的页面是否被标记为完成。
如果工具支持断点续跑，先确认续跑依据的是哪份状态记录——是输出文件本身，还是单独的队列文件。两者不一致时，以输出文件为准更稳妥，因为队列文件可能包含大量未真正处理的链接。具体工具的行为需要以实际版本和日志为准，不能凭印象假定。
决定续跑还是重扫的判断依据
把上面的信息汇总后，可以用三个条件做取舍。
- 已完成记录是否可逐条验证：能验证，倾向续跑；不能验证，倾向缩小范围重扫。
- 未覆盖部分是否集中在少数栏目：集中，续跑剩余栏目；分散，整站重扫成本可能更低。
- 中断前的结果是否已用于其他环节：如果下游已经基于这份结果做了处理，重扫会产生新旧两版数据，需要先确认以哪版为准。
这三个条件没有固定权重，取决于你对结果准确度的要求。如果这份扫描只是用于内部排查，续跑加抽样校验通常够用；如果要交付给他人或用于后续批量处理，边界不清时重扫更省事。
把覆盖范围写清楚，避免下游误用
无论最终选择续跑还是重扫，都应在结果中标注覆盖边界，而不是只给一个总数。可以记录：扫描时间区间、已处理 URL 数量、未处理部分的范围说明、以及哪些栏目是抽样验证过的。
这样做的实际影响是：下游拿到结果时，能判断哪些结论可以整体使用，哪些只能用于已验证的栏目。如果省略这一步，一个覆盖六成的扫描结果很容易被当成全站结论使用，后续决策就会建立在错误前提上。
