关键字排名查询，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c1c351b06d85.html
📄
关键字排名查询，一次全站扫描被中断后怎样判断已覆盖范围
全站扫描中断后，不要凭“跑到第几页”或“剩余时间”判断覆盖范围，这两个数字通常只反映任务调度进度，不反映已实际取回并写入结果的范围。更可靠的做法是：先确认中断发生在取数阶段还是写库阶段，再决定是补跑缺失部分还是整批重跑。缺少完整数据和后台权限时，仍可执行一个最小动作——导出已完成部分的记录，按URL或查询词去重后与站点清单比对，算出“已覆盖”和“未确认”两块，而不是把中断前的进度条当作覆盖率。
先分清两种中断：取数被切断与写库被切断
两种中断的后果不同，判断方式也不同。
- 取数被切断：任务在请求或抓取途中停止，部分对象根本没被访问。此时“未覆盖”是真实缺口，必须补跑。
- 写库被切断：对象已访问，但结果还没落盘或只落了一部分。此时缺口可能是假的，重跑前应先核对已有记录，避免重复消耗配额。
区分依据可以看中断时的日志或任务状态：如果最后一批请求没有返回、连接被重置，偏向取数中断；如果请求已返回但结果表条数明显少于请求数，偏向写库中断。缺少日志权限时，用已导出记录的时间戳分布间接判断——记录集中在中断前某个时间点戛然而止，通常说明写入被截断。
条件一：能拿到已完成记录，做覆盖比对
这是最常见也最可执行的情况。步骤是：
- 导出已完成部分的记录，保留URL、查询词、抓取时间三个字段。
- 按URL去重，得到“已实际覆盖的页面集合”。
- 与站点URL清单（sitemap、内链导出或栏目列表）比对，得到差集。
- 差集就是待补跑范围；已覆盖部分不要重跑。
这里的关键假设是：导出记录里每条都代表一次成功取数。如果导出本身也可能被截断，就要先验证记录总数与任务报告的已完成数是否一致，不一致时以较小的那个为准。
实际动作与结果：假设站点有1000个URL，中断后导出记录去重得到620条，与清单比对后有380条不在其中。下一步就是只对这380条发起补跑，而不是整站重跑。这样做的直接结果是补跑范围明确，配额消耗可控；如果比对发现差集里混入了本就不该扫描的URL（如参数页、分页），还要先修正清单再补跑。
条件二：拿不到记录或权限不足，只能做保守估计
没有导出权限、或导出文件损坏时，无法得到精确覆盖集合。此时可执行的最小动作是：用中断前最后一次成功的时间戳，结合任务开始时间和平均处理速度，估算一个大致区间，并把它标注为“不确定”，而不是当作覆盖率使用。
可以这样设定假设：任务从10:00开始，10:40中断，前30分钟稳定处理，平均每分钟处理约20个对象，那么保守估计已处理约600个，但上下浮动可能很大。这个数字只能用于决定“补跑全部还是补跑后半段”，不能用于对外报告覆盖率。
需要说明的是，请求量或抓取量在中断点归零，不能单独证明前面都已正确处理。归零还可能来自限流、队列阻塞、写库失败或任务被主动暂停，这些原因都会让“已处理数”高于“已成功写入数”。所以缺少记录时，宁可把范围估小，也不要把估算值当成事实。
补跑范围怎么定：按URL补还是按查询词补
关键字排名查询的扫描对象通常有两层：页面和查询词。中断后补哪一层，取决于你的目标是页面覆盖还是词覆盖。
- 目标是“每个页面都有排名数据”：按URL比对，补缺失页面。
- 目标是“每个目标词都有结果”：按查询词比对，补缺失词，同一页面可能被多次补跑。
如果两层都要，先补查询词再按URL去重，通常比先补URL更省请求。例外是：站点页面数量远小于查询词数量时，按URL补更快，因为一个页面可以一次性覆盖多个词。
判断完成的标准与例外
补跑结束后，判断“已覆盖”的标准是：目标集合中每个对象都有一条成功记录，且记录时间在本次任务窗口内。不要用“任务状态显示完成”作为唯一依据，状态完成不等于每条都成功。
例外情况需要单独处理：被robots或登录墙挡住的页面，补跑多少次都不会有结果，应把它们从目标集合中移出并单独记录；返回空结果的查询词，要区分“确实无排名”和“取数失败”，前者可以计入覆盖，后者不能。
最后，中断后的覆盖判断本质上是一次范围核对，不是一次数据质量判断。即使覆盖率达到预期，也只能说明对象被访问过，不能推出排名数据准确或可用于决策——那需要另外核对数据口径和采集时间。
