好搜SEO工具：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c9aeb69a3346.html
📄
好搜SEO工具：一次全站扫描被中断后怎样判断已覆盖范围
扫描中断后，不能凭工具界面是否还显示进度、日志是否停止写入或本次请求量归零来判断覆盖范围。更可靠的做法是：把中断前已经产出的原始记录当作唯一事实来源，按URL清单逐条核对“是否被抓取、是否拿到状态、是否完成解析”，再决定是补扫剩余区间还是重跑全站。下面以你手里那份中断后留下的导出文件为对象，说明怎么把它变成可执行的处理方案。
先确定中断发生在哪个阶段，而不是看进度条
同一份导出文件里，不同记录的完整程度意味着中断点不同。把记录按字段完整度分成三类，能直接指向下一步动作：
- 只有URL、没有状态码：说明任务在排队或发起请求阶段就断了，覆盖范围约等于零，剩余部分需要整体重扫。
- 有状态码、没有标题或正文摘要：请求已到达目标，但解析或写盘被切断，这批URL需要补解析，不一定要重新请求。
- 字段齐全但数量明显少于预期：中断发生在扫描后段，已完成的记录可用，缺口集中在未出现的URL区间。
判断依据是字段，不是时间戳先后。时间戳可能因为并发写入而乱序，用它推断断点容易误判。假设一份导出共1200行、其中400行只有URL，那么可用的完整记录是800行，但这800行是否等于“已覆盖”，还要看下面一步。
用站点自身的URL全集反推缺口，而不是用行数
导出文件的行数只说明工具写了多少条，不说明站点有多少页。要判断覆盖范围，需要一个独立于本次扫描的URL全集作为分母。常见来源有三种：
- 服务器访问日志中一段时间内出现过的URL；
- 站点地图文件里列出的URL；
- 站内链接爬取得到的URL集合。
把导出文件里的URL与这个全集做差集，得到的未出现URL才是真正的缺口。这里有个容易踩的坑：如果全集本身来自同一次扫描，差集必然为空，等于没有核对。所以要选一个在扫描之前就已存在、或由另一条路径生成的清单。
实际操作可以这样：把导出URL去重后排序，与站点地图URL排序，用文本比对工具找出只出现在地图里的条目。这批条目就是需要补扫的对象。如果差集规模很小，补扫成本低于重跑；如果差集接近全集，说明中断发生得很早，重跑更省事。
把分歧转成可核对的项目
多个角色对“扫了多少”有不同理解，通常是因为各自看的证据不同：一方看工具进度百分比，一方看导出文件行数，一方看服务器日志里的请求量。这三种证据的口径不一致，争论没有意义。可行的做法是建立一个核对项清单，让每个人对同一批URL给出同一维度的判断：
- 该URL是否出现在导出文件中；
- 若出现，状态码字段是否有值；
- 若状态码有值，标题或内容摘要字段是否有值；
- 该URL是否出现在独立URL全集中。
四项都是“有/无”或“是/否”，不涉及主观估计。核对完成后，缺口范围就是一个确定的URL列表，而不是一个百分比。百分比可以用于汇报，但不应作为决定补扫还是重跑的输入。
补扫还是重跑：按缺口比例和字段缺失类型决定
两个选择都成立，但适用条件不同：
- 补扫成立的条件：缺口URL数量少、且集中在一个可枚举的区间；已完成的记录字段完整，不需要重新请求。
- 重跑成立的条件：缺口URL数量接近全集，或大量记录的字段处于“有状态码无解析结果”状态，补解析的成本和重跑接近。
假设全集1000条，导出中完整记录850条，缺口150条且都能从站点地图枚举出来，补扫这150条即可，不必重跑。反过来，如果完整记录只有200条，缺口800条且分散，重跑更直接。这里的数字只是说明比较方法，实际阈值取决于你的时间预算和请求成本。
还有一个动作会影响下一步判断：在补扫之前，先对缺口URL做一次去重和规范化，去掉带跟踪参数的重复项。如果不去重，补扫结果会混入大量同一页面的不同参数版本，下一次核对时缺口看起来变小了，但实际覆盖的独立页面数没变。这个结果会直接误导“是否还需要再扫一轮”的决定。
中断后不要直接采信的两个信号
第一，工具界面仍显示进度或“运行中”，不能证明扫描还在继续，也不能证明已覆盖的范围有效，界面状态和实际产出可能不同步。第二，本次请求量归零，可能是中断，也可能是限速、被目标拒绝或任务已正常结束，需要结合导出文件的字段完整度判断，而不是单独作为结论。
把这两个信号排除后，你手里剩下的可核对材料就是导出文件、独立URL全集和服务器日志。以这三者为依据，覆盖范围可以被还原成一个URL列表，补扫或重跑的决定也就有了可复核的基础。下一轮扫描开始前，建议先固定URL全集的生成方式，这样即使再次中断，也能用同一套口径快速算出缺口。
