很多站点在查收錄时都會遇到這样的情况：栏目第 2 頁、第 3 頁甚至第 20 頁都被收錄了，真正想推的詳情頁却一直停在“已發現”或者“已抓取，尚未编入索引”。分頁連結本身並不“坏”，問题通常出在數量、入口和差异度上——它們把抓取机會和索引名額占掉了，而分頁頁面對搜尋用戶的價值往往有限。
先判断：這類分頁有没有獨立检索價值
不要把“分頁”当成一個整体来處理，先按下面的标准分一分：
- 有獨立需求的：每一頁的标题、描述和内容组合都不同，能獨立回答某類查询的分頁，值得保留。
- 没獨立需求的：只是把同一批内容按時間或 ID 切段的翻頁，第 5 頁和第 6 頁除了顺序外没有差別，這類頁面基本不需要出現在索引里。
- 纯導航型的：论坛、评论、相册的翻頁，多數属于這一類。
為什么分頁容易被大量收錄
常见原因有三個，按出現频率排序：
- 入口太多太密。列表底部一次放出 10 個頁碼連結，再加上“下一頁”“尾頁”，一個栏目就能产生十几條可抓取入口。
- 模板相似、差异极小。翻頁頁面的正文区只換了几條條目，标题往往只有一個數字之差。
- URL 形態不统一。同一份列表可能同时存在 ?page=2、/page/2/、?p=2 几套地址，等于把分頁數量翻了几倍。
注意最後一点，它带来的問题不是“多收錄了几頁”，而是抓取和索引被分散到了同一批内容的不同地址上。
處理顺序：從收口入口到收敛索引
第一步：统一分頁 URL 形態
同一個列表只保留一種分頁寫法，其余寫法通過 301 归並到保留的那一種。這一步不做，後面的判断都會受到干扰。
第二步：检查 sitemap 與站内連結
把分頁 URL 從 sitemap 里清出去，让 sitemap 只承担“希望被索引的頁面”的职责。同时检查列表頁底部的頁碼連結：是否需要一次展示 10 個頁碼，還是只保留上一頁、下一頁和首尾頁即可。
第三步：决定“保留還是收敛”
- 對無獨立價值的分頁，頁面上加 noindex, follow，保留連結可抓取，但不進入索引。
- 如果分頁只是同一内容的切段，也可以考虑把它們全部規范化到主列表頁。但要清楚代價：canonical 指向第一頁後，後面几頁的内容不會再作為獨立頁面參與索引。
- 确實有獨立價值的分頁，保留並让它的标题、描述能反映目前頁的内容范围。
canonical 指回第一頁並不是萬能解法。当後頁包含大量第一頁没有的條目时，這样做等于主動放弃這些條目被單獨發現的机會。先用“有没有獨立需求”回答，再决定要不要指。
第四步：處理 JS 加载和滚動加载的列表
如果列表是通過無限滚動或按钮加载的，要確認後加载的内容有没有對應的可抓取 URL。没有的话，這部分内容對搜尋而言等于不存在；有的话，按上面的規則同样處理。
第五步：观察並复查
改動後不要只看一两天，比較合理的是两到四周後复查：
- 抓取統計里，分頁 URL 的抓取比例是否下降；
- 詳情頁的“已發現”數量有没有减少；
- 站点整体收錄總量下降，但有效頁面的收錄比例上升，属于正常現象，不必急着回滚。
几個容易踩的坑
- 给分頁加了 noindex，却忘了把頁内連結保留為可抓取，结果詳情頁的入口被切断。
- 分頁 URL 做了 301，但站内連結和 sitemap 里還是舊地址，導致每次抓取都多一跳。
- 把脚本生成的參數化分頁地址也当成正常分頁保留，等于给自己制造了一批近重复地址。
分頁處理的核心不是“砍掉多少頁”，而是让抓取和索引集中在真正有獨立價值的地址上。先收口 URL 形態，再判断價值，最後才動 noindex 和 canonical；顺序反過来做，很容易把詳情頁的入口一起弄丢。