列表页通常是详情页 URL 被发现的第一站。搜索蜘蛛顺着列表中的链接往下走，能拿到多少详情地址、翻页是否顺畅、加载更多是否可抓，都会影响抓取路径的完整度。与其只看 Sitemap 提交了多少 URL，不如回到列表页，核对它实际递出了哪些入口。
翻页链接要能被直接抓取
传统分页不该依赖 JavaScript 点击。如果翻页地址写在 href 里，蜘蛛可以逐页跟进；如果只是按钮绑定事件，抓取路径容易在第二页断掉。核对时可以在关闭脚本的环境下查看列表页，确认下一页、页码链接是否仍然存在。
- 页码链接使用可解析的 URL，例如 /list?page=2 或 /list/page/2。
- 不要用 nofollow 屏蔽翻页，除非该分页确实不需要被抓取。
- 最后一页之后不要返回 200 空列表，容易形成空入口。
加载更多与无限滚动需要补入口
点击加载更多、滚动加载的列表，详情链接往往在脚本执行后才出现。蜘蛛可能只看到首屏若干条。可以保留一个可抓取的“查看更多”链接，指向下一批数据；或者把加载更多对应的接口地址转成静态分页，供抓取使用。
如果页面必须依赖脚本，至少保证首屏链接是 HTML 中直接存在的，并给后续批次留一个普通链接入口。
分页参数要收敛，避免重复发现
同一个列表可能通过 page、offset、start、last_id 等多个参数组合访问。参数越多，蜘蛛可能把同一批内容当成不同页面反复抓取。建议固定一种分页命名，其他旧参数做 301 到规范地址，并在日志里观察哪些参数被高频访问。
- 确定主分页参数，例如 page。
- 排序、筛选参数只保留必要维度，避免与分页组合出大量 URL。
- 对空结果页、超出范围页返回 404 或 410，不要让它们参与抓取队列。
Sitemap 与内链的分工
Sitemap 适合提交详情页、栏目页的规范地址，但它不能替代列表页的抓取路径。列表页负责让蜘蛛按站内结构发现新内容，Sitemap 负责补充入口较深或更新频繁的地址。两者都指向同一批 URL 时，要保持规范地址一致，避免参数版和静态版混用。
- 列表页链接：负责日常发现和更新信号。
- Sitemap：负责兜底提交和批量核对。
- 日志：负责验证两者是否都被抓取，以及抓取是否落到同一规范地址。
服务器响应影响翻页节奏
列表页抓取通常呈批量连续请求。如果服务器响应变慢，蜘蛛可能降低翻页速度，甚至只抓前几页就离开。检查日志时，可以把列表页请求按时间窗聚合，观察响应时间、状态码和翻页深度是否同步变化。持续 5xx 或长时间高延迟，会让抓取路径变短。
用日志核对列表到详情的链路
在日志中筛选列表页地址，看蜘蛛实际访问了哪些页码，再对照详情页日志，判断哪些详情 URL 是从列表页被发现的。重点看三件事：翻页是否连续、详情链接是否被跟进、空列表是否仍返回 200。发现断点后，优先修链接和状态码，而不是反复提交 Sitemap。
- 翻页连续：从第 1 页到第 N 页的请求是否均匀出现。
- 详情跟进：列表页抓取后，是否出现对应详情页请求。
- 异常状态：空列表、越界页码是否返回 200。
把列表页当作 URL 发现的第一入口来维护，比只盯着抓取总量更有用。翻页链接可抓、加载更多有补位、分页参数收敛、服务器稳定，再配合 Sitemap 和日志核对，就能让详情页 URL 的发现路径更清楚。