列表頁翻頁，往往是站点里數量最大的一批 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，也不單獨做站内入口；
- 在可行范围内减少分頁數量；
- 持續观察抓取分布和索引狀態，不要一次性改動全部規則。
分頁收錄没有一刀切的答案，但有個判断标准可以長期使用：它有没有在帮你把真正的内容送到蜘蛛面前。有，就留着；没有，再谈压缩和收敛。