批量查询关键词排名，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3b92a46c87ca.html
📄
批量查询关键词排名，一次全站扫描被中断后怎样判断已覆盖范围
结论先给：如果扫描任务在中断时留下了逐条进度记录或可导出的中间结果，你可以按“已写入条数 ÷ 应查总数”估算覆盖范围，并只补跑缺失部分；如果只有一条总进度条、没有逐条记录，那么中断前的覆盖范围无法可靠还原，应当整批重跑或改用分批任务。判断的关键不是中断发生在百分之几，而是中断前后是否存在可核对的条目级痕迹。
先分清两种中断：有中间产物和没有中间产物
批量查询关键词排名的全站扫描，通常由三部分组成：待查关键词清单、逐条查询过程、结果写入。中断可能发生在任何一段。判断覆盖范围前，先确认中断时哪一段有留存。
- 有中间产物：任务把每条结果即时写入文件、数据表或日志，你能看到已完成的条目及其时间戳。此时覆盖范围可直接统计，不需要猜测。
- 无中间产物：结果只在任务结束时一次性输出，中断即丢失。此时进度条显示的百分比只能说明“处理到哪”，不能说明“哪些已完成”，覆盖范围不可还原。
这两种情况对应完全不同的下一步：前者补跑差额，后者重跑全量。把无中间产物当成有中间产物去补跑，最容易造成重复查询和结果错位。
用三个可核对的证据确认已覆盖范围
当你手上有一份中断后的残留数据，不要只看条数，要同时核对以下三点，才能判断它是否真的覆盖了那部分关键词。
- 条目主键是否连续且可对齐：把残留结果与原始关键词清单按同一标识（如关键词本身或内部编号）做匹配。能一一对应的部分，才算真正覆盖；对不上的条目即使有记录，也不能计入。
- 时间戳是否落在中断之前：如果结果带有写入时间，晚于中断时刻的记录可能来自重试或重复写入，需要单独剔除，否则会高估覆盖。
- 空结果与未查询是否可区分：某关键词查不到排名，和某关键词根本没被查到，是两回事。只有工具明确写出“已查询、无结果”时，才能把它算作已覆盖；缺失记录应视为未覆盖。
这三点里只要有一点无法满足，覆盖范围就只能给出区间，不能给出确定数字。区间估算可以用于决定补跑策略，但不能用于对外汇报完成度。
一个会推翻上述结论的反例
假设你的任务确实有逐条日志，条数也对得上，但中断发生在结果写入阶段而不是查询阶段：查询已经跑完，写入只完成了一部分。这时“已查询条数”和“已写入条数”不一致，按写入条数估算覆盖会偏低，按查询日志估算又会偏高。
更麻烦的是，如果写入是覆盖式而非追加式，重跑补缺可能把已有结果冲掉。因此，只要中断点靠近写入环节，前面基于条数比例的判断就失效，必须先确认写入方式，再决定补跑还是重跑。这个反例说明：覆盖范围问题本质上是数据一致性问题，不只是进度问题。
据此决定下一步动作
确认覆盖范围后，动作分三种：
- 可对齐、可区分空结果：只补跑未覆盖的关键词，并在补跑前把残留结果另存一份，避免写入冲突。
- 只能估算区间：按最坏情况补跑，即把不确定部分全部重查，宁可重复也不漏。
- 无中间产物：整批重跑，并把任务拆成可按批次独立完成的小块，让下次中断时至少能保住已完成批次。
执行补跑后，用同一套对齐方法再核对一次总数，确认补跑结果与残留结果没有重复或冲突，再进入下一步分析。这个核对动作本身也会告诉你，当前工具是否适合继续承担全站扫描；如果每次中断都无法还原范围，就该考虑把任务拆小或更换写入方式，而不是反复重跑全量。
