SEO词库工具，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9aaa6f9344c4.html
📄
SEO词库工具，一次全站扫描被中断后怎样判断已覆盖范围
先给有条件的结论：如果扫描中断前已经产生可导出的中间结果，并且每条记录带有抓取时间、来源页或批次标记，那么“已覆盖范围”可以按这些标记还原；如果工具只在扫描全部结束后才落盘、中断后只剩进度条，那么覆盖范围无法从结果文件判断，只能按日志或请求记录重建。两种情况的处理动作完全不同，先确认属于哪一种，再决定是补扫还是重扫。
先看中断时留下了什么，再谈覆盖
判断覆盖范围的第一步不是问“扫了多少”，而是问“中断那一刻，哪些数据已经独立于扫描进程存在”。可以导出的中间结果、写进数据库的批次号、带时间戳的请求日志，这三类证据的价值依次递减，但只要存在其中一类，就能把覆盖范围收敛到一个可核对的区间。
相反，如果工具采用“全部完成后一次性写入”的模式，中断后本地文件为空或只有临时状态，那么任何关于覆盖比例的估计都只是猜测。此时更可靠的做法是看扫描配置里设定的入口列表，按入口逐个确认是否被访问过，而不是相信进度显示。
把“已覆盖”拆成三个可以分别核对的事实
多人对同一事实有不同理解，通常是因为把三件事混成了一件。把它们拆开后，分歧会变成可以逐项核对的项目：
- 入口覆盖：扫描配置里的起始 URL 或词表条目，有多少已经被实际请求过。这一项看日志或批次记录就能确认。
- 结果落盘：已请求的内容有多少写进了最终结果集。中间结果存在时这一项可查，否则不可查。
- 结果可用：落盘的结果是否完整到能用于后续分析，比如是否缺少关键字段、是否只存了部分分页。
三个人说“扫了大概一半”，往往分别指这三项中的不同一项。先约定按哪一项对齐，再讨论数字。
一个会使上述结论失效的反例
假设扫描工具支持断点续扫，但续扫时只从上次中断的队列位置继续，不重新校验已经写入的结果。这种情况下，即使中间结果存在、批次标记完整，覆盖范围仍然可能被高估：中断前最后一批请求可能已经发出但未收到响应，恢复后队列从下一项开始，这一批就成了既不在已完成集合、也不会被重扫的空白。
识别这个反例的方法是核对请求日志与结果记录的数量差。如果日志里存在请求记录、结果集里没有对应条目，且续扫后该条目仍未出现，就说明存在这种缺口。此时“已覆盖范围”不能直接取结果集的条目数，需要把日志与结果做一次差集。
按假设例子走一遍核对动作
以下为假设场景，仅用于说明比较方法，不代表任何具体工具的行为。
假设一次扫描配置了 200 个入口，中断时日志显示已请求 120 个，结果集里有 115 条记录。差集为 5 个入口，需要先确认这 5 个是请求失败、响应超时，还是写盘失败。处理动作是：把这 5 个入口单独发起一次小范围扫描，观察是否正常返回并写入。如果正常写入，说明原中断只是偶发，覆盖范围可以按 120 个入口计；如果仍然不写入，说明存在配置或权限问题，此时继续补扫剩余 80 个入口没有意义，应先解决写入问题，否则补扫结果同样落不了盘。
这个动作的结果直接决定下一步：差集能补齐，就按入口数补扫；差集补不齐，就先修配置再整体重扫，而不是在不可靠的基础上继续叠加。
给多人协作留一份可核对的记录
要避免下一次再出现理解分歧，中断后应立即记录四件事：中断时间、当时的入口游标、结果集条目数、日志与结果集的差集数量。这四项写在同一处，任何人复核时都能得出相同结论。记录时不写“大概扫了一半”这类描述，只写可复查的数字和对应的文件或批次标识。
需要说明的是，请求量或抓取量归零并不自动等于覆盖为零，也可能是日志轮转、采集延迟或写盘失败造成的表象。遇到这类现象，先换一个证据源交叉验证，再下结论。
