B2B 产品列表用分页、加载更多还是无限滚动，才不会漏掉后面的产品？

直接答案： B2B 长产品列表通常优先采用有独立 URL 的分页，或在“加载更多”背后保留可抓取分页链接。无限滚动只有在能同步更新地址、恢复位置、提供键盘与辅助技术反馈，并确保后续产品有真实链接时，才适合使用。

采购方在第 4 屏看到一个接近需求的型号，点进去核对参数，再按返回。页面很勤快地把他送回第 1 屏。刚才那台产品没有消失，只是又需要滚三分钟才能证明它存在。对客户，这是记忆测试；对爬虫，如果后续内容只靠按钮或滚动触发，测试可能更简单：它根本不参加。

分页、加载更多和无限滚动都不是天然正确或错误。要选的是一种能同时回答三个问题的方式：后面的产品能否被发现，用户能否回到原位置，页面状态能否被复制和分享。

B2B 产品列表为什么通常更适合分页？

因为采购比较需要位置感，而不是只需要连续刷动

B2B 产品列表往往包含型号、关键参数、应用范围和资料入口。采购方会在列表与详情之间反复往返，甚至把第 2 页与第 5 页的产品发给同事比较。分页给出明确边界：当前第几页、前后还有多少、这个 URL 能否再次打开。

Google 的分页文档也要求后续页通过普通 <a href> 顺序连接，每页使用唯一 URL。爬虫通常不会替用户点击“加载更多”按钮，也不会触发依赖用户动作的 JavaScript；没有链接的后续产品，可能无法通过列表路径被发现。Google Search Central：分页与增量加载

模式	采购体验	抓取条件	主要风险	更适合的场景
分页	位置清楚，可复制页码	每页唯一 URL，顺序真实链接	翻页动作较多	型号多、需要往返比较、列表较稳定
加载更多	用户决定何时追加，保留上下文	背后仍需可访问的分页 URL 与链接	按钮后内容可能只对交互可见	中等列表、移动端浏览、仍要保留位置
无限滚动	连续浏览，操作少	需要复杂的 URL、历史记录和可访问实现	疲劳、页脚难到达、返回丢位置、后续项难发现	内容流强、目标不明确的探索场景

工业品目录通常不是娱乐内容流。采购方很少在第 86 个型号出现时感叹“再来一个”；他更关心筛选条件、比较位置和能否把结果交给工程师。所以分页常常是更稳妥的默认值，加载更多可以作为界面增强，无限滚动则需要更充分的理由。

分页 URL、canonical 和顺序链接应该怎样设置？

每一页都要有自己的地址和自引用 canonical

假设分类路径是 /products/valves/，后续页可以使用 /products/valves/?page=2。关键不是选择路径还是参数，而是每一页的地址唯一、稳定，站内链接和浏览器历史记录能复现同一批产品。

Google 明确建议分页序列中每页使用独立 URL，不要让第 2、3、4 页都 canonical 到第 1 页；每页应自引用 canonical。页码也不要写在 #page=2 这样的 fragment 中，因为 Google 通常忽略 fragment，可能不会把它当成新的页面继续跟随。Google Search Central：分页与增量加载

项目	正确做法	失败迹象
后续页 URL	?page=2 等稳定唯一地址	刷新后回到第 1 页
顺序链接	下一页使用真实 <a href>	只有无地址按钮或滚动事件
canonical	每页指向自身正式 URL	所有后续页都指向第 1 页
页码边界	超出范围返回 404	?page=9999 返回 200 空列表
内链一致性	列表、Sitemap、canonical 使用偏好 URL	同一页同时出现多个参数顺序
返回位置	详情返回时恢复页码、筛选和滚动位置	用户被重置到列表顶部

过去一些实现使用 rel="next" 和 rel="prev" 告诉 Google 页面顺序。Google 当前文档说明它已经不再使用这些标记；即使其他系统仍可能利用它们，也不能用它们替代可点击的前后页链接。

Sitemap 是补充发现，不是列表断链的许可证

Sitemap 可以列出希望搜索引擎发现的 canonical URL。Google 也建议同一内容存在多个地址时，只提交偏好的版本。Google Search Central：创建 Sitemap

但 Sitemap 不能把一个只能靠滚动触发、用户无法返回、站内没有路径的产品目录变成好结构。需要公开发现的产品，仍应从分类或后续分页获得真实链接；Sitemap 只是补充信号，也不保证索引。

加载更多怎样保留体验，又不让后续产品变成孤儿？

把按钮做成分页的界面增强

一个稳妥方案是：服务器仍提供第 1、2、3 页的独立 URL 与顺序链接，前端把“下一页”视觉上呈现为“加载更多”。用户点击后，产品追加到当前列表，同时更新浏览器历史状态；复制当前地址或刷新页面时，仍能恢复到相应页段。

实施步骤可以按下面进行：

1. 先完成不依赖 JavaScript 的分页版本，确认后续页和产品链接可访问。
2. 再用 JavaScript 增强为追加加载，不删除原有 URL 与链接语义。
3. 加载前显示明确按钮名称，例如“再显示 24 个产品”，而不是只有“More”。
4. 加载后保留焦点在按钮附近，播报新增数量和总数，不突然把用户送到页面顶部。
5. 到达末尾时明确显示“已显示全部”，并让页脚仍可到达。

Google 的文档把加载更多和无限滚动都视为常见 JavaScript 模式，同时提醒爬虫不会点击按钮。前端看起来是一页，不代表内容发现也可以只剩一页。Google Search Central：分页与增量加载

无限滚动什么时候不适合工业品目录？

当用户需要比较、返回、分享和到达页脚时，要非常谨慎

无限滚动最大的诱惑是界面干净：没有页码，没有按钮，用户继续滚就好。代价也藏在“继续滚”里。总量不清楚会产生滚动疲劳；页面持续追加后，内存和性能压力上升；页脚可能不断被推走；详情页返回时，如果不能恢复状态，用户会丢失刚才的位置。

W3C 的无障碍原则要求功能可由键盘操作，用户能定位内容并知道自己在哪里。W3C WAI：无障碍原则 WAI-ARIA 1.2 确实定义了可动态追加内容的 feed 模式，但它要求向辅助技术表达条目、加载和集合关系，属于需要认真实现与测试的复杂方案，不是一句 role="feed" 就完成。WAI-ARIA 1.2：feed

下列情况优先放弃无限滚动：

• 产品需要跨页比较、保存位置或分享具体范围。
• 列表后面有询盘入口、联系方式、下载或重要页脚导航。
• 团队没有能力维护浏览器历史、焦点、加载状态与错误恢复。
• 后续产品没有独立分页 URL 或普通链接可供抓取。
• 产品数量很大，持续追加会拖慢移动端或导致内存问题。

NeoGress 项目里怎样把长列表验收放进发布流程？

先确定产品主 URL，再测试列表如何到达它

NeoGress 的产品管理思路强调先把产品作为可复用对象整理，再用于产品页和内容。长列表设计应建立在这个前提上：每个公开产品有稳定主 URL，分类、分页或加载更多只是通往它的路径，不应该为同一个产品生成多份正文。

这并不代表 NeoGress 的所有项目都自动采用同一种分页方式。实际列表模式、每页数量、筛选与 URL 行为，需要在当前站点中核验。系统可以降低产品资料整理和更新成本，不能替企业决定哪些产品应公开，也不能替前端验收返回位置、键盘操作和抓取路径。

发布前做一次真实任务：从第 1 批进入第 3 批，打开一个产品详情，返回；刷新、复制地址到新窗口；禁用 JavaScript再访问；最后只用键盘完成翻页或加载。记录每一步看到的产品顺序、页码 URL、canonical、焦点与滚动位置。没有这份证据，“体验很好”通常只是测试者还没走到第二页。

B2B 产品列表分页 SEO 上线前怎么验收？

用四条路径确认后面的产品没有被藏起来

1. 无 JavaScript 路径： 从分类第 1 页通过真实链接走到后续页和产品详情。
2. 返回与分享路径： 在后续页打开产品后返回，位置与筛选条件保留；复制 URL 能复现相同列表段。
3. 搜索路径： 每页返回 200、使用自引用 canonical，超范围页返回 404；Sitemap 与内链不提交重复排序版本。
4. 无障碍与移动路径： 键盘能操作前后页或加载按钮，焦点不丢失，新增结果有反馈，页脚可到达，窄屏无横向溢出。

最后抽查第 1 页、第 2 页、中间页、最后一页和超范围页，再抽五个只出现在后续页的产品。如果任何一个产品只能靠“往下滚到系统心情好时加载出来”，它就还没有获得稳定入口。

FAQ

产品列表每页放多少个产品最好？

没有统一数字。应结合产品卡片信息量、图片大小、移动端性能和采购比较任务测试。每页数量要稳定，避免频繁变化导致产品在不同页之间跳动并破坏返回位置。

分页第 2 页需要独立 title 和 description 吗？

Google 说明分页序列可以使用相同 title 和 description，并尝试识别页面序列。更重要的是每页有唯一 URL、自引用 canonical 和可跟随链接；页面标题是否区分页码可按用户清晰度决定。

第 2 页应该 canonical 到第 1 页吗？

不应该。Google 当前分页指南明确建议每个分页页面使用自引用 canonical。把全部后续页指向第 1 页，可能削弱后续产品列表的独立发现路径。

加载更多按钮一定要有 URL 吗？

界面按钮本身可以由 JavaScript增强，但其背后的下一批内容应能通过独立分页 URL 与真实链接访问。这样用户刷新、分享或禁用 JavaScript 时仍有路径，爬虫也不需要模拟点击。

无限滚动可以通过 Sitemap 解决收录吗？

Sitemap 能补充产品 URL 的发现，但不能修复返回位置、键盘操作、列表语义和站内链接缺失，也不保证索引。需要公开的产品仍应从网站结构获得清楚入口。