site命令查询：全站扫描中断后，怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9ec7d81094d9.html
📄
site命令查询：全站扫描中断后，怎样判断已覆盖范围
先给结论：中断后的site命令查询结果不能直接当作“已覆盖全站”的证据，它最多只能说明“在中断前，查询接口已经能返回哪些页面”。要判断覆盖范围，应该把中断前的样本、中断时的进度标记和中断后的补充查询分开看，再用可复现的小范围抽查验证，而不是把一次不完整的结果当成整站结论。
为什么中断后结果看起来“像全站”，却可能只是局部样本
一个常见矛盾是：中断前你抽查了几条URL，site命令查询都能返回，于是直觉认为“全站已经被抓取或收录”。但规模化之后，例外开始出现——某些栏目、分页、参数页或新生成的页面查不到。这并不一定说明整站有问题，更可能是扫描范围本身就没有覆盖到那些部分。
这里有两个成立条件不同的解释：
- 解释一：中断发生在覆盖完成之前。如果扫描是按URL队列、分页或时间片推进的，中断点之后的页面根本没有进入本次查询范围，缺失是“没查到”，不是“查不到”。
- 解释二：中断前已经覆盖，但结果本身有筛选或延迟。查询接口可能只返回部分结果、对相似页面做合并，或者数据更新滞后。此时缺失是“返回层”的问题，不是“扫描层”的问题。
这两种解释对应的处理动作完全不同：前者要补扫，后者要换验证方式。
用哪组证据区分“没扫到”和“扫到了但没返回”
能区分这两种解释的证据，不是再跑一次同样的全站查询，而是找中断点附近的边界样本。具体可以这样做：
- 从中断前最后一批已确认返回的URL里，挑3到5条，记录它们的路径特征，例如栏目层级、是否带参数、是否是分页。
- 从中断点之后、原本计划覆盖但尚未处理的URL里，挑同样数量的样本，单独做一次site命令查询。
- 比较两组样本的返回情况：如果中断前样本稳定返回、中断后样本大量缺失，更支持“覆盖未完成”；如果两组都大量缺失，更支持“返回层筛选或延迟”。
这个动作的结果会直接影响下一步：若判断为覆盖未完成，下一步是补齐队列后重新扫描，而不是调整页面；若判断为返回层问题，下一步是换用更细的查询条件或等待数据更新，而不是重复全站扫描。
一个注明假设的短例子：怎样估算已覆盖比例
假设一次计划扫描1000条URL，中断时进度标记显示已处理到第400条。中断后，你从已处理的400条里随机抽20条，site命令查询有18条能返回；从未处理的600条里随机抽20条，只有4条能返回。在这个假设下，可以粗略认为已覆盖范围更接近“已处理的那部分”，而不是整站。
但这个估算有前提：抽样必须随机，且中断后没有发生大规模改版或删除。如果未处理样本里恰好包含大量新生成页面，返回率低也可能只是时间差，不能单独归因于覆盖中断。因此这个比例只能作为下一步补扫优先级的参考，不能当作最终覆盖率。
哪些边界不能直接照搬
个别样本成立，不等于规模化后成立。以下几种情况尤其不能把中断前的局部结果直接推广到全站：
- 站点结构差异大：栏目页、详情页、分页和参数页的返回行为可能不同，用详情页样本推断栏目页覆盖会失真。
- 新页面占比高：如果中断后新增了大量URL，它们本来就不在本次扫描计划内，缺失与中断无关。
- 查询结果本身有上限：部分查询接口对返回条数或展示方式有限制，规模化后更容易触发，此时缺失不能证明页面未被处理。
- 中断原因未确认：如果是网络、配额或工具侧限制导致中断，补扫前应先确认限制是否仍然存在，否则重复中断会浪费一轮动作。
实际动作上，建议先记录中断时的进度标记和已处理样本的返回情况，再决定是补扫还是换验证方式。这个记录本身也是后续判断“覆盖范围是否扩大”的基线，比单次查询结果更可靠。
把判断落到可复现的下一步
判断已覆盖范围时，不要只问“site命令查询返回了多少条”，而要问“这些返回对应的是扫描计划里的哪一段”。如果中断点清晰、样本可复现，就可以用边界样本比较法给出一个带前提的覆盖估计；如果中断点不清晰，优先补齐进度记录，而不是直接下结论。只有把覆盖范围和返回结果分开记录，下一次中断时才不会再把局部样本误当成全站结论。
