爱站SEO查询一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0e865bbb49e8.html
📄
爱站SEO查询一次全站扫描被中断后怎样判断已覆盖范围
扫描中断后，不要用“已扫到多少条”直接当覆盖率。更可靠的做法是先判断中断发生在哪一类页面边界，再用可复现的小样本反推：如果中断点前后的页面类型、层级和链接深度差异很大，已覆盖范围往往只对某一类页面成立，不能直接外推到全站。
先分清两种中断：任务停了，还是数据没落盘
同一个“中断”现象，可能对应两种完全不同的覆盖状态。
- 解释一：采集确实停了。扫描进程被终止或超时，未访问的链接仍在队列里，已产出的记录对应真实抓取过的页面。此时覆盖范围大致等于“已完成队列 + 已写入结果”，缺口在队列尾部。
- 解释二：采集还在跑，只是结果没落盘。进程被中断时缓冲区未刷写，或导出动作只完成了一部分，那么已抓取的页面数可能大于已保存的记录数。此时按结果文件判断覆盖，会系统性低估。
这两种情况的处理方向相反：前者要补抓队列，后者要补导出而未必重抓。分不清就重跑，可能白花一遍时间。
用三个证据区分是停采还是丢数据
能区分上述解释的证据，通常来自扫描过程本身留下的痕迹，而不是结果条数。
- 时间戳的分布。如果最后若干条记录的时间戳密集且连续，之后突然归零，更像进程被终止；如果时间戳一直均匀分布到最后，但条数明显偏少，更像写入或导出不完整。
- 队列或日志的残留状态。多数扫描工具会留下待访问队列或运行日志。队列仍有大量未处理项，说明是停采；队列接近清空但结果偏少，说明问题更可能在落盘环节。
- 已知页面的命中情况。挑几个确定存在、且位于不同层级的页面，检查它们是否出现在结果里。若浅层页面大量缺失，说明覆盖连基础层都没走完；若浅层齐全、深层缺失，缺口集中在链接深度。
注意：时间戳归零或条数偏少本身不能单独证明某种解释，它也可能来自过滤规则、去重或权限拦截。要结合队列状态一起看。
用分层抽样估算覆盖，而不是数总数
中断后最有用的判断，是按页面类型分层估算，而不是给一个全站百分比。
假设一次扫描在约四成进度时中断，结果里首页和栏目页基本齐全，但文章详情页只覆盖了前几页列表。此时“已覆盖约四成”这个说法会误导：对栏目层可能已接近完整，对详情层却远未覆盖。可行的动作是：
- 先按层级或模板把已知页面分成几组，例如首页、列表页、详情页、分页。
- 每组各抽少量确定存在的页面，检查是否在结果中。
- 记录每组的命中比例，而不是合并成一个总数。
这样得到的结论会直接改变下一步：如果缺口集中在详情页，补抓时应优先恢复列表翻页与深层链接；如果缺口在各层都均匀出现，更可能是整体停采，需要从队列断点续跑。
什么情况下这套判断不成立
分层估算依赖一个前提：你能拿到相对完整的已知页面清单，或至少能按模板抽样。如果站点本身结构混乱、大量页面只能通过站内搜索或动态参数到达，抽样命中率低并不能说明扫描有问题，可能只是入口本身不可枚举。
另外，若扫描工具在中断时没有留下队列或日志，只留下一个结果文件，那么区分“停采”和“丢数据”的证据就不足。此时更稳妥的做法是把这次结果标记为不完整，仅用于观察已覆盖部分的特征，不用于得出全站结论。
对具体工具而言，是否保留断点、日志位置和导出机制各不相同，需要以你实际使用的版本和界面为准核对，不能照搬其他工具的恢复方式。
把结论写成可复核的记录
判断完成后，建议留下三样东西：中断时的进度描述、分层命中比例、以及你据此选择的下一步动作。这样即使换人接手，也能看出“已覆盖范围”是在什么条件下得出的。缺少这些条件，一个孤立的覆盖数字很容易被当成全站结论使用，而它其实只对某一层页面成立。
