搜索引擎营销工具，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e4682144e4c4.html
📄
搜索引擎营销工具，一次全站扫描被中断后怎样判断已覆盖范围
判断已覆盖范围，不能只看工具显示的进度条或已扫数量，而要回到扫描日志与任务清单，把“已处理”“已提交”“已完成”三件事分开核对。中断时点之后重新发起扫描，最容易把重复覆盖误当成完整覆盖，所以先确认断点位置，再决定是续扫、补扫还是从头重扫。
先分清三种“扫过”的含义
扫描类任务通常会产生三类记录：任务已经取到该地址、工具已经发出请求、结果已经写入本地或远端存储。中断发生时，这三类记录的数量往往不一致。若只看到“已取到”数量接近全站总数，就认定覆盖完成，后续很可能出现大量地址没有实际结果。
核对时按下面顺序做：
- 找到中断前最后一次成功写入的时间戳，而不是最后一次发出请求的时间。
- 把该时间戳之前的任务清单导出，与全站地址清单做差集，差集就是明确未覆盖部分。
- 对时间戳附近的一小段地址做抽样复核，确认这些地址是“已请求未写入”还是“根本未请求”。
这一步的产出不是覆盖率数字，而是一份带状态的地址清单。它决定下一步动作：如果未写入集中在断点附近，续扫通常够用；如果未请求部分分散在全站，说明中断前任务分发本身就不完整，续扫会留下空洞。
假设情境：一次中断后的三种判断结果
假设某站点共一万个地址，扫描在第六千个附近中断。导出日志后发现：已成功写入五千二百条，已发出请求但无结果的有六百条，剩余四千二百条没有请求记录。此时不能简单认为“已覆盖六千”。
按不同证据，处理方式不同：
- 证据一：无结果请求集中在断点前后。说明中断只影响了一个短时间段，续扫并补扫这六百条即可，不必全站重来。
- 证据二：无结果请求分散在多个时间段。说明这些地址可能因超时、限流或解析失败被跳过，与中断无关。此时即使续扫完成，这些地址仍会缺失，需要单独列出重试。
- 证据三：未请求的四千二百条中包含大量重要栏目页。说明任务分发顺序可能把重要地址排在后面，中断恰好切在关键部分之前。这种情况下应调整扫描顺序，把核心地址前置，再决定是否全量重扫。
这三种结果指向的动作不同，所以中断后的第一件事不是点“继续”，而是先看未覆盖部分的分布形态。
用断点标记和清单差集确认边界
多数工具在中断时会留下断点标记或检查点文件，但标记位置不一定等于真实覆盖边界。可靠做法是同时保留两份材料：一份是工具自己的断点记录，一份是外部维护的地址清单。两者交叉比对后，取交集作为已确认覆盖，取差集作为待处理范围。
具体动作可以这样执行：
- 导出中断前的任务记录，按状态字段分组计数。
- 把状态为成功的地址写入一个临时清单，作为已覆盖基线。
- 用全站地址清单减去该基线，得到待覆盖清单。
- 对待覆盖清单按地址类型或栏目分组，观察缺失是否集中在某类页面。
这个动作的结果直接影响下一步：如果待覆盖清单里核心页面占比高，就应先补扫核心页面并单独验收；如果缺失主要是低价值或重复参数地址，可以合并去重后再扫，避免把时间花在重复请求上。
续扫之前要确认的两个前提
续扫成立需要两个条件同时满足：中断原因已经排除，且断点记录与实际写入边界一致。若中断原因是限流或网络波动，而断点记录又只记录了请求位置，那么续扫可能从错误位置开始，造成一段地址被重复请求、另一段被彻底跳过。
核对前提时，可以抽查断点前后各一小段地址，确认它们的结果是否都已写入。抽查结果若显示断点前有缺口，说明断点记录不可信，应放弃续扫，改用清单差集方式重新组织任务。这个判断不需要全量重跑，只需要在断点附近做小范围验证。
另一个前提是地址清单本身没有在中断期间发生变化。如果站点在扫描中断后新增或删除了页面，旧清单与新清单的差集就不能直接当作未覆盖范围，需要先固定一份扫描基准清单，再开始补扫。
把覆盖判断转成可验收的补扫任务
补扫任务要带明确的验收条件，否则第二次中断后又会回到同样的问题。验收条件至少包括：待覆盖地址清单、每类地址的预期结果字段、以及允许失败重试的次数上限。这样即使再次中断，也能用同一份清单继续比对，而不是重新猜覆盖范围。
假设补扫完成后，待覆盖清单中仍有少量地址没有结果。此时不要直接认定工具失效，先区分合理解释：地址本身返回错误、地址需要登录态、地址被规则排除、或工具在该类地址上存在已知限制。区分清楚后再决定是调整规则、补充凭据，还是把这类地址移出本次任务范围。覆盖范围是否可信，取决于这些解释有没有被逐条排除，而不是取决于一个百分比。
