列表页做分页是很常见的做法，但分页 URL 的发现逻辑和普通页面不太一样。它们通常不靠 Sitemap 或首页直达，而是靠“下一页”“第 N 页”这类链接一层层被带出来。链路上任何一处断掉，后面的页码就可能长期停在“已发现未抓取”，甚至完全没被看到。
分页 URL 的发现靠的是一条链
内容页可以从首页、分类页、Sitemap 等多个入口被发现，冗余度很高。分页页面则往往只有一条路径：第 1 页 → 第 2 页 → 第 3 页。这意味着它对中间环节特别敏感，一旦某一页的页码导航缺失或被 JS 完全接管，后续页码就失去了入口。
page=1 与首页内容重复怎么处理
带参数的首页和不带参数的首页通常渲染同样的内容。建议让首页自引用 canonical，把 page=1 指向首页，或用 301 直接合并到一个地址。这样做的价值不是“多一个 URL 被收录”，而是让抓取配额集中在真正需要被发现的第 2 页及之后。
第 2 页到底怎么被看到
关键在第 1 页返回的 HTML 里有没有指向第 2 页的可解析链接。如果列表只输出前若干条，页码条由脚本在滚动后才插入，搜索蜘蛛在渲染前后看到的结构可能不同。更稳妥的方式是服务端直接输出页码导航，至少在首屏 HTML 中就包含“下一页”和末页链接。
- 页码导航使用真实的 a 标签与 href，而不是 onclick 或表单提交
- “下一页”按钮指向具体的第 2 页 URL
- 末页可以直达，避免只能一页一页往后翻
- 页码链接不要包裹在需要点击才展开的折叠层里
rel=next/prev 还能指望吗
主流搜索引擎已经明确不再把 rel=next/prev 当作索引或抓取的信号，所以不要把发现路径押在它上面。它可以作为站内语义的补充，但真正让第 2 页被看到的，仍然是页面里可点击、可解析的普通链接。
末页与“下一页”的断点
有些站点在第 8 页之后只显示“上一页”，后面的页码就失去了继续深入的入口。可以考虑在页码条中保留首尾页码，让最末几页也有稳定路径；或者在末页明确标注这是最后一页，避免抓取反复试探不存在的第 N+1 页。
加载更多与无限滚动
这两种交互的本质是把内容在客户端追加。如果 URL 不发生变化，第 2 屏的内容和第 1 屏共享同一个地址，搜索蜘蛛只能看到一个 URL。想让后续内容具备被发现的条件，应尽量为每一段内容提供独立地址，并保证该地址在服务端可直接访问，而不是必须依赖滚动和点击才会出现。
排序、筛选与分页的组合膨胀
带排序和筛选参数的分页会成倍放大 URL 数量，而且大量组合的内容高度相似。比较务实的做法是只保留少量真正有价值的排序作为可抓取链接，其余组合不输出为 a 标签，避免把抓取配额消耗在近似页面上，从而挤占内容页的抓取机会。
用抓取日志核对分页链
- 在抓取日志中筛出分页 URL，确认第 1 页、第 2 页、末页是否都出现过请求
- 看请求的时间顺序，判断是否形成逐页推进，而不是只抓了第 1 页
- 核对 Search Console 中“已发现未抓取”的列表里，分页 URL 占比多少
- 检查这些 URL 的返回码和响应时间，排除因超时或错误导致的推进中断
分页 URL 的发现是一条链，链上链接的形态（是否在 HTML 中、是否真实可点）比链接数量更重要。断了一页，后面就都看不见。
另外要注意服务器层面的影响。分页页面的抓取优先级通常低于内容页，当站点响应变慢时，这类 URL 往往是最先被延后的一批，表现就是页码推进停在中途。因此排查分页发现问题时，链接结构和响应时间需要一起看。