关键词排名查询：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /85e107ad2a75.html
📄
关键词排名查询：一次全站扫描被中断后怎样判断已覆盖范围
中断后不要直接重跑全站，也不要凭“跑了一半”估算。先确认扫描器是否留下任务清单或断点文件：有清单时按清单比对，无清单时用抽样反查边界。前者能精确知道哪些页面已处理，后者只能给出一个带不确定性的范围。两种条件下判断方法不同，混用会得出错误结论。
条件一：扫描器留下了任务清单或断点文件
这是最省事的情况。多数批量查询工具在启动全站任务时会先生成待处理队列，逐条写回状态。中断后重新打开任务，先看队列里每条记录的状态字段，而不是看总进度条。进度条通常按已完成条数除以总条数计算，但总条数可能在中途因新链接发现而变化，所以进度条不可靠。
实际动作：导出队列，按状态分为已成功、失败、未开始三类，统计三类各占多少。如果失败条目集中在同一批域名或同一时间段，说明中断原因可能是限流或网络抖动，而不是任务本身有问题。下一步应先对失败条目做小批量重试，观察是否稳定返回，再决定是否重跑全量。若失败条目分散且无规律，更可能是任务被外部强制终止，此时直接从未开始部分续跑即可。
需要注意的例外：断点文件可能只记录“已发起请求”而非“已成功获取结果”。如果工具在请求发出后、结果落盘前被中断，这条记录会显示已处理但实际没有数据。核对方法是随机抽若干条“已成功”记录，检查其排名字段是否为空或为默认值。空值比例偏高时，应把这一批视为未覆盖。
条件二：没有清单，只有部分结果文件
这时无法精确还原覆盖范围，只能通过结果文件本身反推边界。先看结果文件里是否带有查询时间戳或批次编号。有时间戳时，按时间排序，找出最后一个完整批次的时间点，之后的内容视为不完整。没有时间戳时，转而看页面标识的分布：如果结果按站点目录或URL前缀顺序写入，中断点通常落在某个前缀区间内，可以据此判断哪些目录整体缺失。
实际动作：从结果中抽取若干条记录，回到站点上确认这些页面当前是否仍存在、是否仍可访问。这一步的目的不是验证排名是否准确，而是确认结果文件覆盖的是同一批URL集合。如果抽样发现部分URL已改版或跳转，说明结果文件对应的站点结构与当前不一致，此时即使补跑剩余部分，合并后的数据口径也不统一，应整体重跑而非续跑。
假设一个短例子说明判断方法：某次扫描计划覆盖约两千个页面，中断后结果文件里只有按字母顺序排列的前若干目录。抽取其中三条记录，发现两条对应的页面已迁移到新路径，一条仍可访问。这种情况下，已覆盖部分和未覆盖部分对应的URL集合不同，续跑会得到新旧混杂的结果，正确做法是重新生成完整URL清单后再启动。
判断已覆盖范围时容易踩的两个坑
第一个坑是把“有结果”等同于“覆盖完整”。一条记录存在，只说明该页面被查询过，不说明查询时用的是正确的目标域名、正确的地区参数或正确的匹配方式。中断后如果工具重置了这些参数，已覆盖部分和续跑部分的排名口径可能不同。核对方法是比较中断前后各抽一条记录的参数快照，参数不一致时不能合并。
第二个坑是用抓取量归零来判断任务结束。请求量或写入量降为零，可能是任务真的跑完了，也可能是被限流后静默等待、进程已退出但未写结束标记、或结果写入了另一个临时文件。归零本身不构成完成证据。更可靠的完成标志是任务状态字段变为终态，或队列中未开始条目数为零。两者都没有时，应主动检查进程状态和目标输出目录，而不是等待。
决定续跑还是重跑的依据
判断标准可以收敛为两点：已覆盖部分的参数与URL集合是否与计划一致，以及未覆盖部分能否被准确识别。两者都满足时，续跑并合并结果；任一不满足时，重新生成清单后整体重跑。全站扫描被中断本身不是问题，问题是用一个口径混杂的结果去做后续的排名对比或趋势判断，那会让后面的每一步都建立在不确定的基数上。
如果工具本身不提供队列导出或断点续跑，那么每次中断都只能整体重跑，这时更实际的做法是把全站拆成按目录或按优先级分批的小任务，让单次中断的损失范围可控。具体工具是否支持这些能力，需要以你实际使用的版本说明为准，不同版本之间差异可能很大。
