列表页、归档页、标签页的分页，是站点里很容易被忽略的一类入口。第一页往往在导航里，后面的第2页、第3页却要靠翻页链接一层层点进去。如果翻页结构没交代清楚，蜘蛛很可能只抓到第一页就停下，后续内容就变成了没有入口的孤岛。

先看翻页链接是不是真的可抓

很多分页用“加载更多”按钮或无限滚动实现，用户往下滑，内容不断出现，但页面源码里只有一批初始数据，后面的内容靠JS请求追加。这种形式对用户友好，对蜘蛛却不一定友好。蜘蛛看到的是一个没有后续链接的页面，自然不会再往下走。

如果必须用“加载更多”，至少要保证有分页URL可以单独访问，并且在源码里给出可点击的链接。例如在列表底部保留“下一页”的a标签，指向第2页的真实地址。不要只用button加事件监听。

分页URL要干净，别带一堆无用参数

翻页地址常见两种：路径型 /list/page/2/ 和参数型 /list?page=2。两种都可以，关键是保持一致，别同一批内容同时出现多种翻页写法。参数型如果还混着排序、筛选、时间范围，容易组合出大量地址。

建议：

• 翻页参数只保留页码，如 page=2，不要加没必要的跟踪参数。
• 排序和筛选尽量用可选的路径或参数，并明确哪些组合需要收录，哪些不需要。
• 避免把“上一页/下一页”链接写成带session ID或随机值的地址。

canonical 与分页：别把第2页指回第1页

有些站点为了集中权重，把分页的 canonical 全部指向列表第一页。这样做的问题是：第2页上的内容条目会被当成重复内容，蜘蛛可能不再抓取后面的页面。分页本身不是重复内容，它只是内容的不同片段。正确的做法是让每一页自己 canonical 自己，同时确保第1页能通过翻页链接到达后续页。

如果确实希望第一页作为规范入口，那也要保留后续页面的可抓取性和独立地址，而不是简单用 canonical 全部合并。

rel next / prev 现在怎么用

Google 已经明确不再把 rel next 和 rel prev 作为索引信号，但其他搜索引擎和爬虫仍可能参考，而且它本身是描述页面关系的语义标记。可以保留，但不要依赖它来解决抓取问题。真正有用的还是页面里明明白白的翻页链接。

无限滚动与“加载更多”的折中做法

如果前端体验必须做无限滚动，建议采用渐进增强：默认输出分页链接，点击“加载更多”时再替换为动态加载。这样蜘蛛至少能顺着链接翻到下一批内容。另一种做法是分页URL保留，JS只负责把下一页内容拼到当前视图中，但地址栏和链接依然可访问。

分页深度与抓取预算

列表页分页越深，蜘蛛到达的成本越高。如果一个栏目有200页，蜘蛛不太可能把每一页都抓一遍。这时可以：

• 把重要内容同时放到更浅的入口，如首页推荐、频道首页、专题页。
• 控制每页条数，别让第一页就列出几百条，导致后续页面没有抓取必要。
• 对已经没有新内容的深层分页，可以评估是否需要保留可抓取状态，或做适当的 noindex 处理，但要谨慎。

自查清单

1. 列表第一页是否有清晰的“下一页”链接，且是标准a标签。
2. 翻页URL是否稳定，不带无关参数和随机值。
3. 第2页、第3页的 canonical 是否指向自身，而不是第一页。
4. “加载更多”按钮是否有对应的可访问URL备用。
5. 分页页面是否在XML站点地图中有选择地提交，而不是把所有翻页都塞进去。
6. 深层分页是否消耗了过多抓取预算，重要内容是否有更浅的入口。

分页不是大问题，但它常常是内容被发现的第一道门。把翻页链接、URL和规范地址处理好，蜘蛛才能顺着列表把后面的内容一页页翻完。