翻页入口：先确认它是可点击、可抓取的链接
列表页、标签页、归档页往往都有翻页。问题在于，很多模板把“下一页”做成了按钮：点击后由脚本拼接参数、追加内容，源码里只有一个 div 或 span。人看得见，抓取程序看不见。爬虫不会去点按钮，它只会沿着 a 标签的 href 走。如果翻页入口不是链接，第二页之后的内容基本等于对搜索侧关闭。
自查时可以直接禁用 JavaScript 看渲染前的源码，或者用查看源代码的方式确认翻页控件里到底有没有 href。
- “下一页”“上一页”“末页”是否为带 href 的 a 标签。
- href 是否指向真实可访问的地址，而不是 javascript:void(0) 或 #。
- 分页链接是否被 rel="nofollow"、onclick 或事件拦截。
- 翻页控件是否只在滚动到底部时才由脚本动态生成。
分页 URL 要收敛，别让参数无限膨胀
分页地址常见两种形态：路径式 /list/page/2/ 和参数式 /list?page=2。两种都能用，关键是同一个页面只对应一个地址。
- 不要同时存在 ?page=2、?p=2、?pageno=2 这类多套参数写法。
- 排序、筛选、每页条数等参数不要和页码混在一起，生成大量组合地址。
- 大小写、结尾斜杠在全站保持一致。
- 分页地址不要带会话 ID、追踪参数之类的临时字段。
页码上限与超范围页面的处理
有的站点允许翻到几百页甚至上千页，越往后内容越旧、价值越低，抓取预算却被大量消耗。更常见的问题是：超过实际页数后仍返回 200 和空列表，等于人为制造一批空页面。
建议给分页设一个合理上限，超出范围的请求返回 404 或 410。如果确实要保留旧内容，就把深分页收敛成归档入口，而不是让爬虫一页一页往下翻。
判断标准很简单：如果某个页码对应的列表，用户几乎不会看、站内也没有其他入口指向它，那它大概率不值得被单独收录。
分页页的标题、描述与 canonical
标题不要全站共用一句
所有分页共用同一个 title，会让搜索侧难以区分哪一页对应哪批内容。至少把页码或区间带进去，例如“某某列表 第 3 页”，让每个分页页有一个自洽的身份。
canonical 要指向分页自身
常见误区是把所有分页的 canonical 都指向第一页，希望“集中权重”。这样做的直接后果是，后续页面的内容不容易被当作独立入口。除非你有明确的合并意图，否则分页页的 canonical 指向自己更稳妥。
无限滚动要有可抓取的分页兜底
无限滚动对用户体验友好，对抓取不友好：内容按需加载，链接不在初始 HTML 里。可行的做法是保留一套传统的分页链接作为兜底，滚动只是视觉增强，底层结构仍然是 a 标签串联。也可以给每次加载生成独立 URL，但要注意别把同一批内容拆成过多地址。
用抓取日志验证分页覆盖率
改完之后别只盯着页面看，去日志里核对。
- 筛出分页 URL 的抓取记录，看爬虫是否真的访问到第二页、第三页。
- 观察返回状态码，确认没有大量 200 空页或 5xx。
- 对比分页抓取量与列表页实际页数，估算覆盖比例。
- 检查被抓取的分页是否集中在第一页，后续页几乎没有记录。
一份可执行的自查清单
- 翻页控件是可点击的 a 标签，href 指向真实地址。
- 同一页只有一个规范地址，参数不重复、不混杂。
- 分页设有上限，超范围返回 404 或 410。
- 分页页标题包含页码或区间，便于区分。
- canonical 默认指向自身，除非有明确的合并策略。
- 无限滚动场景下保留传统分页兜底入口。
- 日志中能看到深层分页被抓取，而不是只有第一页。
分页是内容站最容易被忽略的基础设施。它不需要复杂的技术改造，多数时候只是把按钮换成链接、把参数理一理、把上限定下来。做完这些，再去日志里确认一遍，比反复猜测“内容为什么没被发现”要实在得多。