SEO查询工具，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a3b8cc3c7736.html
📄
SEO查询工具，一次全站扫描被中断后怎样判断已覆盖范围
扫描中断后，不要凭“跑到第几页”或进度条位置估算覆盖范围，而要回到工具已经落盘的结果，用URL清单、抓取时间和状态字段重建实际覆盖边界。判断的核心是：你能否说清哪些URL已被处理、哪些只是被发现但未处理、哪些完全没进入扫描队列。只有前两类能进入后续分析，第三类必须重新扫描或单独补抓。
先分清三种记录，不要混在一起算覆盖率
全站扫描被中断时，工具通常会留下三类痕迹：已抓取并返回状态的URL、已发现但尚未请求的URL、以及只存在于站点地图或内链中但未被加入队列的URL。这三类的可信度完全不同。
- 已抓取URL：有明确的HTTP状态、抓取时间、响应大小。这类记录可以直接用于覆盖率计算和问题筛查。
- 已发现未抓取URL：出现在待抓取队列或链接列表中，但没有状态码。它们只能证明“被发现”，不能证明“被检查”。
- 未进入队列URL：只存在于站点地图、导航或数据库里，工具日志中没有出现。这类必须视为未覆盖。
实际动作：把导出文件按“是否有状态码”拆成两张表。有状态码的表用于计算已覆盖范围；无状态码的表单独标记为待处理。这个动作会直接决定下一步是补扫还是重新全量扫描。
用可核对证据判断中断发生在哪一层
中断可能发生在发现阶段、抓取阶段或写入阶段，不同层级的覆盖范围差别很大。可以用以下证据区分：
- 看最后一批成功记录的抓取时间。如果时间集中在中断前几分钟，说明抓取阶段被切断，已抓取部分通常可用。
- 看队列中是否还有大量无状态URL。如果无状态URL数量远大于已抓取数量，说明发现阶段可能已完成，但抓取远未完成。
- 看站点地图中的URL是否出现在导出文件里。随机抽取若干条站点地图URL，逐一在导出文件中查找。如果大量缺失，说明发现阶段也未完整覆盖。
- 看是否存在重复抓取同一URL的记录。重复记录多，说明中断前可能发生过重试或队列回滚，覆盖范围需要去重后再算。
假设一个站点有1000个已知URL，中断后导出文件中有420条带状态码记录，另有380条无状态码队列记录，剩余200条在站点地图中存在但未出现在任何导出文件中。此时可判断：已覆盖约420条，待确认380条，未进入扫描约200条。这个数字只是假设示例，用于说明比较方法，不代表任何工具的实际表现。
把已覆盖范围转成可执行的处理方案
判断覆盖范围的目的不是得到一个百分比，而是决定下一步动作。可以按以下顺序处理：
- 已抓取且状态正常的URL：直接进入标题、描述、内链、状态码等常规检查。这部分结果不受中断影响，可以优先处理。
- 已抓取但状态异常的URL：单独列出，核对是否因中断导致超时或连接重置。如果是，标记为需复抓，不要直接判定为死链或错误页。
- 已发现未抓取的URL：用同一工具或另一次扫描单独补抓。补抓前先确认这些URL是否属于同一域名、同一目录或同一模板，避免把站外链接混入。
- 未进入队列的URL：从站点地图、数据库或服务器日志中重新提取，与已覆盖清单做差集。差集结果就是必须重新扫描的部分。
实际动作：先对已覆盖的420条记录做一轮问题筛查，同时把380条待抓取URL和200条未进入队列URL合并成补扫清单。补扫完成后，用URL作为唯一键与第一次结果合并，去重后再计算最终覆盖率。这个动作的结果会直接影响你是否需要重新全量扫描：如果补扫清单能覆盖剩余部分，就不必重跑全站。
注意中断本身可能造成的假象
扫描中断后，有些现象容易被误读。例如，某些URL在导出文件中显示为404或超时，可能只是中断时连接被切断，而不是页面真的不存在。又如，抓取量突然归零，可能是工具进程被终止，也可能是目标站点临时限流或网络抖动。这两种解释对应的处理方式不同：前者需要补抓，后者需要先确认站点可访问性再决定是否重扫。
因此，在把任何异常状态写入报告之前，先做一次小范围复核：从异常URL中随机抽取少量，手动访问或单独请求，确认状态是否一致。如果手动访问正常，说明中断造成的误判概率较高，应把这些URL放回补扫清单，而不是直接归入错误页。
最终判断标准：能否说清每个URL的去向
覆盖范围是否判断清楚，不取决于进度条走了多少，而取决于你能否对每一个已知URL回答：它是否被请求过、返回了什么状态、如果没有被请求，是队列未处理还是根本未发现。当这三个问题都有明确答案时，已覆盖范围就是可核对的；当仍有大量URL无法归类时，最稳妥的做法是重新扫描或按差集补扫，而不是在不确定的数据上继续做决策。
