百度指数查询，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /30776a197524.html
📄
百度指数查询，一次全站扫描被中断后怎样判断已覆盖范围
中断后不要凭“还剩多少页”猜覆盖率。更可靠的做法是先确定扫描器已经把哪些URL写入可复核的清单，再用清单与站点实际URL集合做差集。若清单可续跑，就补扫差集；若清单不可续跑，就重新定义扫描边界，而不是从断点页码继续。
两种常见解释：断点续跑还是重新定界
扫描中断通常有两种解释。第一种是网络或进程中断，扫描器自身的队列和已抓取记录仍然完整，只是暂时停止。第二种是队列或记录本身不完整，例如写入失败、去重表丢失、分片任务没有汇总。两种解释对应的动作完全不同：前者可以从断点继续，后者继续跑只会重复已覆盖部分，却漏掉未入队的URL。
判断属于哪一种，可以看三个证据：
- 中断时是否留下可读的已抓取清单，且清单包含URL、状态码和抓取时间；
- 队列文件或数据库中的待抓取记录是否仍能读出，且没有大批量缺失；
- 重新启动后，扫描器是否从零开始，还是能识别已有记录并跳过。
如果清单和队列都完整，选择断点续跑，代价是可能重复少量页面；如果清单缺失或队列损坏，选择重新定界，代价是耗时更长，但覆盖率可验证。
用差集而不是页数判断覆盖范围
页数只能说明扫描器处理了多少次请求，不能说明覆盖了多少个不同URL。判断覆盖范围时，先准备一份站点URL全集，来源可以是sitemap、站内链接抓取结果或已知栏目清单。再把已抓取清单中的URL去重，与全集做差集。差集越小，说明已覆盖范围越接近全集。
这里有一个假设例子：某站点sitemap列出1200个URL，中断时已抓取清单中有900条记录，其中80条是重复抓取。去重后实际覆盖820个不同URL，差集为380个。若直接按“已抓取900条”判断，会高估覆盖范围。这个例子只说明比较方法，不代表任何真实站点的数据。
动作上，先把差集导出为待补扫清单，再决定是否续跑。补扫完成后，重新计算差集，而不是只看总请求数是否增加。
中断后哪些现象不能单独证明覆盖正确
请求量归零、抓取速度下降或日志不再增长，都不能单独证明扫描已经覆盖全站。请求量归零可能是进程退出、被限流、队列为空，也可能是目标站点暂时不可达。抓取速度下降可能是网络波动，也可能是扫描器进入低优先级队列。日志不再增长可能是任务完成，也可能是写入失败。
要区分这些原因，需要同时看清单记录数、队列剩余量和差集大小。若清单记录数不再增加，但差集仍然很大，说明扫描并未覆盖全站，只是停止了。若清单记录数不再增加，差集接近零，才更接近完成状态。
可复核清单比断点页码更有用
百度指数查询这类工具与站点扫描不是同一类对象，但“中断后判断覆盖范围”的思路可以迁移：先确认已处理记录是否可复核，再决定继续还是重来。对于扫描任务，建议保留三类字段：URL、抓取状态、抓取时间。只要这三类字段可读，就能重建覆盖范围；只有断点页码，则无法判断中间是否跳过或重复。
如果扫描器支持导出已抓取清单，优先导出并备份，再执行补扫。如果扫描器只显示进度百分比，不接受外部URL清单，那么中断后更稳妥的选择是重新定义扫描边界，例如按栏目或按sitemap分段扫描。分段后每段都有独立清单，中断只影响当前段，不会让整体覆盖率无法判断。
选择条件与代价对照
当已抓取清单完整、队列可读、去重表可用时，选择断点续跑。代价是可能重复抓取少量URL，但补扫范围明确。当清单缺失、队列损坏或扫描器重启后从零开始时，选择重新定界。代价是耗时增加，但覆盖范围可重新验证。
无论选哪种，下一步都应先导出差集清单，再执行补扫，最后用差集大小判断是否继续。若差集仍然很大，不要因为请求量已经恢复就认为覆盖完整；若差集接近零，也不要只凭一次结果就下结论，应保留清单以便复核。
