Google关键词工具：一次全站扫描被中断后怎样判断已覆盖范围，假设情境：扫描到一半进程被杀，先别急着重跑
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c2e388a918e8.html
📄
Google关键词工具：一次全站扫描被中断后怎样判断已覆盖范围，假设情境：扫描到一半进程被杀，先别急着重跑
中断后不要先看总数，而要先确认扫描器把哪些URL判定为“已处理”。已处理不等于已成功，它可能包含成功取数、明确跳过、以及被中断时正在处理但未写入结果三类。判断覆盖范围时，应以“已写入结果且能对应到具体URL”的记录为下限，以“已发现且尚未写入结果”的URL为缺口，再决定是续扫、重扫还是缩小范围。下面用一个假设情境把这条判断路径走完。
假设情境：扫描到一半进程被杀，先别急着重跑
假设你为一个约两万页的站点跑全站扫描，目标是给每页匹配一组关键词和竞争度参考。任务跑到大约四成时被系统终止，日志只留下一行退出记录，结果文件里有一批数据。此时最容易犯的错是直接重新发起全站扫描：如果工具按URL重新取数，你会重复消耗配额；如果它按目录分片，你又会漏掉中断时正在处理的那一批。正确顺序是先做覆盖判定，再决定动作。
前提条件要写清楚：你手里得有URL清单和结果文件两个东西。没有URL清单，覆盖范围就无法核验，只能重扫；没有结果文件，中断前的进度就不可恢复。这两样缺一，后面的判断都不成立。
用“已写入结果”而不是“已处理”定义覆盖下限
很多扫描器会同时维护两个计数：已发现URL数和已处理URL数。中断时“已处理”往往包含正在处理但尚未落盘的任务，所以它偏高。可核验的下限是结果文件里能逐条对应到URL的记录。
实际动作：把结果文件里的URL去重，导出一份“已有结果URL集合”，再和完整URL清单做差集。差集就是未覆盖部分。这个动作的结果直接决定下一步——如果差集很小且集中在某几个目录，续扫那几个目录即可；如果差集覆盖全站且分布零散，说明扫描是按随机或并发顺序推进的，续扫无法保证不重不漏，应改为按目录分片重扫。
需要留意的合理解释：结果条数少于预期，不一定代表扫描失败。也可能是部分URL被规则跳过，例如参数页、重复内容页或非HTML资源。要区分“跳过”和“未处理”，得看结果文件里有没有跳过原因字段，而不是只看数量。
用三个证据判断中断点落在哪一类
判断中断位置，可以收集三类可区分的原因证据：
- 时间戳聚集：结果记录的时间戳如果集中在中断前某个区间，之后突然断档，说明是顺序推进被打断，中断点之后基本未覆盖。
- 目录分布：如果已有结果覆盖了A、B目录却完全没有C目录，而URL清单里C目录占比不小，说明扫描按目录顺序推进，缺口边界清晰。
- 错误记录：如果结果里混有超时或取数失败条目，这些URL属于“处理过但没拿到有效数据”，既不算覆盖也不算干净缺口，需要单独列出重试。
这三类证据指向的动作不同：时间戳断档适合从断点续扫；目录缺口适合按目录补扫；错误条目适合单独重试而不是全量重跑。把三类混在一起看，就会得出“覆盖了一半”这种无法指导操作的结论。
续扫、补扫还是重扫：按缺口形态选
三种处理方式各有成立条件：
- 续扫成立的条件是扫描顺序稳定、有断点记录、且工具支持从指定位置继续。缺任何一个条件，续扫都可能造成重复或遗漏。
- 补扫成立的条件是缺口能按目录、URL模式或时间窗口切分。补扫的范围要写成明确的URL集合，而不是“剩下的部分”。
- 重扫成立的条件是缺口零散、顺序不可复现，或结果文件本身不完整。重扫前应先缩小范围，例如只扫核心栏目，避免再次被中断。
假设例子：两万页站点中断后，差集显示缺口集中在“产品”目录的八千页，其余目录完整。此时补扫产品目录是合理动作；补扫完成后，把新结果与旧结果按URL合并去重，再核对总数是否接近URL清单。如果合并后仍缺几百页，那几百页大概率是跳过项或错误项，应逐条查看原因，而不是再发起第三次全站扫描。
把覆盖判定固化成下次可复用的检查点
中断本身不可怕，可怕的是没有可核验的中间状态。要减少下次的判断成本，可以在扫描前做两件事：先导出完整URL清单并留存；再让工具按可切分的批次输出结果，例如按目录或按固定条数分片。这样即使中断，你面对的是“哪些分片已完成”，而不是“大概跑到哪了”。
另外要明确一点：请求量、抓取量或结果条数归零，不能单独证明扫描器处理正确。它也可能是被限流、被拦截或任务根本没启动。判断覆盖范围最终要回到URL级别的对应关系上，数量只是辅助信号。把这条原则用熟，中断后的决策就从猜测变成了核对。
