列表型站点（商品列表、文章归档、标签聚合）的抓取路径，很多时候是靠分页一层层往下走的。日常检查往往只看第二页能不能打开，却忽略了第三页之后链路是否还能接上，结果是入口页被反复抓取，尾部页面迟迟不进抓取队列。分页断点不是“能不能访问”的问题，而是“路径能不能连续”的问题。
分页接续断点的常见形态
- 下一页链接由脚本注入：原始 HTML 里只有第 1 页的地址，后续页码靠前端渲染补齐，抓取端如果不等渲染就会停在第一页。
- 滚动加载没有可请求的分页地址：内容由接口追加，页面本身不存在可带页码的 URL，路径无法延展。
- 页码越界统一跳回第一页：超过末页时全部重定向到第 1 页，抓取端容易把这条路径视作环路，减少对后续页码的抓取。
- 末页之后返回 200 空页或软 404：内容为空但状态码正常，抓取端判断不出分页已经结束。
- 带页码的路径被规则整体排除：列表页可以抓，但含参数的页码地址在 robots.txt 或站点规则里被屏蔽。
为什么断点不容易被发现
一是抓取日志通常按状态码和频次排序，断点表现为“某批 URL 从不出现”，属于缺失型问题，不会主动报警；二是从用户视角看，滚动加载和点击分页体验都正常，站点运营侧很难感知；三是当分页由接口驱动时，即使前端能看到更多内容，抓取端拿到的仍是同一份静态结构。
从日志侧观察缺失
把抓取日志按路径前缀聚合，统计列表页第 1 页到第 N 页的命中分布。如果第 1 页的抓取量远高于第 2 页，而第 2 页之后几乎为空，基本可以判断分页接续在某处断开。再对照服务器访问日志中的真实请求，确认是抓取端没来，还是来了被拦。
从可达性侧验证
关闭脚本执行，用抓取视角请求列表页，查看返回的 HTML 中是否包含指向下一页的可点击地址；再顺着这些地址连续请求若干页，确认每一跳都存在下一跳。
排查与修复顺序
- 确认分页地址是否可请求：为每页生成稳定、能被直接访问的 URL，而不是仅靠交互触发。
- 补齐静态链接：在列表页 HTML 中输出“下一页”和页码链接，脚本渲染作为增强而非唯一入口。
- 修正越界行为：末页之后返回 404 或明确终止分页，不要统一重定向回第一页。
- 检查规则与状态码：确认分页路径未被 robots.txt 屏蔽，空页不要返回 200。
- 建立回链：让详情页有回到所属列表页或相邻条目的链接，避免路径只靠分页单向延伸。
- 在站点地图中补充必要的分页入口，但只保留有独立价值的页码，避免把无意义的翻页全部提交。
长期维护的几个习惯
- 把分页深度作为固定观测项，而不是只在改版时检查一次。
- 列表页改版后，重点回归“下一页”的链接是否仍在服务端输出。
- 控制单页条数，避免为减少页数而把单页体积做得过大。
- 分页地址保持稳定，不要频繁更换参数命名，否则已发现的路径会全部作废。
分页链路的价值在于让抓取端知道内容往哪儿走、走到哪儿停。它不能保证收录，但可以避免内容因为路径不通而长期缺席。
分页断点通常不会带来明显报错，只会让抓取范围停在入口附近。定期用抓取视角顺着页码走一遍，比事后分析抓取量下滑更省事。