旺格子优化软件，全站扫描中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /99ce43d47c5f.html
📄
旺格子优化软件，全站扫描中断后怎样判断已覆盖范围
先看扫描是否留下了可续跑的进度记录。如果软件把已抓取地址、时间戳和状态写进了本地数据库或日志，你可以据此重建覆盖范围；如果中断后只留下一个笼统的完成百分比，就必须改用抽样复核来估算，不能把百分比当作已覆盖比例。
条件一：有可读的进度记录时，按记录重建覆盖范围
判断依据不是界面上显示的进度条，而是记录里是否存在逐条地址及其处理状态。可用的记录通常包含三类字段：地址、处理时间、处理结果（成功、失败、跳过）。只要这三类字段齐全，中断位置就能被定位。
实际操作可以分三步。第一，导出中断前的记录，按处理时间排序，找出最后一条成功记录的时间点。第二，统计该时间点之前的去重地址数，与站点已知的地址总量对比，得到已覆盖比例。第三，检查失败和跳过状态的条目，它们虽然被扫描过，但结果不可用，是否计入覆盖范围取决于你的目标：如果目标是发现可优化页面，失败项应视为未覆盖。
这一步的结果会直接决定下一步：如果已覆盖比例较高且失败项集中在少数目录，续跑时只需补扫这些目录；如果记录缺失严重，续跑成本可能接近重扫。
条件二：只有汇总百分比时，用分层抽样估算覆盖
假设软件中断后只显示“已完成 62%”，没有任何逐条记录。这个数字可能按地址数计算，也可能按目录数、任务批次或预估总量计算，不同口径下含义完全不同，因此不能直接采信。
可行的做法是按站点结构分层抽样。把站点按目录或栏目分成若干组，从每组中随机抽取一定数量的地址，逐个检查它们在中断前是否已被处理。如果某组抽样地址大多已有处理痕迹，说明该组覆盖较完整；如果某组几乎找不到痕迹，说明该组大概率未被覆盖。
举例说明：假设站点有五个主要栏目，每个栏目抽十条地址，其中四个栏目各有八条以上已有处理痕迹，一个栏目只有一条。那么可以判断前四个栏目覆盖较充分，最后一个栏目需要优先补扫。这里的数字仅用于说明比较方法，不代表任何真实工具的统计结果。
抽样的局限也要说清：样本量太小时，个别栏目可能被误判；站点各栏目地址量差异很大时，按栏目等量抽样会高估小栏目的权重。遇到这种情况，应按地址量比例分配样本，或在补扫时对所有栏目做一轮轻量核对。
中断本身不能证明处理正确，也不能证明处理错误
扫描中断后，请求量下降或抓取日志停止增长，只能说明进程停了，不能说明已处理部分的结果是对的。同样，恢复后请求量回升，也不代表覆盖范围被正确接续。判断覆盖范围和处理质量是两件事，前者看记录和抽样，后者需要另外检查响应状态、内容解析是否正常。
一个常见的误判是：看到失败率很低就认为覆盖良好。失败率低可能只是因为大量地址被标记为“跳过”而非“失败”，跳过项同样没有产出可用结果。核对时要把跳过、超时、重复地址单独统计，而不是只看失败数。
续跑前先确定边界，再决定补扫还是重扫
选择补扫还是重扫，取决于两个可核实的条件。条件一：中断前的记录能否准确还原已处理地址集合。条件二：站点地址总量在中断期间是否发生了明显变化，例如新增了大量页面或删除了旧栏目。
如果记录完整且站点结构稳定，补扫是更省成本的选择，只需处理未覆盖和失败的部分。如果记录不完整，或者中断期间站点有大量新增地址，补扫容易出现重复处理和遗漏并存的情况，此时重扫更可控，但耗时更长。
无论选哪种，建议在续跑前做一次小范围试跑，取一个已知未覆盖的目录，观察新记录能否与旧记录正确合并。如果合并后出现重复条目或状态冲突，说明续跑逻辑需要先修正，否则覆盖范围的判断会再次失真。具体到你所用的工具，记录格式、导出方式和续跑入口需要以实际界面为准，不同版本可能存在差异。
