网站综合查询：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /167ae999a63e.html
📄
网站综合查询：一次全站扫描被中断后怎样判断已覆盖范围
结论先给：被中断的网站综合查询不能靠“进度条走到哪”判断覆盖范围，只能靠一份可核对的已抓取清单。如果工具本身没有留下逐条记录，那么任何“大概扫了七八成”的说法都不成立，此时正确动作是缩小范围重扫，而不是补扫剩余部分。下面说清哪些证据能用、什么情况会让判断失效，以及中断后第一步该做什么。
先分清“扫描中断”到底断在哪一层
网站综合查询通常串起几个环节：发现链接、请求页面、解析内容、写入结果。中断可能发生在任意一层，而不同层留下的证据完全不同。
- 发现层中断：待抓队列还没建完。此时已抓列表可能很少，但漏掉的未必是“剩下的”，因为队列本身就不完整。
- 请求层中断：队列完整，只是部分页面没发出请求。这种情况下已抓列表能较可靠地反映覆盖，缺口就是未完成的部分。
- 解析或写入层中断：页面抓到了，但结果没落盘。这时已抓列表会低估覆盖，实际抓取量大于可见结果。
判断覆盖范围前，先确认断在哪一层。只看“已抓多少条”而不看队列是否完整，很容易把发现层的问题误读成请求层的问题。
可核对的证据只有三类
中断后想判断覆盖，需要能相互印证的材料，而不是单一数字。
- 已抓 URL 清单：逐条可导出、可去重、带状态码。这是最硬的证据。没有它，覆盖判断基本无从谈起。
- 待抓队列快照：中断瞬间还剩哪些 URL 未处理。它决定“缺口”是否是真实缺口。
- 站点自身的 URL 来源：站点地图、栏目页、内链列表。用它反推总量，再和已抓清单做差集。
把这三者交叉比对，才能得出有条件的覆盖结论。假设某站点地图列出 1200 条 URL，已抓清单去重后 800 条，待抓队列快照剩 350 条，三者大致能对上，说明缺口约 400 条且位置可定位。若队列快照缺失，800 这个数字只能说明“至少抓了 800”，不能说明“还差多少”。
一个会让结论失效的反例
即使拿到了已抓清单和队列快照，有一种情况会让“覆盖 = 已抓 / 总量”彻底失真：站点存在大量由脚本动态生成、或依赖会话状态才出现的 URL。
这类 URL 往往不在站点地图里，也不在静态内链中。网站综合查询如果只按静态来源建立队列，那么“总量”本身就是低估的，算出来的覆盖率会虚高。反过来，如果工具把带参数的筛选链接、分页参数、会话 ID 都当成独立 URL 收进队列，总量又会虚高，覆盖率被压低。
所以看到覆盖率数字时，先问一句：分母是怎么来的。分母不可信，比值就没有决策价值。此时更稳妥的做法是放弃百分比，改为按栏目或按模板抽样核对——每个主要模板抽若干条，确认是否被抓到，用“模板级覆盖”代替“全站百分比”。
中断后第一步该做什么
不要直接点“继续”。先做一次小范围重扫，用结果验证判断。
具体动作：从待抓队列快照里取一小段 URL，单独重扫，把新结果与中断前的已抓清单做差集。
- 如果差集为空，说明中断前的写入是完整的，补扫剩余队列即可。
- 如果差集里出现本该已抓的 URL，说明写入层可能丢数据，已抓清单不可信，应整体重扫。
- 如果重扫又中断在同一位置，说明问题可能出在某个具体页面或请求模式上，先隔离这类 URL 再决定范围。
这个小样本的结果直接决定下一步：是补扫、整体重扫，还是先修请求问题。跳过这一步直接放量，很可能把一次可解释的中断变成一份不可信的全量结果。
把覆盖判断写成可复核的记录
为了下次中断时能快速判断，扫描前就应约定记录格式：每条 URL 带状态、时间、来源（站点地图 / 内链 / 队列）。中断后按来源分组统计，就能看出缺口集中在哪一类来源上。
需要核对的工具行为包括：是否导出逐条清单、是否保留队列快照、是否区分“未请求”和“已请求未解析”。这些具体能力因工具而异，使用前应以实际界面和文档为准，不要凭名称假设。
覆盖范围不是一个能凭感觉回答的问题。它取决于队列是否完整、清单是否可信、分母是否成立。三者缺一，结论就只能降级为“部分覆盖，缺口待定”，并据此选择重扫范围。
