蜘蛛翻页，靠的是链接而不是页码

很多站点的列表页做成一个“翻页组件”，视觉上能点，代码里却没有可抓取的 href。蜘蛛不会去点按钮，它只认 HTML 里能解析出来的链接。如果第二页的地址只存在于 JavaScript 事件里，那么从第一页往后，蜘蛛的路径基本就断了。

判断一个列表页对蜘蛛友不友好，最直接的办法是：把页面 HTML 抓下来，看里面有没有指向下一页的 a 标签。

几种常见翻页写法和它们的差别

• 普通链接分页：每页都有独立 URL，链接写在 HTML 里。蜘蛛一路点下去没问题，是最省心的写法。
• 只有一个“下一页”链接：蜘蛛能顺着往下爬，但爬得慢，中间页要靠 Sitemap 或其他内链补。
• JS 渲染的翻页：链接在初始 HTML 中不存在，需要渲染后才能看到，蜘蛛能否拿到取决于渲染能力与渲染时机。
• 无限滚动：滚动触发加载，通常没有独立 URL。除非同时提供分页地址，否则深一点的条目蜘蛛基本看不到。

分页参数要收口，别让它无限长

带参数的分页（比如 ?page=、?p=、?start=）本身没有问题，问题出在参数组合。排序、筛选、视图模式、每页条数这些参数叠加起来，同一个列表能生成成百上千个地址。蜘蛛会把这些地址当成不同页面去抓，抓取预算被消耗在重复内容上。

比较稳妥的做法是：

1. 保留一套主翻页参数，其余筛选参数限制可抓取范围，必要时用 robots.txt 或 noindex 收口。
2. 翻页超过一定页数后，内容价值快速下降，可以不再向蜘蛛暴露链接，改用 Sitemap 覆盖真正重要的条目页。
3. 排序类参数不要生成可抓取链接，除非它有明确的独立价值。

翻页深度：让蜘蛛翻到哪一层就够

列表页的价值在于把详情页暴露出来。如果详情页本身已经通过栏目、相关推荐、Sitemap 等多条路径可达，那列表页翻到几十页之后的部分，对蜘蛛来说并不是必须的。反过来，如果某个详情页唯一的入口就是列表页第 30 页，那它大概率长期处于没被翻到的状态。

判断标准很简单：一个页面如果没有任何一条不依赖深度翻页的路径能到达它，它被发现的概率就低。要么给它补内链入口，要么放进 Sitemap。

和 Sitemap、内链怎么配合

分页、内链、Sitemap 是三件事，但解决的是同一个问题——让蜘蛛知道有哪些 URL 值得来。列表页负责近处的发现，内链负责页面之间的横向关联，Sitemap 负责兜底的清单。三者重叠没关系，重叠本身也是给蜘蛛的确认信号。

需要注意的是，Sitemap 里放的应该是详情页、栏目页这类相对稳定的地址，而不是把 ?page=2 到 ?page=200 全部塞进去。分页地址更新频繁、单页价值低，混进清单反而稀释了信噪比。

服务器响应会直接影响翻页能不能走完

翻页路径是一条串行的路：第一页到第二页再到第三页。任何一环超时或返回错误，后面的就都断了。列表页通常还是站点里查询最重的页面之一，缓存没做好时，蜘蛛连续翻页很容易触发慢响应。

• 列表页做页面级缓存，减少数据库压力。
• 保证翻页请求的响应时间稳定，避免个别页偶发超时。
• 不要对蜘蛛的翻页请求做过度限流，否则它可能判断站点不稳定，降低整体抓取频率。

用日志确认蜘蛛到底翻到哪了

猜没有意义。翻出最近的服务器日志，筛选蜘蛛 UA，看它请求的列表页 URL 分布：是集中在第 1 到 3 页，还是能稳定走到第 10 页以后；是每天来一次，还是几周才来一次。如果发现它长期只停在前几页，问题通常出在链接可抓取性或者响应速度上，而不是蜘蛛不想抓。

把这些数据和你自己的预期对一下，再决定是补内链、调分页写法，还是把重点条目交给 Sitemap。分页这件事改动成本很低，但它是蜘蛛在站内行走的主干道。