网站分页的 SEO 到底该怎么做：rel=next/prev 废弃之后，列表页收录的那些坑

几乎每个内容站都有分页：文章列表第 1 页、第 2 页……一直排到第 20 页。这件事看起来平平无奇，但在 SEO 上却是个长期被误解的区域。很多站长还在照抄 2015 年的教程，往页面 head 里塞 rel="next" 和 rel="prev"，却不知道 Google 早在 2019 年就宣布不再使用这两个标签了。

这篇文章讲清楚三件事：分页链接在搜索引擎眼里到底是什么、现在该怎么标记、以及分页最容易引发哪些收录事故。

一、先破一个过时的观念：rel=next/prev 已经失效

2011 年，Google、Bing、Yahoo 联合推出 rel="next" 和 rel="prev" 微格式，目的是让爬虫把一系列分页看成「一组」，把权重合并到第一页。当年这确实是标准做法。

但 2019 年 3 月，Google 官方明确宣布：不再把 rel=next/prev 作为索引信号。原因很简单——Google 的爬虫现在已经能自己识别分页结构了，通过链接关系、URL 参数、页面内容相似度就能判断出「这是第几页」，不需要你手动标注。

所以现在的情况是：

• 写了 rel=next/prev，没有坏处（不会被惩罚），但也没有直接好处。
• 搜索结果的展示、权重分配，Google 走的是自己的判断逻辑，不看你这两个标签。
• Bing 早期也用过，现在同样弱化了。

我的建议是：如果你用的是新模板，就别特意为 SEO 加它了；如果是老主题自带的，也不用急着删，毕竟没坏处，而且对某些非主流爬虫可能还有一丝参考意义。真正重要的是下面这几条。

二、分页页面的 canonical 该怎么写

这是分页 SEO 里最核心的问题：第 2 页、第 3 页该不该有自己的 canonical？

答案是：每一页都应该 canonical 到自己。也就是说，/list?page=2 的 canonical 就写 /list?page=2，不要全部指向第 1 页。

为什么？因为每一页的内容其实是不同的——第 2 页展示的是第 11 到 20 篇文章，这个列表本身就是独立内容。如果你把第 2 到第 20 页的 canonical 全指向第 1 页，等于告诉搜索引擎「后面这些页面是重复内容，别收录」。结果就是：这些页面里的文章链接虽然还能被爬虫顺着爬，但你等于主动放弃了这些列表页可能带来的长尾流量。

举个真实场景：一个做教程的站，有人搜索「某工具教程 合集 第二页」这种需求很少，但有人搜「某关键词 site:你的站」，如果第 2 页被正确收录，你多出来的入口就多一个。更重要的是，不要人为限制爬虫只能通过首页往外爬，那样内页的发现速度会明显变慢。

正确写法（每一页指向自身）：

<!-- /list?page=2 页面的 head 里 -->
<link rel="canonical" href="https://example.com/list?page=2" />

同时别忘了对排序、筛选参数要区别对待。?page=2 是分页，应该保留；而 ?sort=hot&order=desc 这类纯排序参数，通常应该 canonical 到不带参数的干净 URL，因为排序只是视图变化，内容集合是一样的。

<!-- /list?sort=hot 应该指向标准列表页 -->
<link rel="canonical" href="https://example.com/list" />

三、最常见的分页灾难：第一页有两个 URL

这是我在多个站点的 Search Console 里反复看到的问题。列表页第一页往往有两个可达 URL：

• https://example.com/list
• https://example.com/list?page=1

两者内容完全一样，但 URL 不同。如果两个都没做 canonical 收敛，就会被当成两个重复页面，权重分散。更糟的是，站内链接有时指向这个、有时指向那个，爬虫会来回爬两遍。

解决办法是选一个当主 URL，另一个 301 到主 URL（或者至少 canonical 过去）：

# Nginx 里把 ?page=1 301 到干净路径
location = /list {
    if ($arg_page = 1) {
        return 301 https://example.com/list;
    }
    # 原有处理继续
}

这里要小心一个坑：page=1 的重定向不能写成无限循环。如果 301 的目标又带上了 page=1，就会 Self-referencing loop。上面用 location = /list 精确匹配，并且直接返回不带参数的地址，是安全的。

四、view-all 页面：要不要做一个「查看全部」

早期 Google 建议站长提供 view-all 页面（把全部内容放在一个页面）来帮助爬虫发现内容，同时用 rel=canonical 指向 view-all。但 2019 年之后这个建议也作废了。原因很实在：

• 一个页面塞 500 条内容，移动端性能会崩（LCP 直接爆掉）。
• 页面体积过大，爬虫抓取消耗的抓取预算反而更高。

所以现在的做法是：不要为了 SEO 特意做 view-all 页面。如果你的产品经理（或者你自己）觉得用户需要「全部展开」的体验，那就用前端「加载更多」按钮，让内容通过 JS 动态加载，但要注意——JS 渲染的内容爬虫不一定抓得到完整。稳妥的做法是既提供分页链接（静态可爬），又在视觉上做无限滚动，然后在页面里保留真正的 <a href> 分页导航。

五、分页导航必须是真链接，不能用 JS 跳转

我见过不少主题，分页用的是这样的代码：

<!-- 反例：javascript:void(0) 或 onclick 跳转 -->
<a href="javascript:void(0)" onclick="goPage(2)">下一页</a>

这种写法对爬虫来说是死路——它看不到 URL，也就无法顺着爬到第 2 页。正确写法必须是带真实 href 的链接：

<nav class="pagination" aria-label="分页导航">
  <a href="/list?page=1">上一页</a>
  <a href="/list?page=2">2</a>
  <a href="/list?page=3">3</a>
  <a href="/list?page=4">下一页</a>
</nav>

另外建议给分页容器加上 aria-label，一是无障碍友好，二是顺便给搜索引擎一个语义提示。

还有一个细节：「下一页」链接不要用相对路径的坑。在 /list?page=2 页面上，如果「下一页」写成 href="?page=3"，浏览器会解析成 /list?page=3，这没问题；但如果你写的是 href="page=3"，就会变成 /page=3，直接 404。这类 URL 拼接错误在小站上非常常见，一错就是几十个 404，白白浪费抓取预算。

六、分页和抓取预算：什么时候该 noindex

分页页面要不要被收录，取决于你的站有多大：

• 中小站（几千篇以内）：让分页被正常收录，没什么坏处，还能多几个进入内页的入口。
• 大型站（几万篇以上）：深分页（比如第 50 页往后）价值极低，反而分散抓取预算。这时候可以考虑对深度超过某个阈值的分页页面加 noindex, follow。

注意这里的组合：noindex 但不 nofollow。因为你要的是「不要索引这个列表页，但请继续顺着链接爬里面的文章」。如果写成 noindex, nofollow，爬虫到了第 50 页就不再往深处走了，深层的文章可能永远发现不了。

<!-- 深度分页：不索引，但保留链接爬取 -->
<meta name="robots" content="noindex, follow" />

反例是很多人喜欢用 robots.txt 去 Disallow 分页：

# 错误示范
Disallow: /*?page=

千万别这么干。Disallow 之后 Googlebot 根本抓不到那个页面，也就看不到页面上指向深层文章的链接，深层内容的发现直接断链。想让页面不被索引，永远优先用 noindex 而不是 Disallow，这是基本原则。

七、动手检查清单

最后给你一份可以直接照着查的清单：

1. 打开 Search Console → 网页 → 已编入索引，看有没有大量 ?page= 的「重复网页，Google 选择的规范网页与用户指定的不同」提示。
2. 随便抽 3 个分页 URL，用浏览器 view-source 确认 canonical 指向的是自己，不是第一页。
3. 确认 ?page=1 和干净 URL 没有同时被索引。
4. 确认分页导航是真实 <a href>，不是 JS。
5. 确认没有用 robots.txt 屏蔽分页。
6. 在 GSC 的「已发现 - 尚未编入索引」里看分页 URL 是否堆积过多，过多说明抓取预算被分页吃掉了。

分页这事，说起来都是小细节，但架不住量多。一个站有 100 个列表页，每个都错一点，累积起来就是可观的抓取浪费。花半小时把上面六条对照一遍，比你再写十篇内容带来的收益可能还直接。