列表型站点（商品列表、文章归档、标簽聚合）的抓取路径，很多时候是靠分頁一层层往下走的。日常检查往往只看第二頁能不能打開，却忽略了第三頁之後鏈路是否還能接上，结果是入口頁被反复抓取，尾部頁面迟迟不進抓取队列。分頁断点不是“能不能訪問”的問题，而是“路径能不能连續”的問题。
分頁接續断点的常见形態
- 下一頁連結由脚本注入：原始 HTML 里只有第 1 頁的地址，後續頁碼靠前端渲染补齐，抓取端如果不等渲染就會停在第一頁。
- 滚動加载没有可請求的分頁地址：内容由接口追加，頁面本身不存在可带頁碼的 URL，路径無法延展。
- 頁碼越界统一跳回第一頁：超過末頁时全部重定向到第 1 頁，抓取端容易把這條路径视作环路，减少對後續頁碼的抓取。
- 末頁之後返回 200 空頁或软 404：内容為空但狀態碼正常，抓取端判断不出分頁已经結束。
- 带頁碼的路径被規則整体排除：列表頁可以抓，但含參數的頁碼地址在 robots.txt 或站点規則里被屏蔽。
為什么断点不容易被發現
一是抓取日誌通常按狀態碼和频次排序，断点表現為“某批 URL 從不出現”，属于缺失型問题，不會主動报警；二是從用戶视角看，滚動加载和点击分頁体驗都正常，站点运营侧很难感知；三是当分頁由接口驱動时，即使前端能看到更多内容，抓取端拿到的仍是同一份静態结构。
從日誌侧观察缺失
把抓取日誌按路径前缀聚合，統計列表頁第 1 頁到第 N 頁的命中分布。如果第 1 頁的抓取量遠高于第 2 頁，而第 2 頁之後几乎為空，基本可以判断分頁接續在某處断開。再對照服務器訪問日誌中的真實請求，確認是抓取端没来，還是来了被拦。
從可達性侧驗證
關閉脚本执行，用抓取视角請求列表頁，查看返回的 HTML 中是否包含指向下一頁的可点击地址；再顺着這些地址连續請求若干頁，確認每一跳都存在下一跳。
排查與修复顺序
- 確認分頁地址是否可請求：為每頁生成稳定、能被直接訪問的 URL，而不是僅靠交互触發。
- 补齐静態連結：在列表頁 HTML 中輸出“下一頁”和頁碼連結，脚本渲染作為增强而非唯一入口。
- 修正越界行為：末頁之後返回 404 或明确终止分頁，不要统一重定向回第一頁。
- 检查規則與狀態碼：確認分頁路径未被 robots.txt 屏蔽，空頁不要返回 200。
- 建立回鏈：让詳情頁有回到所属列表頁或相邻條目的連結，避免路径只靠分頁單向延伸。
- 在站点地图中补充必要的分頁入口，但只保留有獨立價值的頁碼，避免把無意义的翻頁全部提交。
長期维護的几個习惯
- 把分頁深度作為固定观测項，而不是只在改版时检查一次。
- 列表頁改版後，重点回归“下一頁”的連結是否仍在服務端輸出。
- 控制單頁條數，避免為减少頁數而把單頁体积做得過大。
- 分頁地址保持稳定，不要频繁更換參數命名，否則已發現的路径會全部作废。
分頁鏈路的價值在于让抓取端知道内容往哪儿走、走到哪儿停。它不能保證收錄，但可以避免内容因為路径不通而長期缺席。
分頁断点通常不會带来明顯报错，只會让抓取范围停在入口附近。定期用抓取视角顺着頁碼走一遍，比事後分析抓取量下滑更省事。