seo综合查询全站扫描被中断后，怎样判断已覆盖范围并决定是否重跑
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /81067f65f9e1.html
📄
seo综合查询全站扫描被中断后，怎样判断已覆盖范围并决定是否重跑
先看扫描任务有没有留下可续跑的中间产物，再决定是补跑剩余部分还是整体重来。判断依据不是“跑了多久”，而是已抓取的URL清单、每类检查的完成标记和最后一条成功记录的时间戳。如果这三样都能对上，通常可以只补缺口；如果中途崩溃导致清单与结果错位，重跑反而更省事。
中断发生在抓取阶段还是分析阶段，处理方式不同
抓取阶段中断意味着页面还没全部取回，此时已覆盖范围等于已成功返回的URL集合。分析阶段中断则页面已经取回，只是规则计算没跑完，已覆盖范围应按“已完成的检查项”而不是“已抓取的URL”来算。这两种情况常被混为一谈，导致补跑时重复劳动或漏掉整块内容。
判断方法很直接：打开任务日志，看最后一条记录是“请求返回”还是“规则执行”。如果日志停在请求层，说明抓取没走完；如果日志已经出现分析类输出，但条目数明显少于抓取数，说明问题出在分析阶段。这个区分决定了下一步是补URL还是补规则。
条件一：中间产物完整时，补跑缺口而不是整体重来
当任务目录里同时存在URL队列快照、已完成列表和失败列表，且三者的数量关系能对上（已完成+失败+待处理≈总数），就可以做增量补跑。具体动作是：先导出已完成列表，再用它作为排除条件重新提交剩余URL。这个动作的结果会直接影响后续判断——如果补跑后失败列表没有明显增长，说明中断只是偶发；如果失败列表持续扩大，问题可能出在目标站点本身，继续补跑意义不大。
补跑前建议先核对失败列表里的状态码分布。大量超时和大量4xx代表完全不同的原因，前者可能是网络或限速，后者可能是链接本身已失效。这一步不做，补跑只是把同样的错误再跑一遍。
条件二：中间产物缺失或错位时，整体重跑更可控
如果任务中断后只留下一个总进度百分比，没有可导出的URL级记录，那么“已覆盖范围”实际上无法可靠还原。此时继续补跑的风险是：你不知道哪些URL被算作已完成，可能重复抓取，也可能永远漏掉一部分。整体重跑虽然耗时，但结果边界清晰。
重跑前可以先做一次小范围验证：只提交一个已知正常的栏目，确认任务能完整走完抓取和分析两个阶段。这个动作的结果决定你是否需要调整并发数或超时设置再开始全量重跑。如果小范围验证仍然中断，说明问题不在数据量，而在配置或目标站点对高频请求的限制。
一个假设例子：如何用数量关系判断该补还是该重
假设一次扫描计划覆盖5000个URL，中断时日志显示已请求3200个，其中成功2900个、失败300个，分析阶段只完成了1800个页面的规则计算。这种情况下，抓取缺口是1800个URL，分析缺口是1400个页面。如果URL队列快照还在，可以只补这1800个URL的抓取，再对全部成功页面重新跑分析；如果快照丢失，就只能整体重跑。这个例子的数字仅用于说明比较方法，不代表任何真实任务规模。
旧内容退出场景下，已覆盖范围还要叠加“是否仍需保留”的判断
当扫描目的是为旧内容、旧系统或旧合作关系做退出决策时，覆盖范围只是第一层信息。第二层是：已扫描到的页面里，哪些仍然承载有效流量、有效外链或必要的合规信息。如果这些页面在中断前已经被扫描到，但分析没跑完，你无法判断它们是否值得保留，此时补跑分析比补跑抓取更优先。
具体动作是：先从已完成的分析结果里筛出“有自然点击”和“有外部链接指向”两类页面，把它们标记为暂缓处理。剩余页面再按扫描覆盖情况决定是补查还是直接进入退出流程。这个动作的结果会缩小需要精确判断的范围，避免因为一次中断就把所有旧内容一起处理掉。
例外情况是：如果旧系统本身已经无法稳定响应请求，继续补跑只会不断产生新的失败记录。这时更合理的做法是先归档已抓取的部分，用现有数据做决策，而不是追求一次完整的全站扫描。
把覆盖范围写成可复核的记录，而不是只记一个百分比
无论最终选择补跑还是重跑，都建议在任务结束后记录三样东西：本次实际覆盖的URL数量、未覆盖的原因分类（未抓取、抓取失败、分析未完成）、以及下次续跑时需要排除的清单。这样做的好处是，下一次中断时你能直接接上，而不是重新猜“上次跑到哪了”。
如果使用的是第三方查询工具，导出字段和任务恢复能力需要以该工具当前实际提供的功能为准，具体信息需要核对，不要假设所有工具都支持断点续跑。对多数通用工具而言，能导出URL级明细比提供一个总分更有决策价值。
