seo自动化工具：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c0706dc493f1.html
📄
seo自动化工具：一次全站扫描被中断后怎样判断已覆盖范围
先看扫描任务有没有留下可续跑的中间产物。如果工具把已抓取 URL、状态码和时间戳写进了数据库或日志，你可以据此重建覆盖边界；如果只在内存里汇总、中断即丢弃，那么唯一可靠的办法是缩小范围重跑，并从重跑结果反推旧任务可能覆盖到哪里。两种情况下都不能把“有输出文件”直接等同于“全站已覆盖”。
条件一：有可续跑或可读的中间记录
这类工具通常会在任务目录下留出队列文件、抓取日志或数据库表。中断后不要急着重跑全站，先做三件事：确认记录是追加写入还是覆盖写入；确认最后一条记录的时间戳是否明显早于中断时刻；确认记录里是否包含 URL、深度、状态码这几个字段。若三者都成立，你得到的是一个“至少已处理”集合，而不是完整覆盖集合。
实际动作：把日志中的 URL 去重后与站点地图、内链导出的 URL 列表做差集，差集部分就是尚未确认覆盖的候选。这个差集会影响下一步——如果差集只集中在深层分页或参数页，可以只补扫这些路径；如果差集覆盖了主要栏目，说明中断发生在早期，续跑价值低，直接重跑更省事。
需要留意的例外：日志按批次缓冲写入时，最后一批可能整体丢失，此时“最后时间戳”会误导你，实际覆盖范围比记录更小。判断方法是看相邻批次的时间间隔是否突然变大，变大往往意味着中间有未落盘的数据。
条件二：没有中间记录，只有一份不完整的结果文件
结果文件只能证明“这些 URL 被处理过”，不能证明“其余 URL 没被处理过”，因为中断可能发生在写入之前。此时可执行的最小动作是：先按目录或路径前缀对已有结果分组，统计每组数量和组内最大深度；再与站点已知的结构做对照。若某个一级目录在结果里完全缺席，而它本应出现在抓取顺序的前段，那么中断很可能发生得很早。
假设一个例子：某站有文章、标签、作者三类路径，结果文件里只有文章路径且深度不超过两层。在假设抓取按广度优先的前提下，可以推断标签和作者路径尚未进入队列，而不是“抓过但没写进去”。这个推断依赖抓取顺序假设，如果工具实际按随机或按权重排序，结论就不成立，只能改为按路径分批重扫。
不能推出的结论包括：把结果文件里的 URL 数量当作全站规模、把缺失路径当作不存在、把某目录零结果当作该目录无问题。这些都需要重跑或换用带持久化队列的配置来验证。
用覆盖证据的强弱来分配下一步
把手上能拿到的信息按证据强度排序，比笼统判断“扫了多少”更有用：
- 强：带时间戳和状态码的逐条记录，且写入方式为追加。
- 中：结果文件加站点结构对照，能定位缺失的路径前缀。
- 弱：只有汇总数字，如“已处理 N 条”，无明细。
强证据下可以只补扫差集；中证据下建议按路径前缀分批重扫，先扫主要栏目；弱证据下不要尝试推断覆盖范围，直接以缩小范围的方式重跑，并把本次配置改为可续跑，避免下次再遇到同样问题。
中断本身也值得记录成判断依据
中断原因会影响你对已有结果的信任程度。进程被手动终止、网络超时、内存不足，这三类情况下已写入数据的完整性不同。手动终止通常保留已落盘部分；超时可能留下半条记录；内存不足可能导致最后一批整体丢失。把中断原因、中断时刻和最后一条记录时间一起记下来，下次设置并发和超时就有参照，而不是每次都靠猜。
最终判断标准很简单：你能不能指出哪些 URL 一定有记录、哪些一定没有、哪些不确定。三者边界清晰，就可以继续；边界模糊，就缩小范围重跑。
