站长SEO工具一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c453980320f9.html
📄
站长SEO工具一次全站扫描被中断后怎样判断已覆盖范围
扫描中断后，不要先看“跑了多少条”，而要先固定一个可复算的核对对象：把本次任务的范围定义、已落盘的结果文件和中断时的进度记录三样东西放在一起，逐项对账。只要范围定义本身模糊，后面的数字再大也无法判断覆盖到哪。
先确认“范围定义”是不是可复算的
全站扫描的覆盖范围，本质上等于“扫描入口 + 抓取规则 + 排除规则”三者共同圈定的集合。中断后第一件事，是回到任务配置里把这三项抄出来，而不是凭印象回忆。
- 入口：是从首页递归，还是从站点地图、URL列表进入？不同入口会得到不同的可达集合。
- 抓取规则：跟随哪些链接、是否跨子域、是否带参数、深度限制是多少。
- 排除规则：robots限制、nofollow、重复URL归一化、黑名单路径。
如果这三项在中断前后被改过，那么“已覆盖范围”就没有唯一答案，必须先确定以哪个版本为准。假设某次任务最初设定深度为5，中途改成3，那么深度4、5的页面即使被访问过，也不能算进当前版本的覆盖集合。范围定义变了，覆盖分母就变了，这是判断一切比例的前提。
用落盘文件而不是界面进度判断已覆盖
中断时界面显示的进度条或计数，往往只是内存中的临时状态，进程结束后可能丢失或回退。更可靠的依据是已经写入磁盘的结果文件。
可以按下面的顺序核对：
- 打开结果文件，统计其中唯一URL的数量，这是“已落盘覆盖数”。
- 检查最后若干条记录的写入时间，确认文件是否在中断点附近停止增长。
- 如果工具支持断点续跑，查看它记录的已完成队列或游标位置，与文件内容交叉验证。
这里有一个常见分歧：界面显示已扫描8000条，但结果文件只有6200条唯一URL。差额可能来自重复URL、被排除的URL，或尚未刷盘的缓冲。此时应以文件中的唯一URL为下限，界面计数为上限，真实覆盖落在两者之间。不要用单一数字下结论。
把“已覆盖”和“已处理成功”分开
覆盖不等于成功。一个URL被访问过，可能返回超时、403、重定向或空内容。判断覆盖范围时，需要把状态分层看：
- 已请求：工具确实发起了访问。
- 已获取：拿到了有效响应体。
- 已解析：提取出了标题、链接、状态码等目标字段。
如果中断发生在解析阶段，那么“已请求”的数量会明显大于“已解析”的数量。此时若直接拿请求数当覆盖数，会高估可用结果。可以随机抽取中断点附近的若干条记录，检查它们是否包含完整字段；如果大量记录只有URL没有解析结果，说明覆盖实际停留在获取层。
用一个短例子把分歧变成可核对的项目
假设团队里三个人对同一次中断扫描给出三种说法：A说覆盖了全站，B说只覆盖了栏目页，C说数据不可用。可以把分歧拆成下面这张核对表（示例为假设，用于说明方法）：
- 核对项一：本次范围定义以哪份配置为准？由谁确认？
- 核对项二：结果文件唯一URL数是多少？最后写入时间是什么？
- 核对项三：这些URL中，处于已解析状态的比例大概如何？
- 核对项四：未覆盖部分是否可以通过断点续跑补齐，还是必须重扫？
把四个问题分别指派给能给出证据的人，分歧就会从“谁说得对”转成“哪个数字对不上”。可核对的项目一旦列出，判断覆盖范围就从争论变成了对账。
决定下一步：续跑、重扫还是缩小范围
对账之后，通常有三种处理方向，选择依据是缺口性质：
- 如果缺口只是尾部未跑完，且工具支持断点续跑，优先续跑，避免重复消耗。
- 如果范围定义在中途被改过，或结果文件结构不完整，续跑会混入两套口径，应重扫。
- 如果全站规模远超本次需要，可先缩小到关键目录重扫，把完整覆盖留到必要时再做。
无论选哪种，都应先记录本次的范围定义和已落盘数量，作为下一次的基线。这样即使再次中断，也能快速判断是接着跑还是从头来。中断本身不是问题，无法复算的覆盖范围才是。
