2026年了，商品列表翻到第二页一直不进索引，是我把入口藏起来了吗？

结论先放前面：商品列表翻到第二页以后一直不进索引，多数不是爬虫抓得太浅，而是第二页从入口就没有独立的被抓路径——页面上没有 a 标签指向它，地址又和第一页共用筛选参数，内容还靠点击后才请求回来。2026 年按交付经验，先把可发现性和可索引性分开查，再决定是否动渲染方式，通常比直接给整站上 SSR 更省成本。

入口没通，和内容没直出，是两道不同的关

可发现性说的是爬虫能不能沿着站内链接走到这个地址；可索引性说的是走到之后，这个地址能不能拿到完整内容并被判定为独立页面。列表页第二页以后掉收录，多数情况卡在第一关：不是爬虫不愿意抓，而是它没有看到一个可以点的链接。

在内容型列表的项目里，比较常见的约束是排期紧、SEO 需求在联调后期才被提出来。可执行的做法是先把「点击加载更多」换成带 a href 的分页链接，地址里保留页码参数，再补一份只放分页地址的站点地图；这一步如果拖到上线后再补，往往要同时改列表组件、路由和埋点，返工一轮常见会多花三到五个工作日（经验区间），埋点口径也容易被打乱。

• 入口断掉：分页写成按钮加点击事件，没有 a 标签，爬虫无法沿链接继续往下走。
• 地址不可区分：第二页和第一页共用一个不带页码的地址，刷新或分享都会回到第一页。
• 内容后置：首屏只渲染第一页，后面几页靠滚动触发请求才回来，返回的 HTML 里没有对应内容。
• 信号互相打架：分页地址的 canonical 统一指向第一页，等于主动告诉搜索引擎这些是重复页。

四种常见的列表加载方式，收录表现差在哪

同样是列表，前端实现方式不同，爬虫拿到的东西差别很大。2026 年常见做法大致落在下面四类。判断时不要只看视觉体验，要看打开这个地址后，服务端返回的 HTML 里有没有内容。

• 静态路径分页（形如 /list/page/2）：地址独立、可直出、能进站点地图，收录表现更稳；代价是需要服务端支持重写规则，改造量中等。
• 查询参数分页（形如 /list?page=2）：同样可以被收录，参数写法本身不是障碍；风险在于筛选条件叠加后膨胀出大量低价值地址，需要做规范化。
• 点击加载更多：体验轻，但只用按钮触发请求时，第二页没有可发现的地址；补救方式是每次加载后用 pushState 生成独立地址，并在页面里保留可抓的分页链接。
• 无限滚动：对用户顺滑，对爬虫不友好；常见补救是给每一段结果一个独立地址，并保留一组可点击的分页或查看全部链接。

成本上的经验区间：把点击加载改成带 a 标签的分页并在路由层生成地址，通常一到三天可以完成；如果还要让分页内容直出，需要服务端或 SSR 配合，周期常见在五到十个工作日，具体取决于列表接口是否已经支持分页参数。前端这边可以自己闭环的是入口和内容直出，canonical 与站点地图通常要和后端或运维对齐。

排查分页收录，按入口—内容—信号三步核对

这套顺序的作用是避免一上来就改渲染。收录问题通常是链路问题，从入口往回退着查，比直接怀疑框架省时间。三步里任何一步没通过，后面的优化都容易被抵消。

1. 入口核对：打开列表页第一页，查看源代码或禁用 JS，确认第二页的链接是真实存在的 a href；如果只是按钮，先改这里。合格标准是：不执行任何交互，也能从 HTML 里找到指向第二页的地址。
2. 内容核对：直接访问第二页地址，确认返回的 HTML 里包含该页列表项；如果只有骨架屏，说明内容依赖运行时请求，需要预渲染或服务端渲染。合格标准是：关掉 JS 也能看到这一页的列表内容。
3. 信号核对：检查 canonical 是否自指、robots 有没有误拦带参数的地址、站点地图是否只提交了第一页、分页 TDK 是否与第一页完全相同。合格标准是：canonical 指向本页自身，分页地址能在站点地图里查到。

交付现场：排期只剩一周时先动哪里

在一个商品分类列表的交付里，团队当时剩一周就要提测，SEO 需求是联调阶段才加进来的，后端不方便立刻改渲染。约束条件很明确：不能上 SSR，也不能让列表接口全部重写。做法是只改前端能闭环的部分——把「加载更多」按钮换成带页码的 a 链接，URL 上保留 page 参数，列表接口仍按原分页参数返回同一份数据，同时请运维把分页地址补进站点地图。结果是第二页地址在提交后两三周开始出现抓取记录，代价是分页组件、路由和埋点要同步调整，前后多花了三到四个工作日（经验区间）。如果当时先动渲染，成本通常会上一个量级，常见区间是五到十个工作日，而且还不一定解决入口问题。

适合做分页收录的，和不必花力气的

这类优化的前提是分页本身有被搜到的价值。如果是登录后才能看到的订单列表、内部后台，或者筛选组合多到无法穷举的工具页，把精力压在分页收录上收益有限，优先保证第一页能被正常抓取和索引即可。

• 适合：文章列表、商品分类、问答库、职位列表等内容型或长尾流量入口，总量在百条以上、每页内容能独立成立。
• 可以简化：筛选组合极多、内容重复度高的列表，先用参数规范化收敛地址规模，再考虑分页收录。
• 不必强求：纯展示型站点、内容总量只有几十条，或者页面主要靠站内搜索进入的场景，通常只要第一页能被抓取和索引就够了，不必为每一页分页单独做收录优化。

验收口径与几个反复踩的坑

分页收录的验收不宜用「搜一下能不能搜到」来判断，那受站点权重和时间影响太大。更可核对的做法是看服务端日志里爬虫对第二页地址的请求是否出现，以及搜索平台的抓取统计里这批地址有没有被访问过。内容型站点从改完到看到抓取变化，常见区间是两到四周，新站会更慢，不能拿它当「做了没用」的依据。

• 踩坑一：canonical 全量指向第一页。这会直接把第二页并进第一页，属于主动放弃收录，改法是让分页 canonical 自指。
• 踩坑二：分页地址只存在于 JS 状态里。刷新即回到第一页，用户和爬虫都拿不到稳定地址。
• 踩坑三：筛选参数不做规范化。排序、颜色、价格组合能生成成百上千条地址，抓取预算被稀释，真正想收录的页面反而排不上。
• 踩坑四：分页 TDK 与第一页完全一致。虽不致命，但会降低分页内容的独立性；常见做法是列表名加页码或分类后缀，不要堆关键词。
• 踩坑五：把收录问题当成渲染问题。入口没打通就上 SSR，成本先花了，收录未必改善。

常见问题

分页地址写成 ?page=2 会不会影响收录？

不会因为写法本身被判为不可收录。真正影响的是这个地址能否被链接到、打开后能否直接返回内容，参数形式通常不是主要障碍。

无限滚动是不是一定不利于收录？

不是。只要每段加载出来的结果都有独立可访问的地址，并且页面里保留了可被抓取的链接，无限滚动也能被收录，代价是改造量更大。

分页页面标题需要单独写吗？

建议区分但不要堆词。常见做法是列表名加页码或分类后缀，保证第二页的标题、描述与第一页不完全一致即可。

rel=prev/next 现在还有必要写吗？

可以保留作为抓取提示，但不要把它当成收录开关。分页能不能被收录，主要还看入口是否可抓、内容是否直出。

分页链接放页面底部够不够？

够用。关键是链接必须是服务端可输出的 a 标签，这类服务端可输出的 a 标签在抓取路径上的作用，远大于它放在页面的哪个位置。

要动手的话，建议按这个顺序推进：先确认第二页有真实链接，再确认打开能拿到内容，最后处理 canonical 与站点地图；三步都过了再谈渲染升级。这套做法适合内容型列表页，不适合登录后列表和筛选组合过载的场景，后者优先做参数规范化，把地址规模收敛下来再看收录。2026 年做这类改造时，我们也会把这套清单作为前端与后端对齐的交付依据，具体口径可按官方文档或平台规范核对。