对用户来说，向下滚就不断加载很顺；对搜索爬虫来说，它通常不会像真人一样持续滚动、点击“加载更多”。如果后面的内容没有独立可抓取 URL 和链接，漂亮的无限列表可能让大量页面难以被发现。
01 先区分内容浏览和页面发现两个问题
无限滚动解决用户连续浏览体验，SEO 需要搜索能够通过 URL 和链接发现后续内容。两者可以同时存在，不必二选一。
Google 当前 Pagination 指南建议将长列表拆成可独立访问的分页页面，并让每一页拥有唯一 URL。
02 每个分页状态需要稳定 URL
例如 ?page=2、/page/2/，只要结构稳定且服务端能直接返回对应内容即可。用户从搜索或分享链接进入 page=4 时，应该真的看到那一段列表。
不能要求先打开第一页，再运行 JavaScript 连续滚四次才能得到同样内容。
03 分页之间要用真正可抓取的 <a href> 链接
Google 的链接最佳实践要求关键导航使用带 href 的 anchor。只有按钮 onClick 加载下一批，搜索爬虫可能无法通过链接发现后续页。
界面可以视觉上表现为“Load More”，底层仍可以提供对应分页 URL 与链接逻辑。
04 不要把所有分页 canonical 到第一页
每一页包含不同列表项目时，它们不是完全重复页面。全部 canonical 到 page 1 可能让后续内容更难被正确发现。
Google 当前分页文档建议每个页面使用自己的 canonical，而不是把系列合并成一个代表。
05 用户返回列表时要恢复位置和已加载内容
无限滚动常见痛点是点进详情，再返回列表后回到最顶部。尤其浏览到第 100 条时非常挫败。
应该保存滚动位置、分页状态和筛选条件。URL 状态化也能帮助浏览器历史正常工作。
06 无限滚动不适合所有任务
社交 Feed 强调探索，Infinite Scroll 很自然；B2B 产品目录需要比较、定位和记住页码，传统分页可能更高效。
“加载更多”则介于两者之间，既保持连续感，又给用户明确控制和页面节奏。
07 筛选与排序要避免和分页一起生成无限 URL 组合
一个产品列表同时有 10 种筛选、5 种排序、100 页，URL 组合会快速膨胀。需要明确哪些组合值得索引，哪些只服务用户。
Canonical、robots、内部链接和参数策略应该与分页架构一起设计。
08 选择方案时同时看用户任务、性能和搜索发现
没有“无限滚动一定更现代”或“分页一定更 SEO”的简单答案。正确方案取决于内容性质、用户是否需要定位、列表规模和技术实现。
只要后续内容有稳定可访问页面、可抓取链接和正确索引信号，前端可以继续提供流畅的连续加载体验。
09 筛选 URL 要区分“有搜索需求的集合页”和纯交互状态
电商或产品目录中，一些组合筛选可能本身就是用户会搜索的稳定需求，例如“工业级防水连接器”；另一些只是临时排序或多选状态。两类 URL 不应该使用同一索引策略。
有价值的集合页可以做成稳定、可内部链接、拥有独立文案与 canonical 的落地页；纯交互参数则更适合作为界面状态管理，避免无限制造近似页面。
10 分页设计不能只在桌面端看“上一页 / 下一页”
移动端、无障碍和长列表场景还需要考虑当前页状态、可点击区域、返回后位置保持，以及用户从详情返回列表时是否保留筛选和页码。
搜索可发现性与用户连续浏览其实是同一个架构问题：每个重要分页状态要有稳定 URL 和可抓取链接，同时不能让用户因为切页而丢失上下文。
常见问题
Infinite Scroll 会导致 Google 完全抓不到吗？
不一定，但后续内容应通过独立 URL 和可抓取链接可访问，不能只依赖用户滚动事件。
分页页要 canonical 到第一页吗？
通常不应该。包含不同列表内容的分页页应使用各自 canonical。
Load More 比分页更好吗？
取决于任务。探索型内容适合连续加载，精确定位和比较任务可能更适合分页。
需要 rel=next/prev 吗？
Google 已不再使用 rel=next/prev 作为索引信号，不应把它当当前核心方案。
无限滚动返回时怎么保留位置？
保存分页、滚动和筛选状态，并让浏览器历史和 URL 能恢复上下文。
相关服务与进一步咨询
链接复制成功
