站长工具网站，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /post/45730439.html
📄
站长工具网站，一次全站扫描被中断后怎样判断已覆盖范围
判断依据不是“扫了多久”，而是扫描器有没有留下可核对的进度记录。如果工具按队列逐条抓取并实时写入结果，中断点之后仍有断点续扫的余地；如果结果只在任务结束时统一生成，中断后基本无法还原覆盖范围，只能重扫。先确认这一点，再决定是接着扫还是从头来。
先分清两种扫描器：流式落盘还是批式汇总
这是决定后续所有动作的前提。流式落盘指每抓完一个页面就写入结果表或日志，任务中断后已写入的部分仍然存在；批式汇总指结果在内存中累积，任务完成才统一输出，中断即全部丢失。
区分方法很直接：中断后去结果列表看有没有数据。有部分数据，且条目数与耗时大致成比例，倾向流式；结果为空或只有一条汇总错误，倾向批式。另一种证据是日志文件——如果日志里有逐条URL的记录，即使界面不显示，也能还原覆盖范围。
需要留意的例外：有些工具虽然逐条写入，但写入的是缓冲区，进程被杀时缓冲未刷盘，看起来像批式。这时看日志最后一条的时间戳与中断时刻是否接近，差得越远，丢失的尾部越多。
用已产出的URL清单反推覆盖边界
拿到部分结果后，不要直接数条数，而要把URL按路径前缀分组，观察哪些目录已经出现、哪些完全没有。例如假设某站有 /product/、/blog/、/help/ 三个主要目录，结果里只出现了前两个，那 /help/ 属于未覆盖，而不是“扫过了没问题”。
实施动作：导出已有URL，去重后按一级路径归类，统计每类的数量。结果如何影响下一步——如果缺失的目录恰好是你最关心的部分，续扫的起点应设为该目录，而不是简单接着上次的时间点；如果缺失的只是权重低的栏目，可以接受当前覆盖度，先分析已有数据。
这个方法的适用条件是站点结构清晰、URL有规律。如果URL是无意义ID或参数拼接，按前缀分组会失效，此时改用站点地图作为对照基准，逐条比对哪些条目已出现在结果中。
把“谁认为扫完了”变成可核对的项目
多角色协作时，分歧往往出在“覆盖”的定义上。运营认为首页和主要栏目扫到就算完成，技术认为必须包含所有分页和参数页。与其争论，不如把口径写成一张对照表：
- 必扫项：首页、栏目页、详情页模板各一个代表URL
- 选扫项：分页、筛选参数、标签聚合页
- 排除项：后台、登录、测试目录
然后拿这张表对照已有结果，逐项标记“已覆盖”“未覆盖”“不确定”。不确定的项单独列出，用单页抓取验证，而不是靠推测。这样分歧就转化为一张状态表，谁都能核对。
例外情况：如果扫描器本身不区分必扫和选扫，抓取顺序随机，那对照表只能用于事后评估，不能用来指导续扫起点。此时更实际的做法是重扫并只保留必扫项，牺牲选扫项的完整度换取确定性。
续扫前的验证动作与结果判断
决定续扫后，先做一次小范围试探：选一个已知未覆盖的URL，单独抓取，确认工具能正常返回结果。如果这一步就失败，说明问题不在覆盖范围，而在工具状态或目标站点的访问限制，续扫没有意义。
试探成功后，把续扫起点设为未覆盖目录的入口，而不是上次中断的URL。原因是中断点附近的页面可能已经写入但未确认，从入口重扫会产生少量重复，但能避免遗漏，重复条目在后续去重时处理即可。
结果如何影响下一步：续扫完成后，把新结果与旧结果合并去重，再按前面的对照表复查一遍。如果仍有“不确定”项，说明该工具对这类URL支持有限，需要换用单页检测逐个确认，而不是再扫一次全站。
这些现象不能单独证明覆盖正确
抓取量归零、耗时突然变短、结果条数正好等于站点地图条目数，都不足以说明覆盖完整。抓取量归零可能是被限流，耗时变短可能是提前退出，条数吻合可能是站点地图本身就不全。要交叉验证：至少用站点地图、内链抽样、日志三种来源中的两种来对照结果。
如果只有一种来源可用，就在结论里注明覆盖判断的置信度较低，后续分析时对缺失部分保持保留态度。这比默认“扫过了就是全的”更稳妥，也避免把覆盖缺口误当成站点问题。
