搜尋抓取

列表分頁的 URL 發現:第二頁之後的地址靠谁带路

列表分頁常常是 URL 發現的断点:第二頁之後的地址如果没有可跟随的連結,詳情頁就很难進入抓取队列。本文梳理分頁連結的常见寫法問题、無限滚動的折中處理、分頁參數的可索引性判断,以及用 Sitemap 與服務器日誌补路径、驗證效果的具体做法。

搜尋抓取

列表分頁的 URL 發現:第二頁之後的地址靠谁带路

很多站点的 URL 發現並不是断在首頁,而是断在列表的第二頁。首頁和新發布的文章被反复抓取,翻到第三頁之後的詳情頁却迟迟没有動静。問题往往不在内容本身,而在分頁連結是否构成一條搜尋蜘蛛能走完的路径。

分頁為什么會断在第二頁

列表頁常见两種寫法:一種是真的用 a 标簽指向 ?page=2,另一種是按钮点击後由脚本拼出新地址。前者至少留下一條可跟随的連結,後者在未渲染的情况下等于没有入口。

  • “加载更多”只改 DOM、不改變 URL,蜘蛛翻不動。
  • 分頁地址只寫在 onclick 或 data 属性里,标簽中没有 href。
  • 第二頁以後被 noindex 或 robots 規則挡住,連結還在,路径却到此為止。
  • 列表按時間倒序排列,重要但較舊的條目被推到很深的頁碼。

可跟随的分頁入口该是什么样

比較省事的做法是让分頁本身是一组静態可達的連結:上一頁、下一頁、頁碼數字都用 a 标簽带 href,地址中的參數稳定,不随會话或推荐位變化。這样即便某一頁内容没有單獨索引價值,蜘蛛也能顺着它走到更深的條目。

頁碼很多时,可以把扁平列表拆成若干层級:栏目頁 → 月份或分類归档頁 → 詳情頁,用归档頁把抓取路径深度压下来,而不是让蜘蛛一路点到第五十頁。归档頁本身也能作為長期存在的入口,比临时參數頁更稳定。

無限滚動與“加载更多”的處理

纯無限滚動對 URL 發現最不友好,因為滚動過程中不會产生新地址。常见的折中方式是分頁與滚動並存:首屏给出若干頁可点击的連結,滚動只作為浏览体驗的补充;或者在每次加载額外内容时同步更新 URL,让地址可以被複製、被引用,也方便蜘蛛跟随。

分頁參數與可索引性

分頁地址要不要被索引,取决于它有没有獨立價值。纯粹的“第 N 頁”通常只是入口而不是内容,但把它完全挡掉,也會顺带切断後面的路径。更稳妥的處理是:保留連結可抓取,用 canonical 指向该分頁自身或對應的聚合頁,避免同一批條目被多條排序參數重复發現。

排序、篩選類參數尤其容易膨胀出大量近似地址。可以用 robots 規則或參數處理工具收窄,但要注意別把带頁碼的常規分頁一並挡掉——一旦挡住,第二頁之後的詳情頁就只剩下 Sitemap 這一條路了。

用 Sitemap 兜底分頁地址

当分頁路径不可控时,Sitemap 是补充分頁入口的常規手段:把归档頁和主要分頁地址按實际可訪問的 URL 列進去,保持 lastmod 與真實更新一致。它不保證被抓取,但至少让這些地址不再完全依赖某條容易断掉的連結鏈。

用日誌驗證到底走到了哪一頁

與其猜,不如看日誌:篩選列表頁地址,看蜘蛛請求到第几頁就停了,是不是每個分頁只被抓過一次,某一頁之後突然為空。经常能從中發現某頁返回 500、某頁跳到登入頁,或者分頁參數在不同 UA 下表現不一致這類具体問题。

分頁不是给蜘蛛看的展示頁,而是通往詳情頁的路。路断了,後面的内容再有價值也很难被發現。