SEO软件平台：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /de19f462ff79.html
📄
SEO软件平台：一次全站扫描被中断后怎样判断已覆盖范围
先看扫描日志的结束原因，再看已处理URL清单与站点可发现URL总量之间的差集，最后用抽样比对验证差集是否可信。中断后的覆盖范围不是“跑了多少条”这个数字，而是“哪些URL被完整处理、哪些只入队未处理、哪些根本没被发现”这三类的划分。
矛盾现象：同一份中断记录，两个人读出两种结论
常见场景是：负责执行的人看到进度条停在某个百分比，判断“大部分已经扫完，可以先看报告”；负责决策的人看到日志末尾是中断信息，判断“数据不完整，整份报告不能用”。两种理解都只抓住了一个信号，没有落到URL级别去核对。
产生分歧的根源在于，进度百分比通常按“已入队或已发起请求”计算，而报告里的指标往往只统计“已返回并解析成功”的页面。中断发生时，这两个口径之间会留下一个既未完成、也未失败的中间层。谁都不清楚这个中间层有多大，分歧就无法收敛。
两种解释：任务被截断，还是发现阶段本身就不完整
解释一：任务被截断。爬取队列已经建立完整，只是执行到中途停止。这种情况下，未覆盖部分主要是队列里排在后面的URL，站点结构本身已被识别，补跑或分批续跑可以补齐。
解释二：发现阶段不完整。中断发生在链接发现尚未收敛的阶段，队列本身还在增长。此时未覆盖部分不仅是“没跑到的”，还包括“本来能通过内链、站点地图或分页被发现、但因为中断而从未进入队列的URL”。这种缺失无法靠续跑自动补上，必须重新触发发现。
两种解释对应完全不同的下一步：前者可以复用已有结果，后者需要重跑发现逻辑，否则后续任何指标都建立在残缺的URL集合上。
区分两种解释的证据：看队列是否还在增长
能区分这两种情况的关键证据，是中断前一段时间内“新发现URL数”的变化趋势，而不是已完成数量。
- 如果中断前若干批次里，新发现URL数已经趋近于零并保持稳定，说明发现阶段基本收敛，倾向解释一。
- 如果中断前新发现URL数仍在明显波动或持续新增，说明队列尚未收敛，倾向解释二。
- 如果日志只记录了完成数、没有记录每批次新增发现数，那么这份日志不足以支撑任何覆盖范围判断，需要先补齐这一项再谈结论。
另一个辅助证据是入口覆盖率：把站点地图、主导航、分页序列这几类已知入口分别列出，检查每一类是否都至少被处理过一轮。若某一类入口完全没出现在已处理清单中，通常指向解释二。
把分歧转成可核对的项目：三类URL清单
与其争论“算不算跑完”，不如把已处理结果拆成三份可核对的清单，让每个角色对着同一份事实说话。
- 已完整处理：有请求记录、有返回状态、有解析结果。这部分可以直接进入指标统计。
- 已入队未处理：有排队记录但没有返回结果。这部分属于可续跑范围，前提是发现阶段已收敛。
- 未发现：通过站点地图、内链或分页本应能到达、但从未出现在任何记录中的URL。这部分只能靠重新发现来补齐。
核对方法是：从站点地图和主要栏目页各抽一小批URL，逐一在三份清单中定位。如果抽样URL大量落在第三类，说明覆盖范围的实际缺口比进度数字显示的大得多。
一个注明假设的短例子
假设某站点站点地图列出1000个URL，中断时已完整处理600个，已入队未处理250个，剩余150个在任何记录中都查不到。若中断前新发现URL数已连续多个批次接近零，可以合理推断那150个大概率属于抓取限制或参数过滤导致的未入队，而非发现未收敛；此时续跑并单独核查这150个即可。反之，若新发现URL数仍在增长，那150个更可能是发现中断的产物，应先重跑发现阶段，再决定续跑范围。两种情况下，动作不同，后续指标的可信度也不同。
需要说明的是，请求量或抓取量在中断后归零，并不能单独证明任务已正常结束——它同样可能来自队列耗尽、被目标站点限流，或进程被外部终止。判断覆盖范围时，应结合结束原因、队列增长趋势和抽样比对三者一起看，而不是只看某一个数字。
决定下一步之前先固定口径
把“覆盖范围”定义成可核对的URL分类，而不是一个百分比，分歧就会自然缩小。具体做法是：先确认中断原因和队列收敛状态，再生成三份清单并抽样验证，最后根据抽样结果决定是续跑、重跑发现，还是先修正抓取限制。这个顺序一旦固定，不同角色对同一份中断记录的解读就能落到同一组事实上。至于具体平台如何记录队列增长、如何导出未处理清单，各工具实现不同，需要以实际日志字段为准逐项核对。
