SEO点击工具：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ecbdff770216.html
📄
SEO点击工具：一次全站扫描被中断后怎样判断已覆盖范围
先别重跑整站。把中断当成一次不完整采样，用已有日志和结果文件划出三块：已确认覆盖、疑似覆盖、未覆盖。判断依据不是扫描进度百分比，而是每个URL是否同时留下“请求记录”和“结果记录”。只有请求没有结果，说明抓取或解析中断；只有结果没有请求，说明数据来自缓存或旧批次。接下来按这三块决定补扫范围，而不是从零开始。
先固定判断口径：什么算“已覆盖”
打开中断后留下的原始文件，通常包括请求日志、结果明细和错误列表。对每一条URL分别标记两个字段：是否发出请求、是否产出可用结果。两者都为真，才算已覆盖；请求为真、结果为假，归入疑似覆盖；请求为假，归入未覆盖。
这个口径的价值在于，它不依赖工具自己显示的完成度。进度条可能按提交任务数计算，也可能按已排队数计算，中断后往往停在某个中间值，不能直接换算成覆盖比例。你要的是可核对的URL清单，而不是一个百分比。
如果结果文件里带有时间戳或批次号，先按批次拆分。跨批次混在一起看，容易把上一轮的旧结果误当成这一轮的覆盖。
用三类证据区分“真覆盖”和“假覆盖”
疑似覆盖里最常见的是解析失败和超时。它们的共同点是请求已经发出，但结果不可用。处理方式不是简单重试，而是先看错误类型：
- 连接类错误：目标站点拒绝或中断连接。这类URL应归入未覆盖，因为本轮没有拿到任何有效数据。
- 解析类错误：页面取回了，但工具没能提取出需要的字段。应归入疑似覆盖，补扫时可以只重跑解析，不必重新请求。
- 超时类错误：请求发出但未在限定时间内返回。需要看该URL在日志里的尝试次数，若已多次超时，先排查是目标站点限速还是工具并发设置过高。
还有一种假覆盖：结果文件里的URL数量看起来完整，但字段大面积为空。这通常说明请求成功、解析规则不匹配，属于疑似覆盖，不能算已覆盖。
把已覆盖范围落到一张可执行的补扫清单
假设你手上有1000条URL的扫描任务，中断后日志显示620条有请求记录，其中540条同时有结果记录，80条只有请求没有结果；剩余380条没有请求记录。按上面的口径，已覆盖540条，疑似覆盖80条，未覆盖380条。
补扫清单这样排：
- 先处理80条疑似覆盖。若错误以解析为主，只重跑解析；若以连接或超时为主，调整并发或请求间隔后重跑请求。
- 再处理380条未覆盖。按URL优先级排序，例如先补重要栏目页和转化页，再补列表页和归档页。
- 已覆盖的540条本轮不重跑，除非你发现解析规则在中断前后发生过变化。
这个动作会直接影响下一步：如果疑似覆盖里解析错误占比高，说明问题在规则不在网络，补扫成本低；如果连接和超时占比高，说明瓶颈在请求侧，先降并发比直接重跑更省时间。
中断后不要直接重跑整站的两个条件
是否重跑整站，取决于两个可观察条件，而不是感觉。
条件一：已覆盖结果的时效性。如果中断发生在数小时前，且目标站点在这段时间内没有批量更新，已覆盖部分可以沿用。如果站点在此期间发布了大量新页面或改了URL结构，已覆盖部分也可能过期，需要重新评估。
条件二：解析规则是否稳定。如果中断前后使用的是同一套解析规则，已覆盖结果可以复用；如果中途改过字段映射或选择器，已覆盖结果和补扫结果可能不是同一口径，混在一起会误导后续判断。
两个条件都满足时，补扫未覆盖和疑似覆盖即可。任一条件不满足，才考虑重跑，并且重跑前先固定规则版本，避免再次出现口径不一致。
把覆盖判断变成下一次扫描的前置检查
这次中断暴露的其实是扫描过程缺少断点标记。下一次启动前，可以做三件小事：让日志按URL逐条落盘，而不是只在结束时汇总；给结果文件保留批次号和时间戳；把错误类型单独存一份，不要和成功结果混在同一个文件里。
这样做的结果不是让扫描一定不中断，而是中断后你能在一张表里直接看出哪些URL需要补、补哪一步。覆盖范围判断从“猜进度”变成“对清单”，补扫范围也就有了明确边界。
