分页、无限滚动、加载更多、View All、rel=next/prev、Canonical 和 Fragment URL 有什么区别？
七个概念快速对比
概念 用户交互 是否需要独立 URL 搜索发现作用 主要风险
-- --- --- --- ---
分页 点击页码或上一页/下一页 每页需要 提供可爬链接和稳定内容片段 Canonical 错指首页、重复排序
无限滚动 滚动触发追加 SEO 实现仍需分页 URL 前端体验层，不会自动产生可抓链接 爬虫不滚动、内容仅在事件后出现
加载更多 点击按钮追加 SEO 实现仍需分页 URL 按钮本身通常不是发现机制 没有 href、状态不可恢复
View All 一次展示全部 通常一个 URL 集中内容与信号 页面过重、渲染慢、项目过多
rel=next/prev 对用户通常不可见 依附链接 描述前后关系 被误当作 Google 合并分页信号
Canonical 对用户不可见 指向首选 URL 规范重复或近重复页面 所有分页都指第1页导致内容弱化
分页是什么
分页把一个大集合切成多个可请求页面，例如：
每个 URL 应返回该页项目，即使没有执行点击或滚动 JavaScript。页面之间用可抓取的 <a href 链接连接。Google 通常不会替用户点击按钮，也不会依靠在视口中滚动来发现所有项目，因此普通链接仍是基础。
分页 URL 要稳定：同一页码在合理时间内应对应可解释的内容窗口。数据频繁插入时，页码会漂移；游标分页能提高数据一致性，但游标字符串可能产生大量临时 URL。公开 SEO 列表可以使用稳定页码或经过设计的持久游标，内部 API 再使用短期游标。
无限滚动是什么
无限滚动在用户接近页面底部时自动请求下一批数据并追加到当前文档。它改善连续浏览，但浏览器中的“已经追加”状态不会自动成为搜索引擎可请求的资源。
正确实现应把连续列表拆成一系列分页组件。每个组件拥有独立 URL，可在直接访问时返回对应项目；无限滚动只是逐步加载这些 URL 的交互增强。用户滚到新片段时，可以用 History API 更新地址和历史状态，使刷新、复制链接及后退操作能恢复合理位置。
不要在滚动的每几个像素都创建历史记录。应在跨入明确分页边界时使用 history.pushState 或 replaceState，并保证地址栏 URL 直接打开时由服务器或渲染层返回相同内容片段。
“加载更多”是什么
“加载更多”由按钮触发下一批内容。对键盘和屏幕阅读器而言，它通常比无止境滚动更可控，也允许用户决定网络和页面长度。
但 <button 没有可供爬虫跟随的目标 URL。可以保留按钮做交互，同时在 HTML 中提供分页 <a href，再由 JavaScript 增强为异步追加。若链接既承担导航又被增强，脚本失败时仍能跳到下一页。
不能只把目标写在 data-url、onclick 字符串或前端状态对象里。搜索引擎发现链接最可靠的形式是带可解析 href 的 <a 元素。
View All 是什么
View All 把整个集合展示在一个 URL。项目数量有限、正文轻量且页面性能可控时，它可减少分页切换，并让用户在一个文档中查找全部内容。
当集合有数千商品、图片或复杂组件时，View All 会增加 HTML、数据库查询、主线程和内存成本。懒加载图片只能延迟部分资源，不能消除巨大 DOM、接口负载和渲染成本。此时分页更可控。
若分页页与 View All 内容高度重合，可以根据真实重复关系选择 Canonical，但不能机械地把所有分页都指向 View All。必须确认 View All 可稳定访问、性能合格、包含每页独有项目，并且不是需要登录或滚动后才完整出现。
rel=next/prev 现在有什么作用
HTML 链接类型 next 和 prev 表达文档序列关系，可以帮助浏览器、辅助工具或其他消费者理解前后导航。例如：
Google 已公开说明不再把 rel=next/prev 用作合并分页序列的索引信号。因此，添加它不能修复不可抓链接、错误 Canonical 或只有 JavaScript 事件才能出现的内容。
保留正确的 next/prev 不一定有害，但 SEO 设计不能依赖它。真正关键的是每页 URL、普通链接、独立内容、HTTP 可访问性和合理 Canonical。
分页页面的 Canonical 应该指向哪里
第 2、3、4 页通常包含不同项目，因此不是第 1 页的重复副本。Google 对电商分页的指导建议每个分页页面使用自引用 Canonical，而不是全部指向第一页。
如果把所有分页 Canonical 到第一页，搜索引擎可能弱化后续页，后续页上的商品或文章也更难通过列表路径被发现。Canonical 是提示而非强制命令；站内链接、Sitemap、重定向和内容差异若互相矛盾，搜索引擎会自行选择规范 URL。
跟踪参数、排序参数和筛选参数需要单独策略。?page=2&utmsource=x 可 Canonical 到无跟踪参数的第 2 页，而不是第一页。不同排序产生相同项目集合时可规范到主排序；筛选产生有搜索价值的独特集合时，可能需要自引用、标题和内部链接。不能用一条规则覆盖所有参数。
Fragment URL 为什么不能做分页
在普通 HTTP URI 中，section 是客户端片段标识符，不会作为请求目标的一部分发送给服务器。下面两个地址通常向服务器请求相同资源：
浏览器脚本可以读取 hash 并显示不同数据，但服务器、缓存和许多抓取流程首先看到的仍是 /products。这使后续片段缺少独立 HTTP 响应、状态码和可验证 Canonical。
分页应使用路径或查询参数，例如 /products/page/2 或 /products?page=2。Fragment 仍适合页内锚点，如跳到 FAQ 小节，但不应作为需要独立发现和索引的主要内容状态。
History API 不会自动让内容可索引
pushState 可以在不刷新页面的情况下更新 URL，但它只修改浏览器历史。开发者仍需确保新 URL 可直接请求，并返回与状态相符的内容。若服务器对所有路径只返回空壳，再依赖复杂脚本和用户操作加载，抓取与渲染会变得脆弱。
测试方式很直接：复制滚动后的地址，在新隐私窗口禁用已有应用状态后打开；查看初始 HTML 和渲染结果是否包含对应片段；关闭 JavaScript时，至少应存在通往前后页的导航路径。
不要使用 History API 生成服务器返回 404 的“假 URL”。搜索引擎直接请求时会得到错误状态，前端路由成功也不能修复服务器响应。
JavaScript 懒加载与分页不是一回事
懒加载推迟资源或内容获取，分页定义集合如何切片及寻址。图片可在进入视口前后加载，但每个商品链接仍应存在于可渲染内容中。若 <img 使用原生 loading="lazy"，浏览器可控制加载；关键图片仍需考虑首屏性能。
不要要求用户滚动或点击才把所有重要链接写入 DOM。Google 的渲染不会保证执行每一种交互。可以在初始 HTML 提供下一页链接和当前页项目，再让 JavaScript负责平滑追加。
懒加载失败时也应避免向爬虫返回 200 空页面。接口错误、无结果和真正不存在应有不同状态与可见提示。
分页 URL 的状态码如何处理
有效页返回 200。超过末页、参数非法或根本不存在的分页 URL不应无限返回与第一页相同的 200 内容，否则会制造 Soft 404 和重复抓取空间。可以返回 404，或根据产品需求规范化到有效 URL；重定向必须有明确语义，不能把所有错误页都送回首页。
空集合首页和越界页也不同。某个分类暂时没有商品，分类 URL 仍可能返回 200 和空状态；请求 ?page=999999 超出边界则更适合 404。
页码参数应设置合理上限，并防止负数、浮点数、重复参数和任意排序组合造成近无限 URL。服务器必须使用稳定的排序键，并在主键相同时增加确定性次排序，避免项目跨页重复或遗漏。
内部链接如何设计
每页至少应能通过普通链接到达下一页；大型集合只提供“上一页/下一页”会形成很深路径，可增加部分页码、首尾页或分层分类链接，但不要生成数万个链接塞满一个页面。
商品和文章详情页应使用真实 <a href。卡片只绑定 JavaScript 点击事件不够。链接锚文本要描述目标，不应所有都只有“详情”。分页控制可以使用“第 2 页”等可理解标签，并给当前页提供可访问状态。
Sitemap 可以帮助发现详情 URL，但不能替代站内可抓链接。分页页本身是否进入 Sitemap 要按其独立价值决定；核心目标通常是确保详情 URL 可发现、Canonical 一致且更新时间可信。
排序、筛选与分面导航
分页的 page 参数、排序的 sort 参数和筛选的 color/size 参数含义不同。分页扩展一个集合，排序重排同一集合，筛选创建子集。索引策略应分别制定。
低价值筛选组合可能指数增长，消耗抓取资源。可以减少内部链接、使用一致 Canonical、认证或按需返回，必要时使用 noindex；但被 robots.txt 阻止抓取的页面，搜索引擎可能看不到页面上的 noindex。高价值分类应提供稳定 URL、独特标题、正文与自引用 Canonical。
不要让 Canonical 指向内容并不等价的宽泛类别。颜色为红色的集合并不天然等于全部颜色集合，搜索意图和项目都可能不同。
无限滚动的可访问性与状态恢复
追加内容后应通知辅助技术，管理焦点并保留用户在列表中的位置。无限追加会把页脚不断推远，也可能让键盘用户难以到达固定区域。“加载更多”加可访问分页通常更可控。
返回详情页时，应用应恢复页码、滚动位置和已加载项目，但不能只依赖内存。URL 至少要表达可恢复边界，浏览器历史项保存滚动状态，服务端继续支持直接访问。
性能上要控制 DOM 长度。虚拟列表可卸载视口外节点，但会影响页内查找、辅助技术和返回定位；它属于前端渲染优化，不改变分页 URL 的 SEO 要求。
一套可执行的验收流程
列出第一页到末页的稳定 URL，确认每页直接请求返回正确 HTTP 状态和对应项目。
检查导航是带 href 的 <a，而非仅有按钮、onclick 或 data-url。
验证第 2 页以后使用自引用 Canonical，跟踪参数只规范到对应页码的干净 URL。
禁用 JavaScript测试基本分页；启用 JavaScript测试滚动、加载更多、地址更新、刷新与后退。
检查源 HTML、渲染 DOM 和 URL Inspection，确认重要详情链接可发现。
测试末页、越界页、空分类、非法参数和重复参数的状态码。
验证排序稳定，连续抓取多页时没有无故重复或遗漏项目。
监控抓取日志、重复 URL、Soft 404、渲染失败、Core Web Vitals 与用户交互指标。
常见误区
认为搜索引擎会像用户一样滚到底并点击每次“加载更多”。
把所有分页 Canonical 到第一页，削弱后续页独特内容。
依赖 rel=next/prev 代替普通链接和独立 URL。
用 page=2 作为唯一分页状态，服务器无法直接返回该片段。
使用 pushState 创建服务器实际返回 404 的路径。
把分页、排序和筛选参数用同一 Canonical 规则处理。
对任意越界页返回 200 和第一页内容，制造无限重复空间。
用 Sitemap 代替详情页和分页之间的内部链接。
结论
分页是可寻址的内容架构，无限滚动和加载更多是交互增强，View All 是集中展示选择；rel=next/prev 不能替代可抓链接，Canonical 必须尊重每页内容差异，Fragment URL 也不能代替服务器可请求的分页地址。让每个片段有稳定 URL、200/404 语义、普通链接和可恢复状态，才能同时服务用户与搜索引擎。