站长辅助工具一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /271e0391cd1c.html
📄
站长辅助工具一次全站扫描被中断后怎样判断已覆盖范围
扫描被中断后，不要凭“进度条停在哪”判断覆盖范围，而要以工具已经落盘的结果清单为准：先确认有没有导出或可查看的中间结果，再按URL清单反推覆盖边界。如果没有任何可导出的中间结果，这次扫描应视为未覆盖，重新规划分段任务；如果有部分结果，则先做去重与状态标记，只对未覆盖区间补扫。这个判断直接决定你是补扫、重扫还是改用分段扫描。
先确认中断时结果是否已经落盘
扫描类工具在运行中通常有两种状态：内存中的待处理队列，以及已经写入结果表或导出文件的记录。中断后，内存队列基本丢失，能利用的只有已落盘部分。你需要做的第一个动作，是找到结果导出入口或历史任务记录，看这次任务有没有生成可下载、可筛选的结果。
- 如果结果可导出：以导出文件为覆盖证据，不要以界面进度为准。
- 如果只有汇总数字、没有逐条URL：覆盖范围不可核对，按未覆盖处理。
- 如果结果只存在页面列表里、无法批量导出：先手动抽样几条，确认这些记录是否带完整URL和状态字段，再决定是否值得逐页整理。
这一步的结果会直接影响下一步：有逐条URL，才可以做区间补扫；只有汇总数字，补扫无法避免重复，只能整体重来或改成分段任务。
用URL清单反推覆盖边界，而不是靠进度百分比
进度百分比只说明任务执行到哪一步，不说明哪些URL已经处理完成。真正可用的边界来自结果清单本身。把导出的URL按站点结构或字母顺序排列，找出连续覆盖的区间和明显缺口，就能得到一份“已覆盖清单”和“待覆盖清单”。
假设某站点有A、B、C三个栏目，扫描中断后导出结果里A栏目URL完整、B栏目只覆盖前半部分、C栏目一条都没有。此时合理的做法不是从头重扫，而是只补B栏目剩余部分和整个C栏目。这个例子的数字只为说明比较方法，不代表任何真实任务的覆盖比例。
需要注意，URL清单里出现某条记录，只能说明它被处理过，不一定说明结果有效。若工具把超时、跳转、被拒绝访问也写进清单，你需要按状态字段再筛一遍，避免把失败记录当成已覆盖。
区分三种中断原因，决定补扫还是重扫
不同中断原因对应不同的覆盖可信度。判断依据不是中断提示文字，而是结果清单的完整程度和任务配置是否变化。
- 任务被手动停止或超时中断：已落盘部分通常可用，适合按URL区间补扫。
- 工具崩溃或进程被杀：最后一批写入结果可能不完整，需要检查结果文件末尾是否有截断，必要时把最后一段区间划入补扫范围。
- 站点侧限制导致大量请求失败：此时已覆盖范围可能包含大量无效结果，补扫前应先调整请求节奏或分段规模，否则补扫仍会失败。
如果任务配置在中断前后发生了变化，比如改变了抓取深度、过滤规则或URL匹配方式，那么新旧结果不能直接拼在一起。此时要么统一配置后重扫，要么把两次结果分开保存，分别标注配置版本。
把判断结果转成可执行的补扫方案
完成覆盖判断后，动作应当落到一份明确的待处理清单上，而不是重新点一次“开始扫描”。具体可以按以下顺序执行：
- 导出已覆盖URL，去重后保存为基准清单。
- 从站点地图、栏目列表或历史日志中取得完整URL集合，与基准清单做差集。
- 对差集按数量分段，每段单独建任务，避免再次因规模过大而中断。
- 补扫完成后，把新结果与基准清单合并，再统一做状态筛选。
这个流程的关键在于：补扫对象是差集，不是全站。只要差集计算正确，补扫量通常远小于重扫量。反过来，如果无法取得完整URL集合，差集就不可靠，此时分段重扫比盲目补扫更稳妥。
哪些情况下应当直接放弃本次结果
有些中断场景下，继续利用部分结果反而会增加后续判断成本。出现以下条件时，建议把本次扫描视为无效：结果无法导出逐条URL；中断前任务配置已被修改且无法还原；结果清单中失败状态占比过高且无法区分失败与成功；或者你无法确认结果对应的是哪个站点版本。此时重新建立一份范围明确、分段可控的任务，比修补旧结果更省事。
判断标准始终是同一条：你能否用现有材料列出一份可信的已覆盖URL清单。能列出，就补扫；列不出，就重扫。这个决定做完之后，再考虑扫描频率、并发数或过滤规则是否要调整，顺序不要颠倒。
