爱站工具：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Safari/605.1.15 (Applebot/0.1; +http://www.apple.com/go/applebot)
🔗 /66533e70ba28.html
📄
爱站工具：一次全站扫描被中断后怎样判断已覆盖范围
扫描中断后，不要凭“跑了多久”或“页面数字看起来差不多”下结论。更可靠的做法是把已产出的结果按URL、状态和层级三类证据分开核对，再决定保留、改写还是退出这次扫描。判断标准不是覆盖了多少比例，而是未覆盖部分是否集中在会影响你决策的那一类页面上。
先分清中断发生在哪一层，再谈覆盖
全站扫描通常不是一条直线，而是“发现链接—请求页面—解析结果—写入记录”四个环节。中断可能发生在任意一环，不同环节留下的证据完全不同。
- 发现层中断：已抓到的URL列表可能只覆盖了入口附近几层，深层页面根本没进入队列。此时结果里“没有报错”不代表页面正常，只代表没被看到。
- 请求层中断：URL在队列里，但部分请求未发出或未返回。表现为同一目录下有的页面有状态码，有的完全空白。
- 解析与写入层中断：页面已请求成功，但标题、状态或链接数据没落盘。这类缺口最隐蔽，因为URL数量看起来完整。
先确认中断属于哪一层，后面的判断才有意义。如果连这一层都分不清，直接补跑往往只是重复消耗。
用三类可核对证据圈出实际覆盖范围
把分歧转成可核对的项目，关键是找到“能互相印证”的证据，而不是依赖单一数字。
- URL清单与站点地图对比。把扫描产出的URL与站点地图或栏目页列出的链接做差集。差集集中在某一目录，说明覆盖缺口有结构规律；差集零散分布，则更像请求波动。
- 状态码分布。统计已返回状态码的页面占比。注意：状态码齐全不等于内容解析完整，它只能证明请求层走通了一部分。
- 层级深度。记录已覆盖页面距离入口的最大点击深度。如果中断前只到第三层，而你的重点页面在第五层，那么这次结果对决策的价值有限。
假设一次扫描在约四成URL处中断，且缺口全部集中在分页列表的深层。这时“覆盖四成”这个说法会误导人：真正影响判断的列表页可能一条都没抓到，而已经抓到的静态页并不需要复查。数字本身不说明问题，缺口的位置才说明问题。
保留、改写还是退出：三种取舍的适用前提
不必强行把三种选择都用上，按证据选一种即可。
- 保留：适用于缺口集中在低优先级页面，且已覆盖部分足以回答你当前的问题。保留时要标注扫描截止位置和未覆盖目录，避免后续有人把结果当成全量。
- 改写：适用于缺口有规律，比如某类模板页全部缺失。此时可以缩小扫描范围，只针对该目录重跑，而不是整站重来。改写的前提是你能明确说出“缺的是哪一类”。
- 退出：适用于中断原因未查明、且缺口恰好落在核心页面上。在原因不明时补跑，很可能在同一位置再次中断，得到第二份同样不完整的记录。
一个实际动作是：先导出已覆盖URL清单，标出与站点地图的差集目录，再决定是否只对该目录发起一次范围更小的扫描。这个动作的结果会直接告诉你缺口是结构性的还是偶发的，从而决定下一步是补跑还是换入口。
把分歧变成可核对项，而不是各说各话
多个角色对“扫了多少”有不同理解，通常是因为各自看的是不同证据：有人看运行时长，有人看URL总数，有人看报错列表。统一口径的办法是约定一张最小核对表，例如：扫描起止时间、已写入URL数、有状态码URL数、与站点地图的差集目录、最大覆盖深度。
需要提醒的是，请求量或抓取量突然归零，并不能单独证明扫描已经完成或处理正确。它也可能是被目标站点限流、网络中断或队列耗尽造成的。遇到这类现象，应结合差集目录和状态码分布一起看，而不是只看一个归零的计数。
至于具体工具在中断后是否保留断点、能否续跑、结果如何导出，不同版本和权益范围可能不同，需要以你当前实际使用的界面和说明为准，不要凭印象假定。
决定之后，留下可复查的边界说明
无论选择保留还是改写，都应在结果旁写清这次扫描的边界：覆盖到哪些目录、止于哪一层、哪些结论不能由这份数据支撑。这样下一次复查时，接手的人能直接看出缺口在哪，而不必重新争论“到底扫全了没有”。判断覆盖范围的目的不是证明扫描完整，而是知道哪些结论现在还不能下。
