SEO软件一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e8c822c0eeb9.html
📄
SEO软件一次全站扫描被中断后怎样判断已覆盖范围
先别重跑，也先别把中断前的数据当成完整报告。判断已覆盖范围，靠的是抓取日志或扫描记录里的“最后成功条目”，而不是进度条百分比。把中断点前后的记录切成三段：已确认完成、状态不明、未开始。只有第一段能进入结论，第二段要单独标记，第三段直接留空。
先确认扫描器留下了哪类可核对记录
不同工具在中断后留下的证据差别很大，这决定了你能不能精确划出边界。
- 逐条写入型：每抓取一个URL就落一条记录，带时间戳和状态码。中断后你可以按时间排序，找到最后一条完整记录，它之后的都算未覆盖。
- 批量提交型：扫描在内存里跑完再统一写库。中断时可能一条都没落盘，也可能只落了部分分片。这种情况下“已覆盖”只能按分片边界判断，不能按URL数量估算。
- 只留汇总型：界面只显示“已扫描 12400 个页面”这类总数。这个数字通常包含重试和跳转，不能直接当覆盖量，需要回到导出明细里核对唯一URL。
动作：先导出原始明细，而不是截图汇总面板。结果：如果导出为空或只有表头，说明这次中断没有可用的覆盖证据，唯一正确的下一步是重新扫描，而不是修补结论。
用“最后成功条目”划出三段时间线
拿到明细后，按抓取时间排序，找到最后一条状态完整（有状态码、有响应时间）的记录，把它当作分界点。
- 已确认完成段：分界点之前、状态码正常的条目。这部分可以进入后续分析。
- 状态不明段：分界点附近出现超时、连接重置、状态码缺失的条目。它们可能抓到了但没写完，必须视为未覆盖。
- 未开始段：分界点之后完全没有记录的URL。数量等于站点总URL数减去前两段去重后的数量。
这里有个常见误判：把“状态不明段”里的超时条目当成已抓取。超时只说明请求发出过，不说明响应被完整接收。假设一次扫描在 8000 条处中断，其中最后 200 条是超时，那么可用的覆盖上限是 7800 条，而不是 8000 条。这个假设只用于说明划分方法，实际数字以你自己的明细为准。
多人对覆盖范围有分歧时，把争论转成可核对项
运营说“大部分都扫过了”，技术说“一半都没扫到”，分歧往往来自各自看的是不同层面的数字。把分歧拆成三个可以逐项核对的问题：
- 你依据的是明细条目数，还是面板汇总数？
- 你统计的是唯一URL，还是包含重定向和参数的请求数？
- 你把超时和状态缺失的条目算进已覆盖了吗？
让每个人用同一份导出明细各自算一遍，把结果写在同一个表格里。通常分歧会在“是否去重”和“是否计入异常条目”这两步上暴露出来，而不是在扫描本身。核对完再决定是否需要补扫，避免因为口径不同而重复跑一遍全站。
决定补扫范围时的取舍
确认边界后，你有两个合理选择，取决于中断原因是否已经排除。
条件一：中断是偶发的（网络抖动、本地资源被占用）。此时只需补扫“状态不明段”和“未开始段”，已确认完成段不必重跑，省下的时间可以用来核对数据质量。
条件二：中断可能由站点侧触发（服务器限流、防火墙拦截、响应持续变慢）。此时补扫同一批URL很可能再次中断，应先把并发调低、请求间隔拉长，再小批量试跑一段，确认能稳定写入记录后，才扩大到剩余范围。
判断依据不是中断发生的次数，而是中断点附近的状态码分布。如果集中在 429、503 或连接被重置，偏向条件二；如果状态码正常、只是本地进程退出，偏向条件一。选错方向的代价是：按条件一处理限流问题，会反复中断并浪费时间；按条件二处理偶发问题，会不必要地拖慢扫描速度。
把结论落到一份可交接的记录上
最后给这次中断留一份简短记录：扫描起止时间、最后成功条目的标识、已确认完成段的条目数、状态不明段和未开始段的处理方式。下一个接手的人不需要重新推断边界，直接从这个记录继续。如果后续要对比两次扫描的差异，也只有这份边界清楚的记录才能让差异有意义——拿一份覆盖范围不明的旧数据去对比，得到的“新增”或“丢失”很可能只是上次没扫到而已。
