站长实用软件，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b09f8bed3072.html
📄
站长实用软件，一次全站扫描被中断后怎样判断已覆盖范围
中断后不要直接重跑，也不要凭“扫到一半”就认定覆盖了约一半。更可靠的做法是：先看扫描器有没有留下可续跑的进度记录，再用少量已知状态的URL做抽样复核，最后决定是保留已有结果、改写扫描参数后续跑，还是退出这次任务重新规划。若扫描器没有断点记录，已覆盖范围通常只能通过抽样推断，不能精确还原。
先分清中断发生在哪一层
全站扫描一般至少涉及三层：待扫URL队列、已抓取页面内容、已写入的结果库。中断可能只打断其中一层。例如队列还在内存里但结果已落盘，或者结果写了一半而队列丢失。判断覆盖范围前，先确认这次扫描是否把进度持久化到了磁盘或数据库。
- 有持久化队列：可以查看剩余待处理条目，覆盖范围较容易界定。
- 只有结果输出：能知道哪些URL已处理，但无法知道原计划总量，覆盖比例只能估算。
- 两者都没有：只能重新扫描，已覆盖范围无法可靠判断。
这一步的实际动作是打开扫描器的工作目录或任务记录，查找队列文件、日志、断点标记或数据库中的任务表。若找到待处理清单，下一步就应对比“已处理数 + 待处理数”是否接近预期总量；若差距很大，说明中断前可能已丢失部分队列，续跑会漏掉中间段。
用已知样本反推覆盖边界
当没有完整队列时，抽样是最实际的判断方法。准备一小批你明确知道状态的URL，例如首页、栏目页、若干详情页，以及一个已知会返回404或跳转的地址。重新用同一扫描器只扫这批样本，观察它们是否出现在上次结果中。
假设上次扫描中断前处理到第800条，你抽10个样本，其中6个在结果里、4个不在，且不在的样本恰好集中在某个目录下。这只能说明该目录可能未被覆盖，不能直接推出“覆盖了60%”。因为样本不是随机抽取，且中断可能发生在写入阶段而非抓取阶段。更稳妥的做法是把样本按站点结构分层：首页与一级栏目、深层列表页、分页参数页、静态资源各取几个，分别核对。
如果抽样发现结果库里存在大量重复URL或空记录，说明写入过程可能不稳定，此时保留已有结果的风险较高。反之，若结果记录完整、字段齐全、时间戳连续，保留并续跑更划算。
保留、改写还是退出：三种取舍的适用前提
保留并续跑适用于扫描器支持断点续传，且结果库中的记录没有明显损坏。动作是导入剩余队列或从最后一个成功标记继续。结果是省去重复抓取，但需要接受一个前提：中断期间站点内容可能已变化，旧结果与新结果会混在一起。若站点更新频繁，续跑后的数据一致性会下降。
改写参数后重跑适用于队列丢失但结果可用，且你只关心部分目录。动作是缩小扫描范围，例如只扫栏目页和详情页，跳过标签页、分页和静态资源。结果是覆盖范围更清晰，代价是放弃全站完整性。若你的目标是检查死链或抓取异常，缩小范围往往比追求全量更实际。
退出并重新规划适用于结果库损坏、队列无法恢复，或中断原因本身是资源耗尽、被目标站限流。动作是先解决限流或超时设置，再重新设计分批任务。结果是这次扫描的已有数据不再作为决策依据，但避免了在不可靠数据上继续叠加。
判断结果能否用于下一步的检查点
在决定保留之前，至少核对三件事：已处理URL是否包含站点主要目录；结果中的状态码分布是否合理，例如大量200中夹杂少量404属于正常，若几乎全是超时或403则说明中断前已受限；日志中是否有写入失败或队列溢出的记录。若这三项中有两项异常，保留已有结果的意义不大。
另外要注意，扫描中断后“请求量归零”或“抓取速度下降”并不单独证明任务已停止，也可能是目标站响应变慢、本地网络波动或扫描器进入等待重试。把这些现象与队列状态、日志时间戳一起看，才能区分是中断还是暂时停滞。
最终选择取决于你对数据完整性的要求：用于发现少量死链，抽样加续跑通常够用；用于生成站点结构报告或迁移清单，则应在确认队列完整后再继续，否则宁可重跑。无论选哪种，都先把这次中断的日志和队列文件另存一份，避免后续操作覆盖掉判断依据。
