📍 WDQWDWQD987AAAAA:216.73.216.195
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7d7bac10f1d4.html
📄

好搜优化软件，一次全站扫描被中断后怎样判断已覆盖范围

先看扫描日志和结果文件里有没有分批记录。如果工具把已抓取的URL逐条写入本地结果或日志，中断后就能按批次号、时间戳或URL清单核对覆盖范围；如果只有汇总进度条，没有落盘明细，那么中断前到底覆盖了多少页面就无法可靠还原，只能重新扫描或改用能保留明细的方式。判断的关键不是进度百分比，而是有没有可逐条核对的已处理清单。

先分清中断发生在哪一层

一次全站扫描通常分三层推进：取URL、请求页面、解析入库。中断可能发生在任意一层，而每一层留下的证据不同。

• 取URL阶段中断：日志里只有URL来源和数量，没有逐条请求记录，覆盖范围基本不可判断。
• 请求阶段中断：日志若按条写入状态码和时间，可以数出已成功请求的页面。
• 解析入库阶段中断：结果文件里已有字段，但可能缺少部分页面，需要和URL清单做差集。

先打开日志确认最后一条记录属于哪一层，再决定是补扫还是重扫。若最后一条是“开始请求第N个URL”，说明URL层已完成、请求层部分完成，此时按URL清单做差集最直接。

用URL清单和结果文件做差集

把扫描前导出的站点URL清单当作基准集合，把结果文件里的URL当作已处理集合，两者相减就是未覆盖部分。这个动作不需要工具提供专门功能，用表格或命令行都能完成。

假设一次扫描目标为500个页面，结果文件中有312条URL记录，日志显示中断前最后处理的URL是第340条。此时312与340之间的差额说明有28条被请求但未成功写入结果，需要单独检查这几条的状态码，而不是直接认定它们已被覆盖。差集处理完后，把未覆盖URL导出为新清单，作为下一轮扫描的输入。

这个结果会直接影响下一步：如果未覆盖量小且集中在同一目录，可以只补扫该目录；如果差集分散且无法定位中断点，重扫全站比拼接两轮结果更省事，也避免遗漏。

结果异常时先排除这几种解释

中断后常见一种反直觉现象：结果文件里的URL数量比预期多，或者某些页面重复出现。这不一定代表覆盖更全，可能是以下原因。

• 重定向被同时记录为原URL和目标URL，造成数量虚高。
• 分页、筛选参数被当作独立URL重复抓取。
• 上一轮扫描的残留结果没有清空，和新结果混在一起。
• 并发写入时部分记录被覆盖或截断，出现同URL不同状态。

要区分这些解释，可以随机抽取若干条记录，检查其状态码、响应时间和URL参数。如果同一路径带不同查询参数反复出现，说明URL规范化没做好，覆盖范围应按规范化后的路径统计，而不是按原始记录条数。若发现上一轮残留，先清空结果目录再判断，否则任何数量对比都不可靠。

把判断结果落成可执行的下一步

完成差集和异常排查后，手上应该有两份东西：一份是确认已覆盖的URL清单，一份是待处理清单。接下来按待处理清单的范围决定动作。

1. 待处理量小于总量的两成，且集中在少数目录：只补扫这些目录，补扫完成后用同一差集方法再核对一次。
2. 待处理量超过总量的一半，或中断点无法定位：清空结果，重新全站扫描，并在扫描前开启逐条日志。
3. 结果中存在重复或异常记录：先修正URL规范化规则，再重新扫描，否则补扫只会继续产生重复。

补扫或重扫结束后，用同样的差集方法验证覆盖是否完整。如果两次差集结果一致且待处理清单为空，才能认为覆盖范围可确认；否则继续按清单迭代。这个动作的结果决定了是收尾还是再来一轮，而不是靠进度条是否走完来判断。

下次扫描前先做一件事

在启动扫描前，确认工具是否支持把已处理URL逐条写入独立文件，或至少保留带时间戳的日志。如果不支持，就在扫描前手动导出URL清单，并在扫描过程中定期复制结果文件。这样即使中断，也能用清单和副本做差集，而不必从头再来。具体工具是否提供这些能力，需要以你实际使用的版本和界面为准，不能仅凭名称或宣传判断。