权重查询方法，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /51e5bf714d90.html
📄
权重查询方法，一次全站扫描被中断后怎样判断已覆盖范围
先把结论说清楚：扫描中断后，不要用“进度条走到哪”或“剩余时间”判断覆盖范围，因为这类显示通常按已排队任务估算，中断后可能回退、跳变或直接归零。更可靠的做法是拿一份你能核对的全量URL清单，与工具已产出的结果做差集，再对差集抽样判断是“真的没扫到”还是“扫到了但没写进结果”。下面以你手里的一份站点URL清单为对象，把这件事拆成可执行步骤。
先确认你手里有什么，再决定用什么当基准
判断覆盖范围的前提是有一个独立于扫描工具的基准。常见基准有三种：服务器访问日志、站点地图里的URL列表、你自己从站内链接或数据库导出的URL清单。三者覆盖范围不同，结论也会不同。
- 用服务器日志做基准：能反映工具实际请求过哪些地址，但日志可能被轮转、被CDN截断，也可能包含大量非页面请求。
- 用站点地图做基准：结构清晰、便于去重，但它只代表你声明希望被访问的URL，不代表站内真实存在的全部页面。
- 用自建清单做基准：最接近“全站”概念，但需要你确认清单本身没有遗漏栏目或分页。
如果这次中断发生在扫描早期，日志基准往往比站点地图更可信，因为工具可能还没来得及读取站点地图。反过来，如果中断发生在扫描后段，站点地图和自建清单的差集更能说明漏掉了什么。
把“已覆盖”拆成三个可分别验证的状态
“覆盖”不是一个是非题。中断后你至少要把URL分成三类，分别核对：
- 已产出结果：工具报告里能看到该URL的记录。注意这不等于结果正确，只说明它进入了输出。
- 已请求但无结果：日志里能看到请求记录，但报告里没有对应条目。常见原因是响应超时、被限流、返回了非预期状态码，或结果写入阶段被中断。
- 未请求：日志和报告里都找不到。这类才是真正需要补扫的部分。
把这三类分开后，你会发现“已覆盖范围”其实取决于你问的是哪一种。若你关心的是数据完整性，第二类才是风险最高的，因为它看起来像扫过了，实际没有可用记录。
用差集和抽样区分“没扫到”与“扫到没写入”
具体动作：把基准清单和工具结果各导出为一份纯文本URL列表，统一去掉协议、www前缀和结尾斜杠，然后做差集。差集里通常同时混着上面第二类和第三类。这时不要急着补扫全部差集，先抽样。
抽样方法可以这样设定（以下为假设示例，仅说明比较方法）：从差集中随机取50条，逐条在服务器日志里查该URL在扫描时间段内是否有请求记录。假设50条里有30条有请求记录、20条没有，那么可以粗略推断差集中约六成属于“已请求但无结果”，四成属于“未请求”。这个比例只用于决定下一步优先级，不能当作精确覆盖率，因为抽样量小、日志可能不完整。
根据这个结果决定动作：如果“已请求但无结果”占多数，优先检查限流、超时和结果写入环节，而不是直接重扫；如果“未请求”占多数，说明中断发生在任务调度阶段，补扫时应从差集里未请求的部分开始，而不是从头再来。
中断后重扫前，先处理会让结果失真的条件
直接重扫全部URL通常不是最优选择，因为上一次中断的原因如果还在，第二次很可能在相近位置再次中断。重扫前值得确认几件事：
- 扫描速率是否触发了目标站点的限流或防护，表现为大量超时或异常状态码。
- 上次中断是本地网络、工具进程还是目标站点导致的，这决定重扫时要不要降低并发。
- 结果文件是否已完整落盘，部分工具在中断时会留下不完整的临时文件，直接续扫可能产生重复或错位记录。
一个可操作的做法是：先用差集中“未请求”的部分做一次小批量试扫，观察请求成功率和结果写入是否正常。如果小批量稳定，再扩大到全部差集；如果仍然出现大量“已请求但无结果”，说明问题不在覆盖范围，而在采集条件本身，此时补扫只会重复产生无效记录。
把结论写成可复核的记录，而不是一个百分比
中断后的覆盖判断容易退化成“大概扫了七八成”这种无法复核的说法。更有用的记录方式是：基准清单总数、结果条目数、差集数量、差集抽样中已请求与未请求的比例、以及你据此决定补扫的范围。这样下一次中断时，你可以直接对比两次的差集结构，判断问题是偶发还是稳定存在。
需要提醒的是，请求量归零、结果条目骤减这类现象，不能单独证明扫描处理正确或错误，它们也可能来自日志轮转、结果文件未刷新、工具进程被系统回收等合理解释。把现象和基准差集放在一起看，才能得出站得住的结论。
