页面速度优化工具全站扫描中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4da3d64e72b3.html
📄
页面速度优化工具全站扫描中断后怎样判断已覆盖范围
先看扫描任务留下的进度记录和结果文件，而不是直接重跑。多数工具在中断时会保留已完成页面的部分数据，并记录最后处理的URL或队列位置。判断覆盖范围的核心是：把“已产出结果的页面”与“计划扫描的页面”做差集，再决定补扫还是全量重扫。
中断后出现“结果很少”的两种解释
一次全站扫描被中断后，常见矛盾是：任务面板显示完成度不低，但导出的结果只有几十条。这通常有两种解释。
- 解释一：覆盖确实很窄。扫描在早期就中断，工具只处理了入口页和少量内链，结果少是因为真的只跑了这些页面。
- 解释二：覆盖不窄，但结果被过滤或未落盘。工具已经抓取了很多页面，但部分结果因为超时、状态码过滤、重复URL合并或写入失败而没有出现在导出文件中。
这两种解释对应的下一步完全不同：前者需要补扫大量页面，后者需要先修复结果落盘或过滤条件，否则补扫仍会得到残缺数据。
用哪些证据区分“没跑到”和“跑了没留下”
能区分两种解释的证据，通常不在结果文件本身，而在任务日志和中间状态里。可以按以下顺序核对。
- 看任务日志的最后时间戳和最后URL。如果日志停在某个URL，且之后没有新条目，说明扫描确实在那一刻中断，覆盖范围大致到该URL为止。
- 看抓取队列或待处理列表。部分工具会保留未处理队列。队列长度大，说明大量页面没跑到；队列为空但结果很少，更倾向解释二。
- 看结果文件里的URL数量与日志中“已抓取”计数是否一致。如果日志计数明显大于导出条数，说明有结果没落盘或被过滤。
- 抽查几个已知存在的页面。从站点地图或内链中挑几个不同层级的页面，看它们是否出现在结果中。如果连首页都没出现，问题更可能在导出环节。
这里有一个假设例子：假设某次扫描计划覆盖1000个URL，中断后日志显示已抓取620个，但导出文件只有80条。此时不能直接补扫剩余380个，因为620与80之间的差距说明结果落盘可能有问题。更稳妥的动作是先用日志中的已抓取URL列表与导出文件做差集，确认缺失的是“未抓取”还是“未导出”。如果缺失集中在导出环节，下一步应先调整导出范围或重新生成报告，而不是立即重跑全站。
判断覆盖范围时优先核对的三类记录
不同工具的记录方式不同，但可核对的信息类型大致相同。具体字段名称和入口位置需要以你所用工具的当前版本为准。
- 任务级记录：开始时间、结束时间、中断原因、已处理数量、失败数量。这些数字能给出覆盖范围的上限和下限。
- URL级记录：最后处理的URL、已抓取URL列表、跳过URL及跳过原因。跳过原因尤其重要，它决定了这些页面算不算“已覆盖”。
- 结果级记录：导出文件中的URL、状态码、抓取时间。把导出URL与已抓取URL做差集，就能定位缺失环节。
如果工具只提供汇总数字而不提供URL级列表，覆盖范围就只能估算。此时更实际的做法是缩小扫描范围，按目录或子域分批重扫，每批完成后立即导出并记录批次边界，避免再次中断后无法判断进度。
什么情况下补扫，什么情况下重扫
判断清楚之后，取舍标准可以简化为两条。
可以补扫的条件：已抓取URL列表完整，导出结果与已抓取列表基本一致，中断点明确，且剩余URL能通过站点地图或队列单独列出。此时补扫剩余部分即可，已覆盖部分不必重跑。
建议重扫的条件：已抓取URL列表缺失、导出结果明显少于日志计数、跳过原因无法解释，或者扫描期间站点结构发生过变化。这些情况下补扫的边界不可靠，分批重扫反而更省事。
无论补扫还是重扫，动作之后都要做一次覆盖核对：把本轮实际产出结果的URL数量，与计划扫描的URL数量对比，并记录差异原因。这个核对结果会直接影响下一步——差异可解释，就可以基于当前数据做优化决策；差异不可解释，就先不要用这份数据下结论。
