列表页往往是站内 URL 密度最高的地方。一个栏目翻到第 20 页，背后可能对应上千条详情页地址。蜘蛛能不能走到这些地址，很大程度取决于第 1 页里有没有留下一条它能顺着往下走的路。

分页在 URL 发现里的位置

典型的抓取路径是：首页 → 栏目页 → 列表第 1 页 → 详情页。第 1 页承担两件事：把当前页的详情 URL 交出去，以及把“下一页”这条通道留出来。如果第二步断了，后面的分页和详情页就只能靠 Sitemap 或外链兜底，发现速度会明显慢下来，更新也不容易被及时看到。

三种翻页写法的差别

独立 URL 的分页

每一页都有自己的地址，比如 ?page=2 或 /list/page/2/ 这类形式，HTML 里用 a 标签指向下一页，蜘蛛顺着链接逐页推进。这是最容易被抓取的结构，也是排查问题最简单的结构——日志里能直接看到第几页被请求过。

点击加载更多

初始 HTML 里通常只放一个按钮，后续内容由脚本请求返回。这类结构对 URL 发现不够友好：按钮本身往往不是链接，蜘蛛不一定会去触发它。可行的做法是给“加载更多”配一个可点击的普通地址，或者在列表底部保留一组静态分页链接作为兜底。

无限滚动

用户滚动时自动加载，页面上没有明确的分页地址。即使把详情页都放进 Sitemap，列表页之间缺少连接关系，重访和更新发现的效率依然会打折。常见补救方式是在滚动区域下方补一段可爬的分页链接。

上线前值得逐条过的检查点

• 第 1 页的 HTML 源码里，能找到指向第 2 页的可点击 a 链接，而不是只有 onclick 或 javascript 伪协议。
• 分页地址是稳定、可复现的，不要带随机会话参数或时间戳。
• 分页页面的 canonical 指向自身，不要整站统一指回第 1 页。
• 第 2 页之后的 title 和描述可以简化，但正文列表要能正常返回内容，不要返回空壳页面。
• 列表页如果暂时不希望被索引，用 noindex 时保留 follow，避免把通往下一步的链接一起掐掉。
• 筛选、排序、日历这类会生成组合地址的功能，给一个明确的页数或参数上限，别让 URL 无限增殖。
• 移动端和 PC 端的分页结构保持一致，避免只有一端可爬。
• 分页页面的响应时间留出余量，第 1 页加载缓慢会直接影响后续页的抓取节奏。

一个常见的坑：canonical 全指向第 1 页

有些站点为了处理“分页内容重复”，把第 2 页到第 N 页的 canonical 全部写回第 1 页。结果是蜘蛛每走到一条分页链接，都被告诉“真正的地址是第 1 页”，后续页面的收录和路径延续都会受影响。更稳妥的做法是让每页 canonical 指向自身，只在确实存在等价地址（例如排序参数不同但内容完全一致）时才做归一。

怎么在日志和后台里验证

在服务器日志里筛一下对分页地址的请求，看看第 1 页之外的页有没有被访问、访问频率如何。如果日志里始终只有第 1 页，再回头检查链接是否可爬、canonical 是否写错、页面是否返回了空内容。搜索控制台里的已发现未编入索引、抓取统计中的响应分布，也能从侧面反映分页地址有没有被正常读到。

分页不只是浏览体验问题，它同时是站内最密集的一条 URL 发现通道。把这条通道留通，后面的详情页才有被发现的机会。

分页结构不需要做得很复杂。可爬的链接、稳定的地址、自指的 canonical，再加一个合理的页数上限，通常就能让抓取路径顺利延续到列表深处。