SEO工具集，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0c050e4a2918.html
📄
SEO工具集，一次全站扫描被中断后怎样判断已覆盖范围
先看扫描器在中断前留下的进度记录和已写入结果，而不是凭“跑了多久”估算。判断覆盖范围的关键是找到三类可核对的证据：开始与结束时的URL清单、每类结果的计数、以及最后一条成功写入记录的时间戳。如果这三类证据互相吻合，可以按已覆盖处理；如果只有时间戳，覆盖范围通常不确定。
先分清“中断”发生在哪一层
全站扫描通常分三层执行：发现URL、抓取页面、写入结果。中断可能只影响其中一层。假设一次扫描发现阶段已完成，抓取到一半时进程被杀掉，那么“发现覆盖”是完整的，“抓取覆盖”是不完整的。这两者的结论完全不同。
- 发现层完整：URL清单已经落盘，后续可以只补抓未完成的页面。
- 发现层不完整：清单本身缺失，必须重新发现，不能靠补抓解决。
- 写入层落后：抓取可能已完成，但结果没写完，需要核对写入日志而不是抓取日志。
判断动作：打开扫描器的工作目录，找到URL队列文件或数据库表，看它是否有明确的完成标记。有完成标记，说明发现层可信；没有，则把发现层视为不完整。
用“三份计数”交叉验证覆盖范围
仅看一个数字容易误判。更稳的做法是对比三份计数：发现到的URL总数、尝试抓取的URL数、成功写入结果的URL数。三者的关系决定了下一步。
- 发现数等于尝试数，尝试数大于写入数：中断在写入阶段，已抓取的数据可能还在临时文件里，先检查临时文件再决定是否重跑。
- 发现数大于尝试数：中断在抓取阶段，未尝试的部分需要补抓，已尝试的部分可以直接复用。
- 三者接近但都小于预期：可能是发现阶段提前结束，需要确认扫描是否设置了数量上限或深度限制。
这里有一个容易被忽略的反常现象：某些扫描器在中断时会先写入一条“批次结束”记录，导致计数看起来完整，但实际内容缺失。要区分这种情况，需要看最后若干条记录的时间戳是否集中在一个很短的时间窗内。如果是，说明是批量收尾而非真实完成。
假设情境：一次中断后的实际决策路径
以下情境为假设，用于说明判断方法，不代表任何真实项目结果。
假设某站点约有五千个可抓取URL。一次扫描在运行约四十分钟后被手动停止。工作目录里有一个URL队列文件，标记为“未完成”；结果数据库中有三千二百条记录；日志最后一条写入时间与停止时间相差不到两秒。
第一步，检查队列文件。它没有完成标记，说明发现层可能不完整。但进一步看，队列文件里的URL数量是四千八百条，且最后一批URL的添加时间在停止前十分钟就停止了。这提示发现阶段可能已经自然结束，只是缺少完成标记。
第二步，对比计数。发现四千八百，结果三千二百，差值一千六百。检查临时抓取文件，发现有约一千五百条已抓取但未写入的记录。这意味着实际抓取覆盖接近四千七百，写入覆盖是三千二百。
第三步，决定动作。由于发现层大概率完整，且临时文件可恢复，选择先执行写入恢复，再对剩余约一百条未抓取URL做补充抓取。恢复后写入数达到四千七百，与发现数的差值缩小到一百，此时可以认为覆盖范围已经明确：全站约四千八百个URL中，已处理四千七百个，剩余一百个需要单独处理。
这个路径的关键是：不把“结果数”直接当成“覆盖数”，而是把发现、抓取、写入三层分开核对。任何一层缺失，都会让覆盖判断偏向保守或激进。
哪些信号说明覆盖判断不可靠
以下情况出现时，不建议直接复用已有结果：
- 日志中没有明确的批次开始和结束记录，只有零散的时间戳。
- URL队列文件在中断后被截断或重写，无法确认原始发现范围。
- 结果写入使用了缓冲机制，中断时缓冲区内容未落盘，且没有临时文件。
- 扫描过程中修改过抓取规则或过滤条件，导致前后批次的覆盖标准不一致。
这些信号的共同点是：缺少可核对的边界。此时更稳妥的动作是重新执行一次完整扫描，或者至少重新执行发现阶段，再决定是否复用旧结果。重新扫描的成本通常低于在不确定覆盖范围上做后续分析的成本。
把覆盖结论写成可交接的记录
判断完成后，把结论写成一条简短记录，包含：扫描目标范围、发现数、抓取数、写入数、中断点、已覆盖比例、未覆盖部分的处理方式。这条记录的作用不是汇报，而是让下一个使用这批数据的人知道哪些结论可以依赖、哪些需要重新验证。
如果后续分析只依赖已写入的结果，就在记录中注明“未覆盖部分不影响当前分析”或“未覆盖部分可能影响某类页面的结论”。这样，覆盖判断就从一次中断的善后，变成了对后续决策的约束条件。
