关键词排名批量查询：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /38e0c9c7b59d.html
📄
关键词排名批量查询：一次全站扫描被中断后怎样判断已覆盖范围
先看扫描中断时留下的最后一条成功记录和它对应的时间戳，用这条记录去匹配你事先准备的查询清单，就能确定断点前已经覆盖到哪一批；如果清单本身没有稳定顺序，覆盖范围就只能靠结果行去反推，判断会变得不可靠。因此，中断后第一件事不是重跑，而是把“已产出结果”和“计划查询对象”做一次对账。
把查询清单变成有顺序、可对账的对象
全站扫描通常是把一批“域名或页面 + 关键词”的组合逐条送进查询。中断后能否判断覆盖范围，取决于这份组合清单是否具备两个条件：每条组合有唯一标识，且执行顺序固定。假设你手里是一份页面 URL 清单和一份关键词清单，最稳妥的做法是先生成笛卡尔组合，给每条组合编号，再按编号顺序执行。这样中断时只要拿到最大已成功编号，覆盖范围就是编号 1 到该编号。
如果工具只能按“每个页面查全部关键词”或“每个关键词查全部页面”其中一种维度推进，就选与结果表主键一致的那一维。例如结果表每行是“页面—关键词—排名”，就按页面推进；结果表每行是“关键词—页面—排名”，就按关键词推进。维度选错，断点编号和结果行就对不上，后续判断全部失真。
中断后先做对账，再决定补跑还是重跑
具体动作分三步。第一步，从结果存储中取出已成功写入的全部记录，按组合编号去重，得到实际覆盖集合。第二步，把计划组合集合减去实际覆盖集合，得到缺口集合。第三步，检查缺口是否连续：如果缺口集中在尾部，说明是顺序执行被打断，补跑缺口即可；如果缺口零散分布，说明中间有失败重试或并发写入丢失，应怀疑结果完整性，而不是简单续跑。
判断缺口是否连续时，可以看已覆盖编号的最大值是否接近计划总数，以及缺失编号是否都大于某个阈值。假设计划 1000 条，已覆盖编号最大值为 620，且 1 至 620 中缺了 7 条，那么覆盖范围就是 620 条中的 613 条，缺口是这 7 条加 621 至 1000。这个例子只用于说明比较方法，实际数字以你的清单为准。
两种续跑思路的取舍条件
第一种是只补缺口，代价低、耗时短，但前提是结果存储可靠、编号唯一、且中断没有破坏已写入数据。第二种是整批重跑，代价高，但能规避“已写入结果其实不完整”的风险。选择条件可以这样定：如果结果表有唯一约束、每次写入可确认成功、且缺口连续，选补缺口；如果结果表允许重复写入却没有去重键、或者缺口零散、或者你不确定中断时是否有半写入记录，选整批重跑或至少重跑受影响区间。
还要考虑查询本身的时效性。排名类数据随时间变化，如果中断发生在数小时甚至跨天之前，补跑缺口会得到与前面批次不同时间点的数据，整份结果的“同一时刻”假设就被破坏。这种情况下，与其拼接新旧数据，不如重跑整批，让所有组合落在同一时间窗口内。反之，如果查询对象是相对稳定的页面元信息，时间错位影响小，补缺口更划算。
用覆盖范围决定下一步，而不是用请求量
中断后请求量归零或抓取量下降，只能说明进程停了，不能说明已覆盖范围正确。可能有几种合理解释：进程被系统终止、网络超时、配额耗尽、或写入端阻塞。要区分这些原因，看的是结果表最后一条成功记录的时间与编号，以及日志中最后一次成功写入和第一次失败之间的间隔。如果最后成功记录之后还有多次失败重试，说明覆盖范围停在最后成功编号，而不是停在请求次数上。
拿到覆盖范围后，下一步动作取决于缺口比例。缺口很小且连续，补跑后重新对账一次，确认覆盖集合等于计划集合，再进入分析。缺口很大或分布混乱，直接重跑整批，并在重跑前给组合加上执行批次标识，避免新旧数据混在一起。无论哪种，都不要在覆盖范围未确认前就导出报表，否则排名统计会建立在残缺样本上。
给下次扫描留一个可恢复的断点
要减少下次中断后的判断成本，可以在执行前把组合清单落盘为带编号的文件，执行时每成功一条就追加写入“编号 + 时间戳 + 结果主键”。这样中断后无需扫描全量结果，只要读取最后一条成功追加记录即可确定断点。这个动作的代价是增加一次写盘，但换来的是覆盖范围可直接判定，不必靠结果行反推。对需要反复执行的关键词排名批量查询来说，这比事后猜测更省时间。
最后提醒一点：不同工具对“成功”的定义可能不同，有的只要返回响应就算成功，有的要求解析出排名才算。具体判定口径需要以你所用工具的说明为准，必要时先用小批量验证一次写入行为，再决定补跑还是重跑。
