站点运营

站点运营:分頁與列表翻頁自查,別让翻頁把内容切成一地碎片

栏目列表頁是蜘蛛發現站内内容的主要通道,但加载更多、脚本渲染、canonical 誤指向首頁等問题,常让翻頁在後半段断掉。本文從翻頁實現方式、連結可抓性、規范化寫法、每頁條數與翻頁深度几個角度,整理一份可执行的分頁自查清單。

站点运营

站点运营:分頁與列表翻頁自查,別让翻頁把内容切成一地碎片

栏目列表頁往往是蜘蛛發現站内新内容的主要通道。首頁和栏目第一頁的連結通常没問题,問题多出在第二頁往後:翻頁按钮靠脚本渲染、下一頁没有真實 href、頁碼參數任意可訪問,都會让蜘蛛在列表頁前几屏就停下。

先確認站点用的是哪種翻頁方式

传统翻頁連結

形如 /news/page/2//news?page=2,每頁都輸出可点击的 a 标簽。這種實現最容易被抓取,重点检查是否存在頁碼超限仍返回正常狀態碼的情况。

加载更多與無限滚動

這類交互對用戶友好,但對蜘蛛不友好:按钮往往是 div 或 button,没有 href,点击後才由脚本請求接口並拼接 HTML。蜘蛛不点击,也就看不到後面的内容。可行的做法是保留一個真實可抓取的分頁地址作為後备,例如在列表底部放一個指向下一頁的連結,或者提供带頁碼的静態列表面。

分頁連結要能被抓取和跟随

  • 分頁導航使用 a 标簽並带 href,不要只绑 onclick 事件。
  • 不要在分頁連結上随意加 nofollow,除非确實不希望蜘蛛繼續向後翻。
  • 確認分頁連結在初始 HTML 中就存在,而不是滚動到底部後才由脚本插入。
  • 模板改版後回头看一眼分頁導航是否被隐藏容器或條件判断包裹住。

canonical 與 prev/next 別用错

一個常见错誤是把所有分頁頁的 canonical 都指向列表首頁,這等于告诉搜尋引擎這些頁面都是首頁的副本。頁面上的條目連結仍可能被抓到,但分頁頁本身很难有獨立價值。更稳妥的做法是每頁 canonical 指向自身。

rel="prev" 與 rel="next" 目前主要作為路径提示存在,不再作為索引信号。保留無妨,但不能用它替代可抓取的翻頁連結。

每頁條數與翻頁深度

每頁條數太少,頁數迅速膨胀,抓取预算被摊薄;太多則單頁体积變大,解析和渲染成本上升。可以结合日誌观察:蜘蛛實际翻到第几頁,哪些頁碼几乎從不出現。如果長期只抓到前三頁,後面的内容就只能依赖 sitemap 和内鏈补充入口。

缩短路径的常用办法是在栏目頁增加“最新”“热门”模块,或维護按時間归档的专题頁,让舊内容有更浅的入口,而不是只能靠一頁頁翻過去。

參數與伪静態要统一

?page=2 與 /page/2/ 本身都能用,問题在于同一個列表出現多種可訪問形式,且都正常返回。建议固定一種,其余做重定向,避免同一份列表堆出多套地址,也避免和其他篩選參數叠加成大量组合。

自查清單

  1. 随机挑三個栏目,禁用 JS 後看分頁連結是否仍在 HTML 中。
  2. 检查分頁頁的 canonical 是否指向自身。
  3. 翻到最後一頁,確認没有空白頁或循环跳回第一頁。
  4. 測試超出總頁數的頁碼,確認返回 404 或 410,而不是 200 的空列表。
  5. 在日誌中統計分頁 URL 的抓取频次與狀態碼分布。
  6. 確認分頁參數不會與排序、篩選组合成大量可訪問地址。
分頁不是排版细节,而是内容能否被逐层發現的基础设施。先让翻頁連結可抓,再谈每頁放多少條。