网站排名软件，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8819f9ee6d5f.html
📄
网站排名软件，一次全站扫描被中断后怎样判断已覆盖范围
中断后不要先看软件给出的“已完成百分比”，而要先找回扫描日志或任务记录，按URL清单、状态码、抓取时间三项核对实际落盘的数据。判断覆盖范围的核心依据是“已产出结果的对象集合”，不是软件界面的进度条，因为进度条在中断时往往只反映最后一个批次，不能代表全站。
先确认中断发生在哪一层
同一款网站排名软件，中断可能发生在三个不同层面：任务调度层、抓取请求层、结果写入层。三者的已覆盖范围差别很大。
- 调度层中断：任务队列里还有未派发的URL，已派发的可能已完成，也可能悬空。
- 请求层中断：部分URL已发出请求但未收到响应，这部分状态未知，不能算已覆盖。
- 写入层中断：请求已完成但结果未落盘，表面看是失败，实际数据可能仍在临时文件里。
判断方法很直接：打开软件的日志目录或导出文件，找最后一条成功写入记录的URL和对应时间戳。如果日志按批次编号，检查最后一个完整批次的下标，而不是最后一个不完整批次。这一步决定了你后面是“续扫”还是“重扫”。
用三份清单做差集，而不是相信百分比
假设你手上有三个东西：扫描前准备的URL清单A、软件已导出结果清单B、软件日志里标记为失败的清单C。已覆盖范围约等于B减去C中状态未知的部分，未覆盖范围约等于A减去B。
实际操作时，把A和B都导出为每行一个URL的纯文本，用命令行做差集：
comm -23 <(sort A.txt) <(sort B.txt) > missing.txt
结果missing.txt就是尚未产出结果的URL。这个动作的价值在于：它把“覆盖了多少”这个模糊问题，变成“还差哪些具体URL”这个可执行问题。下一步直接拿missing.txt去续扫，而不是整站重跑。
需要注意的边界：如果软件在抓取时对URL做了规范化（去参数、统一大小写、跟随跳转），那么A和B的URL形态可能不一致，直接做差集会误判。此时应先用同一套规范化规则处理A，或者改用“规范化后的唯一键”做比对。
个别样本成立不代表全站结论成立
中断后常见的一个误判是：抽查几个已完成的页面，发现数据正常，就认为整体覆盖可靠。这在规模化后会出问题，原因是中断往往不是均匀发生的。
可能的原因包括：
- 某类URL（如带分页参数的列表页）响应慢，集中卡在队列尾部，恰好是未覆盖部分。
- 某目录下页面触发了限流，软件跳过后继续处理其他目录，导致覆盖出现空洞。
- 结果写入时按域名或目录分批提交，中断点之后整批丢失。
要区分这些情况，可以按目录或URL类型分组统计B的分布，看是否存在整段缺失。如果缺失呈连续区块，更可能是限流或分批写入导致；如果缺失随机分散，更可能是单点超时。这个判断影响下一步：连续缺失适合按分组续扫并调低并发，随机缺失适合直接补扫缺失清单。
决定续扫还是重扫的取舍条件
续扫成立的条件：日志能明确给出最后成功写入的位置，且软件支持指定URL清单重新入队。续扫的代价是两次扫描的时间差可能让部分页面的数据版本不一致，如果排名数据对时效敏感，需要记录两次扫描的时间窗口。
重扫成立的条件：中断原因不明、日志不完整、或软件不支持按清单续扫。重扫的代价是重复消耗请求额度，且可能再次触发同样的中断。如果中断由限流引起，重扫前应先降低并发或延长间隔，否则会重复失败。
一个假设例子：某次扫描计划覆盖5000个URL，中断时导出结果有3200条。若日志显示最后成功批次覆盖到第3200条且顺序连续，续扫剩余1800条即可；若日志显示成功记录分散在第1到第5000条之间且无明确断点，则应按missing.txt补扫，而不是从第3200条往后扫。两种做法的差别在于，后者可能漏掉断点之前的空洞。
把结论转成下一次的检查动作
无论续扫还是重扫，完成后应做一次覆盖校验：用同一套差集方法确认A中每个URL都能在结果清单中找到对应记录，并记录状态码分布。如果仍有缺失，先看这些缺失URL是否属于同一类（同一目录、同一参数模式、同一响应时间区间），再决定是调整软件配置还是手工处理。
最后提醒一点：抓取量归零或进度停滞，不能单独证明扫描已经完成或已经失败。它也可能是软件在等待响应、在写入大文件、或被目标站点限流。判断覆盖范围始终要回到“结果清单里有没有这条URL的记录”，而不是界面上显示了什么。
