栏目列表頁通常是蜘蛛發現新内容的主要入口。不少站点把精力放在首頁和詳情頁上，却忽略了列表頁的分頁——尤其是從传统翻頁改成“加载更多”或無限滚動之後，第二屏之後的内容在初始 HTML 里根本不存在。
先確認蜘蛛能看到什么
用抓取工具或者直接查看網頁源碼（關掉 JavaScript，或只看初始响應），確認列表里是否包含指向詳情頁的真實 a 标簽連結。如果詳情連結要滚動到底部才由脚本插入，蜘蛛拿到的响應里就是一張空列表。
- 首屏是否有可点击的連結，而不是只有图片、按钮和骨架屏。
- 点击“加载更多”後 URL 是否變化，是否有可獨立訪問的地址。
- 分頁是否有對應的静態地址，例如 /list/2 或 ?page=2。
分頁 URL 的几處常见坑
- 只有第一頁有入口連結，後續頁靠脚本拼接參數，且返回内容依赖會话或 Cookie。
- 所有分頁的 canonical 都指向第一頁，等于告诉搜尋引擎後面几頁都是重复内容。
- 分頁參數顺序不稳定，同一頁出現多個不同地址。
- 篩選、排序、分頁三個參數叠加，组合出大量内容近似的结果頁。
一份可执行的自查清單
- 打開任一栏目的第二頁、第三頁，看 URL 是否可直接訪問、刷新後是否稳定。
- 查看该頁源碼，確認 canonical 是否指向自身，而不是统一指回第一頁。
- 確認分頁連結是 a 标簽，並且出現在上一頁的 HTML 中，而不是只在脚本里生成。
- 翻到最後一頁，检查是否有返回上一頁或返回栏目的路径，不要留下断头路。
- 检查各分頁的标题與描述是否完全一致，必要时用頁碼做区分。
- 在服務器日誌里筛出列表頁地址，观察蜘蛛是否訪問過第一頁之後的頁碼。
處理思路
無限滚動和“加载更多”對用戶体驗友好，但建议同时保留一套可抓取的分頁地址作為兜底：脚本加载的内容，仍然能通過 /page/3 這類連結被直接訪問。两者可以共存，由同一批資料渲染，维護成本並不高。
對于篩選條件過多的结果頁，可以考虑用 robots.txt 或 meta noindex 做抓取控制，但動手之前先確認這些頁面有没有承担 URL 發現的任務。真正需要保留的，是那些能通向詳情頁的列表分頁；纯粹组合排序、不指向唯一内容的頁面，才适合收紧。
列表頁的價值不在于它本身有多少文字，而在于它能把蜘蛛送到哪些頁面。如果這條路只留给脚本，等于把發現新内容的主動權交了出去。
調整之後別急着下结论，持續观察一段時間日誌，看詳情頁的首次抓取和更新後的再次訪問有没有變化，再决定是否繼續微調。分頁這種基础结构，改動一次往往要几周才能看出趋势。