列表页是站内新 URL 被发现的主要通道之一。当分页链接不能以可抓取的形式出现在 HTML 里，蜘蛛往往只能停在第一页，后面的详情页即使内容质量不错，也很难进入抓取队列。这类问题通常不会报错，表现也更隐蔽：抓取量看起来正常，但新 URL 增长缓慢，或者收录集中在最近更新的那几篇。
第一步：确认翻页链接是否真的在 HTML 里
排查要从源码开始，而不是从浏览器里看到的页面开始。浏览器里能点、能翻，不代表蜘蛛能看到。
- 关闭 JavaScript 后再请求列表页，检查第 2 页及之后的链接是否出现在返回的 HTML 中。
- 区分「上一页 / 下一页」与页码锚点两种形态。只有上一页下一页时，蜘蛛需要逐页推进，深层列表的路径长度会明显增加，抓取预算消耗也更慢。
- 检查翻页控件是 a 标签带 href，还是 button、div 加事件绑定。后者没有可解析的链接地址，蜘蛛无法把它当作一条路径。
- 确认分页 URL 是否稳定。每次请求都带随机数、时间戳或会话参数的分页地址，会让同一个列表页被反复当作新入口。
几种常见的翻页断链形态
只渲染首屏分页
前端框架先输出第一页数据和前几个页码，后续页码靠滚动或点击「加载更多」再渲染。如果服务端返回的初始 HTML 里没有这些页码链接，抓取路径在第一页之后就直接断掉。判断方法很简单：在源码里搜索分页容器的 class 名，看真实链接数量。
无限滚动没有静态兜底
整页滚动加载的列表，通常在 HTML 里一条链接都没有。可行的做法是保留一个分页版本作为兜底地址，例如给列表加上可访问的页码参数，并在滚动加载失败或未执行脚本时输出这些链接。
分页与筛选参数混用
筛选条件、排序方式、页码常常拼在同一个 URL 上，组合数量迅速膨胀。蜘蛛会把其中一部分当作独立入口抓取，稀释真正需要抓取的分页路径。建议让基础分页地址保持干净，筛选结果通过内链少量暴露，而不是让每个组合都成为可点击链接。
核对与验证顺序
- 先确认列表页本身能被抓取，排除 robots、状态码、跳转等前置问题。
- 再关闭 JS 抓取源码，统计源码里实际存在的分页链接数量与最深页码。
- 用站点日志或抓取日志，查看蜘蛛对同一列表的访问是否出现了第二页、第三页的请求记录。
- 抽样查看几个深层详情页，确认它们是否有除列表页之外的其他内链入口，例如相关推荐、标签页、归档页。
- 对照 Sitemap，看分页地址和深层详情页是否只依赖单一入口。若只靠列表推进，任何一次断链都会让整段 URL 失联。
修复时值得优先处理的方向
- 把分页控件改成带 href 的链接，保持服务端可输出，脚本再在此基础上做拦截和增强。
- 在列表页底部保留一组页码链接，让深层分页有稳定的短路径可达。
- 为详情页补充横向入口，比如同栏目推荐、上下篇、标签聚合，降低对列表翻页的单一依赖。
- 控制每页条目数，让同样的详情页数量对应更少的分页层级，减少路径深度。
- 修正后再观察日志，确认第二页之后的请求记录是否稳定出现。
分页路径恢复后，蜘蛛访问列表页的频次通常会更稳定，但这并不等于详情页一定被收录。抓取只是把 URL 送进队列，最终是否保留还要看页面自身的内容与重复度。
把这件事当作一次路径核对来做，比反复刷新日志更有效：先确认源码里有链接，再确认日志里有访问，最后确认这些 URL 有不止一条入口。三步都对齐，列表页到详情页的抓取通路才算真正打通。