站长必备工具：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3e0cfe7fe2b1.html
📄
站长必备工具：一次全站扫描被中断后怎样判断已覆盖范围
先看扫描器在中断前有没有留下可核对的进度记录，再看已扫部分是否与站点实际结构对得上。只凭“扫了多少条”或“还剩多少条”都不足以判断覆盖范围，因为中断可能发生在抓取、解析或写库中的任意一步。
为什么样本看起来正常，规模化后却出现例外
小范围试扫时，工具往往先处理首页、栏目页和少量详情页，这些页面通常结构规整、内链充足。样本看起来正常，并不代表全站扫描中断后已覆盖范围也正常。规模变大后，容易出现三类例外：分页或筛选参数生成大量近似 URL，部分目录没有入口链接，个别页面响应慢导致队列提前耗尽。此时“已扫描数量”可能只覆盖了容易到达的部分，漏掉的是深层页面或非典型模板页。
两种解释：是抓取中断，还是覆盖边界被误判
第一种解释是抓取中断：扫描器在请求阶段停下，队列里仍有未请求的 URL，已覆盖范围就是已成功请求并解析的部分。第二种解释是覆盖边界被误判：扫描器其实已经跑完可发现范围，但工具把超时、跳转或解析失败也计入“未覆盖”，或者把同一页面的多个参数版本当成不同页面，导致范围看起来比实际小或大。
这两种解释对应不同证据。抓取中断通常表现为进度记录停在某个批次、队列长度不为零、日志末尾有超时或连接错误。覆盖边界误判则表现为同一模板页大量重复、参数不同但正文相同、目录页存在但没有被继续展开。
用三组证据区分中断与误判
第一组：看进度记录是否可续跑
检查工具是否保存了待抓队列、已完成 URL 列表和最后处理时间。若队列文件存在且能读出未完成项，说明中断点在请求阶段，已覆盖范围应以“已完成且解析成功”的 URL 为准。若队列为空但站点仍有大量未出现页面，更可能是发现规则没有展开，而不是中断本身造成遗漏。
第二组：抽样对照站点真实结构
从站点地图、栏目分页、数据库导出或服务器访问日志中抽取若干目录，与扫描结果做对照。假设某栏目共有 50 个详情页，扫描结果只出现 12 个，且这 12 个都能从栏目首页直接到达，那么漏掉的 38 个很可能位于分页之后，属于发现范围问题。若这 12 个分布在多个批次且日志显示请求被中断，则更偏向抓取中断。
第三组：看失败类型是否集中
把失败 URL 按状态码、超时、跳转循环、解析失败分组。集中在超时或连接重置，通常指向抓取中断或目标站限速；集中在重复正文或参数变体，通常指向覆盖边界判断问题。两类原因可能同时存在，需要先处理占比更高的一类。
一个可操作的判断顺序
- 先冻结当前结果，不要立即重扫，避免新旧数据混在一起。
- 导出已完成 URL、待处理 URL 和失败 URL 三份清单，分别计数。
- 从站点地图或栏目分页中随机抽取 3 到 5 个目录，核对每个目录下已覆盖比例。
- 若某目录覆盖比例明显偏低，先检查该目录是否需要点击“下一页”或提交参数才能到达；若是，则调整发现规则后再续扫。
- 若覆盖比例正常但失败清单集中在超时，则降低并发或延长超时后续扫，并保留失败清单用于二次核对。
这个顺序的关键动作是先导出三份清单再决定是否续扫。若跳过导出直接重扫，旧结果会被覆盖，之后无法判断漏掉的是中断前未请求的页面，还是发现规则本来就没展开的页面。
哪些情况下不能直接照搬样本结论
样本扫描正常，不能直接推断全站覆盖完整。以下边界需要单独核对：分页超过工具默认深度的栏目；依赖 JavaScript 渲染后才出现链接的页面；带会话参数或排序参数的列表页；只在移动端模板中出现的入口；以及被 robots 规则或登录状态限制的目录。这些情况下，已覆盖范围应分别标注“已请求”“已解析”“已确认属于站点结构”，不能合并成一个笼统的扫描数量。
如果工具提供断点续扫，续扫前先确认它使用的是同一份队列和同一套发现规则。规则变了，续扫结果就不能与中断前结果直接合并。最终判断标准不是扫描总数，而是抽样目录的覆盖比例、失败类型分布和队列状态三者能否互相印证。
