列表页翻页，往往是站点里数量最大的一批 URL。一个 200 条内容的栏目，每页 10 条就是 20 个分页地址；如果再叠加筛选和排序，数字会迅速膨胀。这些页面有内链、返回 200、也能正常抓取，于是围绕它的收录问题就来了：该不该让它进索引？canonical 怎么指？要不要 noindex？
分页 URL 在收录里是什么角色
不管形式是 ?page=2、/page/2/ 还是 ?paged=2，分页页承载的都是同一批列表内容的不同切片，和第 1 页并不是两套内容。这一点决定了它的定位：它是通往深层内容的路径，而不是需要参与排名的独立页面。
理解这一点后，很多纠结会变得简单——真正要关心的是它有没有帮忙把详情页、商品页、文章页送到蜘蛛面前，而不是它自己有没有出现在搜索结果里。
rel=prev/next 已经不是可以依赖的方案
早些年常用 rel="prev" 和 rel="next" 声明分页关系。Google 在 2019 年已明确表示不再把这些标记当作索引信号，Bing 也基本淡化了它的作用。也就是说，现在不会出现“加了 prev/next 就自动合并”的效果，分页 URL 的处理得换思路。
canonical 的几种常见误用
- 所有分页都 canonical 到第 1 页：等于声明后续页面都是第 1 页的重复版本。索引里的分页数量可能变少，但这些页面上的链接也可能被当作重复内容路径看待。
- 把第 1 页 canonical 到某个“全集页”：如果第 1 页本身就是用户访问的主要入口，这样声明只会制造矛盾。
- 分页页之间互相指向：分页不是父子关系，互指只会产生混乱信号。
相对稳妥的做法是让每个分页页保持自指 canonical，即指向自己的 URL。既不强行合并，也不制造错误声明，剩下的交给搜索引擎判断。
要不要 noindex 分页
这是最常被问到的问题，需要先把两件事分开看：
- 分页被索引：索引里多出一些展示型 URL，搜索价值有限，但通常不至于造成严重后果。
- 分页被屏蔽：链接发现路径受影响，深处的详情页可能需要更长时间才被抓到。
如果分页是通往深层内容的唯一路径，直接 noindex 甚至用 robots 屏蔽，往往会让收录推进变慢，而不是变好。
更实际的做法是：分页保持可抓取、可索引，但不主动去推销它——不写进 sitemap，不在导航里单独给分页做入口，也不指望它自己拿到搜索流量。
比调标记更有效的：减少分页数量
如果分页本身就过量，调整 canonical 只是打补丁。可以从几个方向压缩：
- 提高每页条数，把 20 页缩成 5 页；
- 用“加载更多”或滚动加载代替翻页，同时保留一套服务端可返回的分页 URL 作为回退；
- 合并内容高度重叠的栏目，减少重复列表；
- 给筛选和排序加上明确的 URL 规则，避免同一批内容生成几十种地址。
第 2 点需要留意：纯 JS 加载的分页如果服务端不返回对应内容，蜘蛛很可能只看到第一页。保留可访问的分页 URL 仍然是必要的。
用抓取日志和索引状态来判断效果
- 看抓取日志里分页 URL 占用多少比例，如果过半抓取都花在 ?page= 上，值得处理；
- 看“已抓取未索引”里分页地址的数量变化，判断它是被主动忽略还是被判为重复；
- 看深层详情页被抓取的时间间隔，如果明显拉长，说明发现路径可能被分页占据了。
一个简单的处理顺序
- 先统计站内分页 URL 的总量和生成规则；
- 确认分页是否为深层内容的必要入口；
- 把 canonical 改回自指，去掉互指和全部指向第 1 页的写法；
- 分页不列入 sitemap，也不单独做站内入口；
- 在可行范围内减少分页数量；
- 持续观察抓取分布和索引状态，不要一次性改动全部规则。
分页收录没有一刀切的答案，但有个判断标准可以长期使用：它有没有在帮你把真正的内容送到蜘蛛面前。有，就留着；没有，再谈压缩和收敛。