列表页、频道页、聚合页往往承担着把内容铺开的任务。蜘蛛从一个入口进来，能不能沿着翻页链接一路走到第 20 页、第 50 页，直接决定这些页面背后的详情页有没有机会被发现。分页看起来是前端实现的小事，落到抓取环节却很实在。
分页链接是列表页 URL 发现的主干
一个频道页只有几十条链接时，蜘蛛一次抓取就能全部看到。当内容累积到几千条，列表被切成几十上百页，真正的入口就变成了那些“下一页”“2 3 4 5”的链接。如果这些链接只在前端渲染，或者被脚本接管，蜘蛛看到的可能永远只有第一页。
判断方式很直接：用不执行 JS 的方式请求列表页，看返回的 HTML 里是否含有后续页面的 可点击链接。没有链接，就没有路径。
三种翻页实现，区别在链接是否可解析
传统 a 标签翻页
每页底部一组指向 page=2、page=3 的 a 标签，是最稳妥的做法。层级清晰，蜘蛛可以逐页跟进，页面之间的先后关系也容易理解。需要留意的是分页地址不要层层带上多余的追踪参数。
点击加载更多
按钮触发请求拿数据再插入 DOM。如果按钮本身不是链接，蜘蛛不会去点它。可行的做法是给“加载更多”配一个真实的分页地址，让不执行脚本的环境也能走到后续内容。
无限滚动
滚动到底自动加载，用户体验顺滑，但地址栏不变，蜘蛛没有新地址可跟。常见的补救是额外提供一个分页版地址，或在 Sitemap 中单独提交重要的列表分页 URL。
分页参数与规范化
同一个列表，可能因为排序参数、筛选参数、会话参数组合出多个地址。蜘蛛抓到这些变体，容易把抓取量花在重复内容上。可以用 canonical 指向主分页地址，同时让排序类参数产生的结果保持可访问但优先级更低。
另外要注意分页地址不要被 robots.txt 或 noindex 误伤。有些站点为了控制抓取量屏蔽了带参数的地址，结果连正常的翻页也一起挡在外面，后面的内容就彻底没有入口了。
翻页请求对服务器的压力
列表页通常是动态查询，翻一次页就是一次数据库扫描。蜘蛛连续翻页时，如果响应明显变慢，抓取节奏也会跟着放缓，越往后的页面越难被走到。给列表页做缓存、限制单页查询深度、避免深分页的 offset 过大，往往比事后反复调参更有效。
自查清单
- 用不执行 JS 的方式请求列表页，确认底部是否存在指向后续页的 a 链接。
- 翻到最后一页，确认“下一页”是自然消失，而不是返回重复内容或错误页。
- 检查分页地址是否被 canonical、robots.txt 或 meta 指令误伤。
- 在 Sitemap 中补充重要的列表分页地址，尤其是无限滚动的页面。
- 观察服务器日志，看蜘蛛是逐页推进，还是长期停在第一页。
分页不是给蜘蛛看的装饰，而是列表内容被发现的实际通道。通道断了，后面的页面就只能靠其他入口兜底。
分页设计的核心问题只有一个：从第一页到最后一页，是否存在一条蜘蛛能走通的链接路径。把这条路径理顺，比事后到处补 Sitemap 更省事。