旺道SEO：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b5cc9f2b8e94.html
📄
旺道SEO：一次全站扫描被中断后怎样判断已覆盖范围
扫描被中断后，最危险的做法是凭“跑了多久”估算覆盖了多少页面。更可靠的做法是把覆盖范围拆成可核对的清单：哪些URL被抓取过、哪些只进了队列、哪些根本没被发现。只有把这三类分开，才能判断剩余工作量，而不是重新全量跑一遍。
矛盾现象：进度条停在80%，但结果可能只覆盖一半
假设一次全站扫描在进度显示80%时被手动终止。两个人对同一事实产生了分歧：A认为“已经跑了八成，剩下两成补一下就行”；B认为“进度按任务数算，不是按URL数算，实际覆盖可能差很远”。两种理解都成立，因为它们说的不是同一个量。
进度条通常反映的是已处理任务数占计划任务数的比例，而计划任务本身可能包含重试、分页、参数变体。如果扫描工具把同一URL的多次请求算作多个任务，进度就会虚高；如果它把大量URL折叠进一个任务，进度又会虚低。所以80%这个数字本身不能直接换算成页面覆盖率。
两种解释：是“剩余未跑”，还是“已跑但未落库”
中断后的状态通常对应两种完全不同的解释：
- 解释一：剩余未跑。已完成的URL结果已经写入存储，中断只影响后面的队列。这种情况下，续跑或补跑剩余部分即可。
- 解释二：已跑但未落库。抓取动作发生了，但结果还在内存或临时缓冲区里，中断导致这部分数据丢失，表现为“跑过但查不到”。
这两种解释的处置方式相反：前者应该接着跑，后者必须把丢失区间重跑。如果判断错了，要么重复劳动，要么留下空洞却以为已经覆盖。
区分证据：用三类清单交叉核对
要区分上面两种解释，可以构造三份可核对的清单，然后比对它们的差集。
- 已落库URL清单。从扫描结果导出所有有明确状态记录的URL，这是确定已覆盖的部分。
- 日志请求清单。从抓取日志中提取实际发出过请求的URL，这是“动作发生过”的部分。
- 计划URL清单。从站点地图、内链抓取或初始种子列表得到的待扫集合，这是“理论上应该覆盖”的部分。
把日志清单减去已落库清单，得到的就是疑似丢失区间。如果这个差集很小，说明中断主要影响的是“还没开始跑”的部分；如果差集很大，说明大量请求结果没有落库，必须重跑。再把计划清单减去日志清单，得到的是从未触达的URL，这部分无论哪种解释都需要补扫。
实际操作上，可以先导出这三份清单，用URL做唯一键做集合运算。这个动作的结果直接决定下一步：差集小就续跑，差集大就重跑丢失区间，计划清单里从未出现的部分单独排队。
一个注明假设的短例子
假设某站点计划扫描1000个URL，中断时进度显示80%。导出后发现：已落库URL有500个，日志请求URL有780个，计划清单仍是1000个。那么疑似丢失区间是280个（780减500），从未触达是220个（1000减780）。此时“80%已完成”的说法不成立——真正可用的覆盖只有50%。下一步应该是：先重跑那280个疑似丢失的URL，再补扫220个从未触达的URL，而不是简单地从断点续跑。
这个例子的数字仅用于说明集合运算的比较方法，不代表任何真实项目的规模或结果。
把分歧转成可核对项目的三个动作
当多个角色对“扫了多少”有不同理解时，不要争论百分比，而是把分歧落到具体项目上：
- 统一计数口径。明确进度是按URL数、请求数还是任务数计算。口径不同，同一个数字含义不同。
- 导出并保存三份清单。已落库、日志请求、计划URL各存一份，作为后续核对的基准。
- 约定判定规则。例如“日志有请求但结果无记录”一律归入待重跑，避免每次都要重新讨论。
完成这些动作后，覆盖范围就不再是一个模糊的百分比，而是一组可以逐条核对的URL集合。续跑、重跑还是补扫，取决于集合运算的结果，而不是取决于谁的印象更接近进度条。
需要留意的是，请求量或抓取量归零并不自动证明中断处理正确。它也可能来自限速、封禁、队列耗尽或日志轮转。判断覆盖范围时，应把这些合理解释一并考虑，而不是只看某一个指标的变化。
