权重查询工具，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /282376e798d9.html
📄
权重查询工具，一次全站扫描被中断后怎样判断已覆盖范围
中断后不要凭扫描进度条或已用时估算覆盖面。更可靠的做法是先确认本次任务有没有留下可核对的完成标记，再用抽样回查区分“已抓取但未写入”和“确实未抓取”。假设一次扫描计划覆盖800个页面，在第420个页面附近因网络或会话失效中断，下面按这个情境说明怎样把范围判断清楚。
先判断中断发生在抓取阶段还是写入阶段
全站扫描通常分两步：先逐页请求并解析，再把结果写入结果集或导出文件。中断位置不同，判断方法也不同。
- 抓取阶段中断：多数页面还没有返回数据，结果集中往往只保留已成功写入的部分。此时“已覆盖”大致等于结果集中可查询到的记录数，但还要扣除失败重试占位记录。
- 写入阶段中断：页面已经请求过，但结果没有落盘。这种情况下结果集看起来很小，实际请求量却接近中断点，不能把结果集条数当作覆盖范围。
要区分两者，先看任务日志或运行记录里有没有“请求完成”和“结果写入”两类计数。如果只有请求计数明显高于结果条数，说明中断更可能发生在写入阶段，下一步应优先检查导出文件和缓存，而不是直接重跑全站。
用三组证据交叉核对已覆盖范围
单看一个数字容易误判。把下面三组证据放在一起，才能缩小范围。
- 结果集条数：这是最直接的覆盖下限，但它不包含抓取成功却未写入的页面，也不包含被规则跳过的页面。
- 任务日志或运行记录：关注最后一条成功记录的时间戳和对应页面。如果日志按顺序记录，中断点之前的页面通常可视为已处理，中断点附近需要回查。
- 站点自身的页面清单：用站点地图、栏目列表或数据库中的URL清单作为基准，与结果集做差集。差集里既包含真正漏掉的页面，也包含本次任务本就不打算处理的页面，需要再按范围规则过滤一次。
假设结果集有390条，日志显示最后成功处理到第418个页面，而站点清单共800条。此时不能直接说覆盖了390个或418个。合理判断是：约390条已进入结果集，第418个页面之前的请求大概率已发出，第419到800个页面基本未处理。第390到418之间属于需要抽样确认的灰区。
抽样回查哪些页面，才能确认灰区
灰区不需要全部重跑，但抽样要覆盖不同位置，而不是只抽开头几个。
- 从灰区起点、中点和终点各取少量页面，逐个在结果集中查找。如果中点页面已有记录而终点没有，说明写入大致停在两者之间。
- 优先抽有代表性的页面：首页、栏目页、深层内容页各取一个。只抽首页会高估覆盖范围，因为首页往往最先被抓取。
- 对抽到的页面记录它属于“有记录”“无记录但日志显示已请求”“无记录且日志无请求”三类。第三类才是确定未覆盖的部分。
这个动作的结果会直接决定下一步：如果灰区抽样大多有记录，可以只补跑尾部；如果灰区大多无记录，说明写入中断得比日志显示的更早，应按日志最后成功时间往前留出余量再补跑。
补跑前先固定范围，避免重复和遗漏
判断出大致覆盖范围后，不要立刻重跑全站。先做两件事：
- 把已确认覆盖的URL整理成排除清单，补跑时跳过，减少重复请求。
- 把灰区和确定未覆盖的URL合并成补跑清单，按原扫描顺序排列，便于中断后再次续跑。
如果工具支持断点续跑，先核对它的续跑依据是URL清单还是内部游标。依据不明确时，按外部清单补跑更可控。补跑完成后，再用同一套差集方法核对一次，确认补跑清单中的页面都已进入结果集。
哪些现象不能单独证明覆盖判断正确
结果集条数突然归零、请求量骤降或日志停止增长，都不等于覆盖范围已经确认。它们还可能是会话过期、限流触发、导出延迟或日志缓冲未刷新造成的。遇到这些现象，先看时间戳是否连续、失败记录是否集中出现，再决定是继续补跑还是先排查任务本身。只有把结果集、日志和站点清单三者对齐后，覆盖范围才适合作为后续分析的基础。
