百度站长工具：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9156cf86adf5.html
📄
百度站长工具：一次全站扫描被中断后怎样判断已覆盖范围
扫描中断后，最危险的做法是拿中断前的数字当“已完成”。判断已覆盖范围，不能看扫描进度条或最后一条日志，而要看三样可核对的东西：中断时正在处理的URL落在哪个区间、已完成部分的计数与导出是否一致、以及未完成区间是否还能用同一批参数续扫。只要这三样对不上，就应把结果视为部分覆盖，而不是全站结论。
矛盾现象：进度显示接近完成，导出却明显偏少
常见情况是：扫描界面显示已处理大部分URL，但导出的记录只有很少一部分，或者抓取异常列表几乎为空。直觉会认为“扫描快完了，数据基本可用”。这个判断在中断场景下往往不成立，因为进度和落库是两件事。
两种合理解释需要分开：
- 解释一：进度统计的是“已请求”，不是“已入库”。中断发生在请求队列推进很快、但结果写入尚未完成的阶段，于是进度虚高，导出偏少。
- 解释二：导出被筛选条件限制了。导出时选了特定目录、时间范围或页面类型，导致看起来覆盖很少，实际已处理范围更广。
这两种解释的应对完全不同：前者要重扫未入库区间，后者只需放宽筛选重新导出。不能凭“数字少”直接下结论。
能区分解释的证据：三个可核对点
要区分上面两种情况，按顺序核对：
- 看中断时的日志时间戳与最后一条已完成记录的时间戳。如果两者接近，说明中断时写入基本跟上了请求；如果日志很早、最后记录很晚，说明写入滞后，进度不可信。
- 用同一批筛选条件分别导出两次。一次带筛选、一次不带筛选。若不带筛选的记录数明显更多，说明是筛选造成的“覆盖少”，而非扫描本身没覆盖。
- 核对URL区间是否连续。把已导出的URL按路径排序，看是否存在整段缺失。整段缺失通常意味着扫描在某个目录边界被中断，而不是随机漏抓。
如果三个证据都指向“写入滞后”，那么下一步应该是缩小重扫范围，而不是重跑全站。缩小范围的动作是：以最后一条成功入库的URL为起点，向后取一个明确的区间重新扫描。这样做的结果是，你能得到一个边界清晰的续扫结果，而不是又一次可能中断的全量任务。
一个假设例子：如何界定续扫起点
假设某次扫描处理到 /product/ 下的页面时中断，导出记录显示 /product/a 到 /product/m 有数据，/product/n 之后为空。这不代表 /product/n 之后一定有问题，只代表中断点可能落在这里。
此时不要直接判定“后半段全漏”。正确动作是：先单独请求 /product/n 和 /product/o，确认它们能否正常返回；如果能返回但不在导出里，说明是入库缺失，续扫应从 /product/n 开始；如果返回异常，则要先排查该目录本身的可访问性，再决定是否续扫。这个动作的结果会直接改变下一步：前者是补扫，后者是先修可访问性再扫。
什么条件下才能把中断结果当作已覆盖
只有同时满足以下条件，才可以把中断前的结果当作“已覆盖该范围”使用：
- 已处理区间有明确的起止边界，且边界可复现；
- 导出记录与日志中的已完成计数一致，没有明显缺口；
- 未完成区间没有被混入“已覆盖”的统计口径。
如果只满足其中一两条，建议按部分覆盖处理，并在后续使用这些数据时标注覆盖范围。标注范围不是形式，它决定了你能否把结论外推到全站。对百度站长工具这类平台，具体入口、导出字段和扫描参数可能随版本变化，操作前应以当前界面实际显示为准，不要依赖旧截图或他人描述。
续扫之后还要确认的一件事
续扫完成不等于全站已覆盖。续扫只补上了中断区间，如果原任务在中断前还有更早的未入库部分，续扫不会自动发现。因此续扫结束后，应再做一次区间比对：把续扫结果与中断前导出结果按URL合并去重，看合并后的总量是否接近你预期的全站规模。若仍明显偏少，说明还有第三段缺口，需要继续定位，而不是直接收尾。
判断已覆盖范围的核心，不是相信某个进度数字，而是用日志时间、导出筛选和URL连续性三组证据交叉验证，再用一次有边界的续扫把缺口补实。只有边界清晰、计数一致、缺口补全之后，这份扫描结果才适合用于后续决策。
