SEO关键词工具对比，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e9cc5ed3080c.html
📄
SEO关键词工具对比，一次全站扫描被中断后怎样判断已覆盖范围
先给结论：中断后不要凭“跑到第几页”判断覆盖范围，要把扫描拆成可核对的单元，用已落盘的结果反推缺口。假设你负责一个内容站，用某关键词工具跑全站扫描，任务在中途被中断，团队里有人说“大部分跑完了”，有人说“只跑了首页”，这时唯一能对齐的做法是拿出一份覆盖清单，让每个人对着同一组事实说话。
先定义“覆盖”到底指什么
分歧往往不是数据问题，而是口径问题。全站扫描的“覆盖”至少有三层含义，先选定一层，再谈百分比：
- URL 覆盖：扫描触达了站点内多少个可抓取地址，与站点地图或站内链接总数相比。
- 关键词覆盖：这些 URL 上提取出了多少去重后的词条，与工具设定的词条上限相比。
- 指标覆盖：每个词条是否都拿到了你需要的字段，比如搜索量、难度、竞争度，而不是只有词没有指标。
三层口径对应的“未完成”完全不同。URL 跑了一半，关键词可能只覆盖三成；词条数量够了，指标字段却可能大面积缺失。先让所有人确认按哪一层汇报，否则争论会一直停留在感觉上。
用已落盘结果反推缺口，而不是猜进度
中断后最可靠的证据是已经写出的结果文件，而不是界面上的进度条。按下面顺序做一次核对：
- 导出或截取已完成的记录，统计去重后的 URL 数、词条数，以及各指标字段的非空比例。
- 与扫描前设定的范围对照：站点地图条数、目录白名单、词条上限、字段清单。
- 把差异分成两类：结构性缺口（整段目录没被触达）和随机性缺口（同一目录里零散遗漏）。
结构性缺口通常说明中断点之前就存在范围问题，比如某子目录被排除规则挡掉；随机性缺口更可能只是中断导致。两者的处理方式不同，前者要改配置重跑，后者可以只补跑缺失部分。
一个假设的短例子
假设站点地图列出 800 个 URL，扫描中断后导出文件里有 500 条记录，其中 60 条字段为空。此时可以说 URL 覆盖约六成，但有效指标覆盖不到六成。如果这 500 条集中在博客目录，而产品目录一条都没有，那就是结构性缺口，补跑之前必须先检查排除规则，否则重跑仍会漏掉同一批页面。这个例子里的数字只用于说明比较方法，不代表任何工具的真实表现。
把分歧转成可以核对的项目
当多个角色对同一事实理解不同，把口头判断写成一张待核对表，每一行都要有可验证的来源：
- 范围来源：站点地图、站内链接抓取结果，还是手工粘贴的清单。
- 排除规则：哪些目录、参数、状态码被跳过，由谁确认。
- 字段清单：本轮必须拿到的指标有哪些，允许为空的条件是什么。
- 判定标准：覆盖到多少比例算可用，低于多少必须重跑。
这张表本身就是决策依据。核对完如果发现排除规则误伤，下一步动作是修正规则并重跑，而不是在旧结果上继续分析；如果只是中断造成的零散缺失，下一步是补跑缺失 URL 并合并结果。动作不同，后续所有结论的可信度也不同。
重跑前先决定：补跑还是全量重来
判断依据可以归纳成两条：
- 可以补跑：缺口是随机的、字段结构一致、排除规则已确认无误。此时补跑缺失部分并合并，成本更低。
- 应当全量重跑：缺口是结构性的、中途改过配置、或合并后无法区分新旧记录。此时补跑会把两种口径混在一起，后续对比会失去意义。
另外，请求量、抓取量或某类统计归零，不能单独证明“已经跑完”或“处理正确”。它也可能是限流、超时、被目标站拒绝，或者工具在中断时清空了临时状态。看到异常数字时，先核对日志和配置，再下结论。
让下一次中断不再引发争论
与其在中断后补救，不如在扫描前留下可恢复的痕迹：分批提交 URL 并保留批次编号，每批导出后立即落盘，记录批次对应的范围与时间。这样即使任务再次中断，也能直接说出“第几批到第几批已完成”，覆盖范围从推测变成清单。对使用具体工具的人来说，分批能力、导出字段和恢复方式需要以你所用版本的说明为准，不要假设某个按钮或入口一定存在。
回到最初的分歧：判断覆盖范围的关键不是谁记得更清楚，而是有没有一份可核对的清单，把 URL、词条、字段和排除规则逐项对上。对上了，补跑还是重跑就是一道有依据的选择题；对不上，任何百分比都只是猜测。
