栏目的列表页看起来简单，但只要页数一多，翻页就会成倍地产生地址。一个 50 页的列表，再叠加排序、筛选和时间范围，很容易变成几百上千个 URL。这些地址是否被正确串联、边界是否清楚，既影响蜘蛛在站内的行进路线，也影响访客能不能顺着列表一直看下去。
先数一数分页会生出多少地址
动手改之前，先盘点现状。把几个主要栏目的翻页地址抓出来看一遍，重点记录这几件事：
- 每个列表栏目当前有多少页，最后一页的地址长什么样；
- 翻页靠的是路径（/list/2/）、查询参数（?page=2）还是文件名后缀（list_2.html）；
- 排序、筛选、时间范围这些条件，会不会和分页组合出新的地址；
- 输入一个超出末页的页码，服务器实际返回什么。
地址形式尽量统一
同一站内最好只保留一种翻页写法。混用会让同一批内容出现两套地址，链接和抓取都被分散。可以从下面几点收敛：
- 确定一种形式并全站沿用，例如统一用 /list/page/2/，或统一用 ?page=2；
- 第 1 页就是列表首页，不要让 /list/page/1/ 和 /list/ 同时存在；
- 参数分页要固定参数顺序和大小写，避免 ?page=2&sort=hot 与 ?sort=hot&page=2 被当成两个地址；
- 排序、筛选等条件组合，限制可参与翻页的维度数量。
翻页页面的标题、描述与 canonical
第 2 页往后，如果标题和第一页完全一样，搜索结果里很难区分。可以做几件小事：
- 标题里带上页码或内容区间，例如「某某栏目 第 3 页」；
- canonical 一般自指，指向当前这一页，不要全部指回列表首页；
- 描述按页码做简单区分即可，不必每一页都手写。
不要为了省事把第 2 页以后的页面全部 canonical 到首页，那等于告诉搜索引擎这些页面可以忽略，里面承载的内容链接也失去了入口价值。
把翻页的边界写清楚
- 末页之后不再输出「下一页」链接；
- 访问超出范围的页码，返回 404 或跳回最后一页，而不是给一个状态 200 的空列表——空列表容易被当成有效页面存下来；
- 翻页数量过多时，考虑只保留前若干页可翻，其余用分类页或标签页收口。
列表里要能走到详情页
翻页本身不是目的，把内容页串起来才是。检查每一页列表：
- 每页输出的条目数不要太少，避免把内容摊得太开、翻页层数被拉长；
- 列表里的链接是可直接点击的 a 标签，不是靠脚本点击才生成；
- 分页控件和条目在同一份 HTML 里，不要等 JS 执行完才出现。
「加载更多」与无限滚动
移动端常见的加载更多，如果只在浏览器里拼地址，蜘蛛往往看不到后面的内容。比较稳妥的做法是：
- 保留一份可翻页的地址，指向与加载更多相同的内容；
- 首屏之外的条目，至少让一部分链接出现在 HTML 中；
- 加载更多调用的接口地址不必刻意公开，但对应内容的可访问地址要真实存在。
从访问日志回看翻页情况
改完不等于结束。过一两周回到访问日志，看几个指标：主要栏目被翻到第几页、翻页请求的状态码分布、有没有大量 404 或者状态 200 的空页。如果某个栏目总是只被翻到第 2 页，多半是链接断在了那一页，或者参数地址被 robots 拦下了。也可以对照整体抓取频次，如果翻页请求占比很高而详情页很少，说明列表页在消耗抓取资源，可以适当收敛翻页深度，把入口留给内容页。
一份可以照着做的自查清单
- 翻页地址形式全站统一，只保留一套；
- 第 1 页不与 /page/1/ 这类地址重复存在；
- canonical 自指，不指回首页；
- 末页之后不再输出下一页链接；
- 越界页码返回 404 或 301，不返回空列表；
- 每页列表里的详情页链接在 HTML 中直接可见；
- 加载更多有可抓取的等价地址；
- 排序筛选与分页的组合数量可控；
- 定期从日志检查翻页深度和状态码分布。
这些事都不复杂，但需要一次做完、之后按节奏复查。翻页是列表和详情之间的桥，桥修得直不直，自己走一遍就知道。