JavaScript SEO 实战：Googlebot 两波索引、5 秒渲染超时与 DOM 一致性排查

这篇文章把 Googlebot 处理 JS 页面的流程拆成抓取、WRS 渲染、索引三段，重点讲了两波索引带来的时间差、5 秒执行预算，以及客户端渲染常见的四类翻车场景。适合用 React、Vue、Next.js 做站、担心内容进不了索引的团队对照自查。

Googlebot 的三段式处理流程

• 第一段是抓取：Googlebot 拿到服务器返回的初始 HTML、HTTP 状态头和 robots 指令，静态站此时正文、图片、链接都在，索引器可以立刻解析并抽取外链。
• 第二段是渲染：客户端渲染的页面初始 HTML 往往只有一个空容器（如 div id=app）加几个 bundle 脚本，第一波没有内容可索引，URL 被丢进渲染队列。
• 第三段是索引：等算力允许，WRS 在无头 Chromium 里加载页面，下载样式、执行 JS、发 API 请求、构建完整 DOM，之后才把文本和链接交给索引器。
• WRS 用的是常青版无头 Chromium，能执行现代 ECMAScript 特性和 Web Components，所以问题通常不在“能不能跑”，而在“跑不跑得完”。

两波索引的时间差有多大

• 第一波只索引原始 HTML 里的文本。如果页面返回空壳或 loading 占位符，被索引的就是这些占位字符串。
• 第二波渲染要排队等算力，延迟取决于站点权重、抓取需求和 Google 全球服务器负载。
• 高权重新闻站可能几分钟内完成第二波；小站或 5 万 URL 级别的电商目录，延迟常以天甚至周计，新品上架后长时间不进索引。
• 导航菜单如果靠 JS 事件而不是标准 a href 标签，第一波抓取时内部链接数为零，链接发现被整体推迟。

四类高频失败场景

• 5 秒执行超时：WRS 大约给 5 秒执行预算，串行多次 API 调用或复杂状态计算超时后，浏览器直接中止，只取中止那一刻的部分 DOM，评论、规格等区块就此丢失。
• 非标准链接：Googlebot 只解析标准 a 标签的 href，SPA 常用的 click handler、button 元素、hash 路由都不会被当作链接。
• 水合与元数据不一致：客户端渲染后覆盖的 canonical、title、结构化数据，可能与原始 HTML 里的版本冲突，造成索引信号混乱。
• robots.txt 误屏蔽 JS 资源：把 bundle 或 API 路径挡掉，WRS 拿不到脚本，页面永远渲染不出来。

渲染方案怎么选

• CSR：TTFB 快（约 50–150ms），但可索引性风险高，WRS 成本高，适合登录后或不需要 SEO 的页面。
• SSR：服务器直接返回完整 HTML，不依赖第二波渲染队列，代价是服务器压力和缓存设计。
• SSG / ISR：构建期或增量生成静态 HTML，同样绕开渲染队列，适合内容更新频率可控的站点。
• Dynamic Rendering：对爬虫返回预渲染版本，属于过渡方案，维护两套输出要小心内容不一致。

DOM 一致性审计怎么做

• 核心动作是对比原始服务器响应和 JS 执行后的 DOM，看 canonical、meta title、结构化数据、正文、内链是否都出现在最终 DOM 里。
• 工具上可以用 Chrome DevTools 看渲染结果，或用站点审计工具批量抓取渲染后的 DOM 做比对。
• 重点抽查模板页、分页、筛选参数页这类最容易在客户端才拼出内容的 URL 类型。
• 发现差异后优先改成服务端输出关键标签，而不是等 WRS 去补。