分页与无限滚动 SEO QA 检查清单

分页和无限滚动不只是界面选择，它们决定商品、文章、职位、案例和资源能否通过内链被发现。加载动画再流畅，也无法弥补首屏以外没有可抓取路径的问题。

先决定哪些页面应该独立进入索引。大多数团队希望分类或 Collection 首页被索引，而更深层页面用于发现内容，同时避免争夺同一个查询。开发前写下这项决定，让 Canonical、Title、Sitemap 与筛选规则采用同一模型。

• 列出所有分页模板：Collection、Search、Blog Archive、Resource、Case Study 与 Account History。
• 估算常规与最大结果数、页面深度、更新频率及自然搜索价值。
• 为每个模板选择数字分页、Load More、Infinite Scroll 或混合方案。
• 记录第 2 页及更深页面是允许索引、仅用于抓取，还是通过 Canonical 合并。

每批有价值的内容都应通过普通链接和稳定 URL 访问，例如 `?page=2` 或统一的 path pattern。搜索爬虫不会可靠地模拟用户持续滚动，只运行 JavaScript 的按钮也可能让后续内容全部隐藏。

每个分页 URL 的 HTML response 应直接包含本页项目和导航链接，不依赖 browser event。Hydration 完成后，无限滚动可以增强体验，但不能成为内容唯一入口。

• 关闭 JavaScript 打开第 2 页，确认目标项目与链接仍在 HTML 中。
• 确认每个下一页 URL 可直接返回 200，不依赖 Session Storage 或前一次请求。
• Next、Previous 与必要页码使用真实 `<a href>` 链接。
• 最后一页之后停止生成链接，不可能的页码返回明确的 404。
• HTML、Sitemap、Canonical 与 Analytics 中的参数顺序和 URL 格式保持一致。

不存在把所有分页 URL 都 Canonical 到第 1 页的通用规则。如果深层页面包含其他地方没有链接的商品或文章，把所有信号合并到首页可能削弱发现能力。通常应让每页 Self-reference Canonical，除非经过验证的 View All 页面确实代表完整结果集。

Robots 规则必须与目标一致。Noindex 页面最终可能无法稳定传递发现链接，而 robots.txt block 会让爬虫看不到 Canonical 或 Noindex 指令。不要在不理解处理顺序的情况下组合这些设置。

• 检查第 1 页、第 2 页、最后一页、筛选页面与无效页面的 Canonical。
• 让 Title 与主 Heading 有意义，同时避免在可见文案中堆砌重复页码。
• 避免可索引分页 URL 与 Noindex、robots.txt、Sitemap 规则互相冲突。
• 不要把过时的 `rel=next` 与 `rel=prev` 当作主要发现或合并策略。
• 让多语言与移动 URL 版本遵循同一套 Canonical policy。

用户跨过页面边界时，用 History API 更新 browser URL，让当前可见状态可以分享和恢复。不要每滚动几像素就创建 history entry，而应在稳定边界更新，并明确何时使用 replace、何时使用 push state。

返回列表是收入与可用性要求。用户打开第 37 个商品再返回时，应回到该商品附近并保留筛选与排序，而不是回到空白的第 1 页顶部。只保存必要状态，并通过 URL 重建列表，不要依赖脆弱的完整 DOM snapshot。

• 加载多个批次后复制 URL，并在干净 browser session 中打开。
• 同一 Tab 打开详情再返回，确认列表位置、筛选和已加载范围都恢复。
• 在每个页面边界测试 Refresh、Deep Link、Back、Forward 与 Share。
• IntersectionObserver 或 JavaScript 失败时，提供可见的 Load More 或分页 fallback。
• 向辅助技术播报新增结果，但不要意外移动 keyboard focus。

无限列表可能产生无限 DOM。只追加用户需要的内容、预留媒体尺寸，并在结果很大时谨慎使用 virtualization。虚拟列表不能移除可抓取的服务端链接，也不能破坏键盘导航、页面内查找、Analytics 与位置恢复。

重点测量批次之间的过渡。加载过程不应推动 Footer、跳动 Focus、重复卡片或阻塞 Main Thread。首屏很快但越滚越慢，仍然不是合格的生产体验。

• 为 Card、Image、Ad 与 Loader 预留空间，避免 Layout Shift。
• 懒加载首屏以下媒体，同时正确提高首屏关键图片的优先级。
• 筛选或排序变化时取消过期请求，并对重叠 response 去重。
• 在低内存移动设备与限速网络上测试真实最大深度。
• 多次加载后测量 LCP、CLS、INP、内存增长、请求数与 DOM size。

分页缺陷常在两次请求之间结果集发生变化时出现。价格排序、库存更新或内容发布可能让项目跨页移动，产生重复或缺口。Cursor-based pagination 可以提高快速变化 Feed 的一致性，但如果内容依赖自然搜索，Cursor 仍需要配套 URL 策略。

Filter、Locale、Currency 或 Sort Order 变化时必须重置分页。界面、API Query、URL、Canonical、Result Count 与 Analytics Event 应描述同一个状态，绝不能静默沿用另一组筛选条件下的第 5 页。

• 分别在第 1 页、第 2 页和多次无限滚动后修改筛选条件。
• 测试零结果、一个结果、刚好一整页、多一个结果和最大数据集。
• 模拟 Session 期间项目新增、删除、取消发布或移动。
• 确认 Locale、Market、Currency、Customer Segment 与 Inventory 规则不会泄漏旧结果。
• 确认 API 使用稳定的 Secondary Sort Key 提供确定性顺序。

只有每张卡片都指向正确 Canonical destination，并且 Analytics 只记录一次用户动作，列表才算完成。Re-render、Prefetch 与 State Restore 很容易造成重复 Page View 或 Product Impression，应围绕明确的页面边界与可见阈值定义 Event。

键盘和 Screen Reader 用户需要可理解的自动增长页面替代方案。保留 Focus、提供 Status Update、确保 Footer 可到达，并在连续加载形成陷阱时允许暂停或改用明确的 Load More。

• 抓取 rendered links，对比 Item URL、Canonical、Status Code 与 Redirect。
• 确认 Impression 去重，Click 保留列表位置与 Campaign Context。
• 测试纯键盘加载、Focus Order、Screen Reader Announcement 与 Reduced Motion。
• 分页控件满足触控尺寸要求，并清楚标记目标页面。
• 分别验证同意 Consent、拒绝 Consent 与 Returning Session 的 Analytics。