权重查询一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c7da8e49557e.html
📄
权重查询一次全站扫描被中断后怎样判断已覆盖范围
中断后不要先重跑，先判断“已覆盖范围”是否足够支撑当前决策。判断依据不是扫描进度条，而是任务清单、结果落盘和重复检测记录三者的交集。以下用一个假设情境说明取舍。
先定一个假设情境：中断发生在哪一步
假设你用某类权重查询工具对约两千个URL做全站扫描，任务跑到一半因网络或会话失效中断。此时你手里可能只有一份不完整的结果文件，工具界面是否保留断点、能否续跑、是否按批次落盘，需要按你实际使用的工具核对，不能默认它有断点续传。中断点本身不说明覆盖范围，覆盖范围要看“哪些URL已经产生了可判定的结果”。
把URL清单当作基准表，给每个URL标注三种状态：已出结果、已请求但无有效结果、未请求。只有第一种能计入覆盖，第二种要单独列出来，因为它最容易被误当成已完成。
用三个证据判断覆盖到哪
结果条数与清单条数对不上时先查重复
结果文件里的记录数少于清单数，通常说明确实没跑完；但记录数接近甚至超过清单数，也不能直接认定全覆盖，可能包含重定向产生的重复行、同一URL的多次请求或参数变体。可行的动作是：以规范化后的URL为键做一次去重计数，再与清单比对。如果去重后仍缺若干条，缺的那部分就是明确未覆盖区；如果去重后数量吻合但顺序混乱，可认为覆盖基本完整，下一步转为校验结果质量。
看请求日志的连续性，而不是看百分比
很多工具显示的进度百分比按批次估算，中断后可能停在一个不可信的位置。更可靠的是请求日志：按时间排序，看最后成功返回的批次编号，以及之后是否还有发出但未返回的请求。若日志显示连续批次到某一编号后中断，且没有后续请求，覆盖范围大致等于该编号之前的清单区间。若日志断点前后出现跳批，说明中间有URL被跳过，需要把跳过的区间单独补扫。
区分“无结果”和“未覆盖”
权重查询中，部分URL可能因超时、被拒或本身无可用数据而没有输出。这类URL属于“已请求但无有效结果”，不能算覆盖，也不能直接当作零权重处理。判断方法是看该URL是否有请求记录：有请求记录但无结果，属于待复核；完全没有请求记录，属于未覆盖。两者后续动作不同，前者考虑重试或换判定口径，后者直接补入下一轮清单。
决定补扫还是接受当前范围
是否补扫取决于这次查询要支撑什么决策。如果只是看全站权重分布的大致形态，已覆盖部分若集中在主要栏目且缺口是零散长尾，通常可以先用现有结果做趋势判断，但要注明缺口位置。如果要做逐条URL的处置，比如决定哪些页面需要调整，那么任何未覆盖或待复核的URL都不能进入结论，必须补齐。
一个可操作的分界是：把未覆盖和待复核的URL按栏目或目录聚合。若缺口集中在少数目录，补扫这些目录即可，不必全量重跑；若缺口分散且无规律，说明中断点与URL结构无关，全量重跑更省判断成本。这个取舍的结果会直接影响下一步：局部补扫后要重新做一次去重计数，确认缺口闭合；全量重跑则要保留旧结果用于比对，避免新旧口径混用。
补扫前先固定清单和口径
- 导出中断前的URL清单，冻结为本次基准，补扫期间不再增删。
- 记录本次使用的判定口径，例如是否统计子域、是否跟随重定向，补扫沿用同一口径。
- 补扫只针对未覆盖与待复核两类，已出结果的URL不重复请求。
- 补扫完成后，把新旧结果合并再去重，用合并后的覆盖数对照基准清单。
如果合并后仍有缺口，优先怀疑清单本身在中断期间被改动过，而不是工具再次失败。核对清单的生成时间与冻结时间是否一致，能排除这一类误判。
什么情况下这次扫描结果应当作废
当无法确认中断点、日志缺失、结果文件没有URL标识，或者清单在扫描期间发生过变更时，已覆盖范围就无法可靠界定。此时继续在残缺结果上做判断，风险高于重跑成本，应当重新发起一次扫描，并在开始前固定清单、开启可追溯的落盘方式。反之，如果日志完整、清单冻结、缺口可枚举，就没有必要全量重来，按缺口补扫并复核即可。
