CSR、SSR、SSG、Prerendering、Hydration、Dynamic Rendering 和 Googlebot WRS 有什么区别？

核心区别速查

概念 HTML 主要生成位置 生成时点 搜索与运维重点

-- --- --- ---

CSR 浏览器 访问后 依赖脚本、API 和渲染成功

SSR 应用服务器 每次请求或缓存命中 首始 HTML 完整、服务器容量

SSG 构建系统 发布前 更新触发、页面规模、缓存

Prerendering 构建或渲染服务 提前 快照新鲜度、交互启动

Hydration 浏览器 HTML 到达后 DOM 一致、JS 体积、可交互时间

Dynamic Rendering 按 User-Agent 分流 请求时 内容等价、复杂度、Cloaking 风险

CSR 是什么

Client-Side Rendering 通常先返回 App Shell 和 JavaScript Bundle，浏览器下载脚本、调用 API，再创建主要 DOM 内容。

用户看到内容依赖脚本成功执行。若 Bundle 被阻止、API 失败、Runtime Error 或超时，初始 HTML 可能几乎没有可索引正文。

CSR 的优势

CSR 适合登录后应用、复杂交互和客户端状态频繁变化的界面。完成启动后，站内切换可少做整页导航，并复用已加载代码与数据。

但优势来自具体实现，不代表所有 SPA 都更快；过大的 Bundle 和长任务会推迟内容与交互。

CSR 的搜索风险

Google Search 可以运行 JavaScript，但处理有阶段与资源限制。其他搜索引擎、社交预览器、审计工具或 AI 抓取器可能不执行脚本。

公开、需要发现的核心内容若只存在于客户端渲染结果，鲁棒性弱于直接包含在 HTTP HTML 响应中。

SSR 是什么

Server-Side Rendering 在请求到达时由服务器执行应用逻辑并返回包含主要内容的 HTML。浏览器无需先完成应用启动就能看到正文。

后续可以加载 JavaScript Hydrate 页面，也可以保持为传统链接与表单驱动的网站。

SSR 的优势

首始 HTML 能被用户、爬虫和无 JavaScript 客户端直接解析，通常改善内容可见时间与分享预览可靠性。

它也能在服务器安全地访问后端数据，但返回给客户端的 HTML 仍不能包含 Secret。

SSR 的代价

每请求渲染会增加服务器 CPU、内存和 TTFB 压力；缓存、流式响应和边缘渲染能缓解，但也引入失效与一致性问题。

SSR 不会自动减少客户端 JavaScript。若仍发送完整 SPA Bundle，用户还要支付 Hydration 成本。

SSG 是什么

Static Site Generation 在构建或发布阶段为已知 URL 生成 HTML 文件，访问时通常由对象存储或 CDN 直接返回。

它适合文档、文章、产品说明等更新频率可控的公开内容。

SSG 的优势

运行时服务器负载低，页面可高度缓存，初始 HTML 稳定。爬虫不依赖执行 JavaScript 才能获得正文和普通链接。

安全面也较小，因为请求时不必执行完整应用渲染逻辑。

SSG 的代价

URL 数量和内容规模增大时，全量构建可能很慢；内容更新需要重建或增量再生成，并处理 CDN Cache Invalidation。

构建成功也不代表数据新鲜，必须监控源数据版本、构建时间和实际线上 HTML。

Static Rendering 与 SSG

这两个词经常近似使用，均强调提前生成可直接返回的 HTML。具体框架对 SSG、Export、Prerender 的定义可能不同。

比较方案时应记录“何时运行页面代码、生成哪些 URL、是否仍需客户端启动”，不要只比较产品标签。

Prerendering 是什么

Prerendering 可指在构建时运行客户端应用并捕获其初始 HTML。web.dev 特别区分这种做法与浏览器为未来导航做的 Speculative Prerender。

预渲染快照可以改善 FCP，但若页面仍必须 Boot 完整客户端应用才可交互，用户仍承担脚本成本。

Prerendering 与 SSG 的区别

二者都可提前产出 HTML，边界取决于工具。SSG 往往直接以数据与模板生成静态页面；Prerendering 常强调把客户端应用运行结果捕获成 HTML。

对搜索而言，关键不是名称，而是 HTTP 响应是否含最终核心内容、链接与元数据。

Hydration 是什么

Hydration 在浏览器中运行 JavaScript，把事件处理、状态和交互能力附加到服务器或静态生成的现有 HTML 上。

页面可能先能阅读，稍后才真正可交互。加载阶段需要保证服务器 DOM 与客户端首轮期望一致。

Hydration Mismatch

如果服务器和客户端渲染出不同文本或结构，框架可能警告、丢弃节点、重新渲染或产生闪烁。常见原因有时区、随机数、客户端专属 API 和数据版本变化。

搜索爬虫可能记录重写后的 Rendered DOM，而用户先看到的是服务器 HTML；两者差异需要测试。

Hydration 不等于 SSR

SSR 负责生成 HTML，Hydration 负责恢复客户端交互。一个 SSR 页面可以没有 Hydration，一个静态页面也可以 Hydrate。

把两者拆开有助于判断问题在服务端内容生成还是客户端启动。

Partial 与 Selective Hydration

现代架构可只为需要交互的组件发送或运行 JavaScript，减少主线程工作。Islands、Partial Hydration 与 Resumability 等术语有不同框架实现。

这些优化不能替代搜索基本验证：核心内容与链接仍应在稳定 HTML 中存在。

Dynamic Rendering 是什么

Dynamic Rendering 检测 User-Agent 或爬虫能力，把请求送往 Rendering Server，为机器人返回静态 HTML，同时普通用户仍走 CSR。

它解决的是爬虫兼容，不是普通 SSR 的同一套用户渲染架构。

Google 对 Dynamic Rendering 的立场

Google 把 Dynamic Rendering 定义为 Workaround，而非推荐的长期解决方案；更推荐 SSR、Static Rendering 或 Hydration。

原因包括额外基础设施、缓存复杂度、版本漂移和错误路径增多。

Dynamic Rendering 是否是 Cloaking

只要爬虫版与用户版内容相似，Google 通常不把这种兼容实现视为 Cloaking。若向爬虫提供完全不同、用于操纵排名的内容，就可能构成 Cloaking。

“相似”不能只比较正文数量，还应检查链接、结构化数据、Canonical、Robots 指令和关键交互结果。

Bot Detection 的问题

User-Agent 列表会变化，也可能被伪造。分流错误会让普通用户收到快照，或让爬虫落回失败的 CSR 路径。

缓存键若没包含正确变体，还可能把 Bot HTML 错发给用户，形成严重一致性事故。

Googlebot WRS 是什么

Web Rendering Service 是 Google 用于渲染页面和执行 JavaScript 的组件，采用 Evergreen Chromium，但其运行环境与普通用户访问仍有差异和限制。

站点无法控制某个 URL 何时进入渲染队列，也不应把 WRS 当成自己的可用性测试浏览器。

Google 处理 JavaScript 的阶段

Google 文档把流程概括为 Crawling、Rendering 和 Indexing。首次抓取 HTML 后会提取可见链接，并把可渲染页面放入队列；WRS 处理后再次从 Rendered HTML 提取内容与链接。

抓取与渲染不是同一个瞬时动作，队列停留可能很短，也可能更久。

Initial HTML 为什么重要

服务器响应中的链接与正文无需等待 WRS 就能被初步发现和处理。App Shell 只有占位符时，重要信息全部推迟到渲染阶段。

初始 HTML 完整还能覆盖不执行 JavaScript 的其他爬虫和故障降级场景。

200 状态与渲染队列

Google 文档说明，返回 200 的页面通常会进入渲染队列，除非 Robots 指令阻止索引；非 200 页面可能跳过渲染。

因此 SPA 不能对所有不存在路由都返回 200 和同一个 Shell，否则会制造 Soft 404 与错误索引信号。

robots.txt 与资源

Googlebot 无法获取被 robots.txt 阻止的页面或关键 JavaScript、CSS、API 资源时，Rendered HTML 可能不完整。

不要为了节省抓取把页面渲染必需资源一律封禁；应通过 URL Inspection 查看实际加载失败项。

Robots Meta 的时机

Google 提醒，若初始 HTML 已含 noindex，它可能跳过后续渲染和 JavaScript 执行。指望客户端脚本删除 noindex 并不可靠。

索引控制应在服务器响应与最终 DOM 中保持一致，避免 JavaScript 先阻止再放开的设计。

JavaScript 链接

Google 可以从 Rendered DOM 中发现链接，但推荐使用带可解析 href 的真实 <a 元素。只有 Click Handler、Button 或 Fragment 状态不构成同等稳定的 Crawlable Link。

SSR 页面也可能因组件把导航渲染成无 href 控件而失去发现能力。

API 请求失败

WRS 渲染时，API 可能因鉴权、Cookie、CORS、限流、地理策略或短暂错误返回不同结果。页面不能假设爬虫具备用户会话。

公开索引内容应能在匿名、干净浏览器环境稳定获取。

Lazy Loading 风险

依赖用户滚动、点击或复杂 Intersection Observer 时，WRS 不一定触发内容加载。重要正文和链接不应只在用户交互后出现。

图片和非关键模块可延迟，但需要索引的文本应有确定的初始或自动渲染路径。

超时与长任务

过大的 Bundle、串行 API、无限 Timer 和主线程长任务会推迟或阻止 Rendered DOM 完成。真实用户性能问题也常与爬虫渲染失败同源。

拆包、减少脚本和直接输出核心 HTML，通常比为爬虫增加另一套复杂逻辑更可靠。

SSR 也可能搜索失败

SSR 只保证服务器尝试生成 HTML，不保证状态码、Canonical、Robots、Hreflang、结构化数据和内容质量正确。

服务端异常若被框架捕获后返回 200 空壳，同样会产生 Soft 404 或空内容索引。

SSG 也可能过期

静态 HTML 可能比数据库落后，DateModified 和 Sitemap lastmod 也可能被错误刷新。搜索引擎看到的是线上响应，不是 CMS 当前状态。

发布流程应验证生成文件、CDN 内容和 Canonical URL，而不是只看构建日志成功。

缓存一致性

SSR Cache、静态页面、API Cache 和客户端 State 可能分别更新。用户版、爬虫版与源数据版本漂移时，搜索信号会互相冲突。

应在响应中记录可脱敏的 Build ID 或 Content Version，便于比较各层。

如何选择架构

公开且长期可搜索的页面优先让核心内容出现在初始 HTML，可用 SSG、SSR 或两者混合。登录应用和高度个性化区域可更多使用 CSR。

Dynamic Rendering 只作为兼容遗留系统的临时方案，并制定迁移退出条件。

混合渲染

同一站点可对文章使用 SSG、库存页使用缓存 SSR、账户中心使用 CSR，并让必要组件 Hydrate。选择单位可以是 Route 或 Component。

混合模式的难点是版本、缓存和错误处理一致性，需要统一观测与测试。

验证 Initial HTML

用不执行 JavaScript的 HTTP 客户端检查状态码、Title、Canonical、Robots、正文与关键 href。不要把浏览器 Elements 面板的 DOM 当成原始响应。

再与浏览器关闭 JavaScript后的页面比较，识别核心内容依赖。

验证 Rendered HTML

使用 Search Console URL Inspection 或 Rich Results Test 检查 Google 获取的截图、Rendered HTML、资源错误和 Console Exception。

它们是诊断特定样本，不保证立即重新索引，也不能代替全站监控。

三方对比测试

为同一 URL 保存 Initial HTML、干净 Chromium Rendered DOM 和 Google 工具结果，比较 Title、Canonical、Robots、主标题、正文、链接及结构化数据。

差异应分类为预期交互变化、延迟数据还是实际索引风险。

日志与监控

监控服务器状态码、SSR/Build Error、Bundle 加载失败、API 失败、Hydration Warning、WRS 可见的 JS Exception 和渲染前后内容数量。

客户端 Analytics 可能无法完整代表 Googlebot/WRS 活动，应同时使用服务器日志和 Search Console Crawl Stats。

常见误区

常见错误包括“Google 能运行 JS，所以 CSR 永远没问题”“SSR 自动提升排名”“Prerender 等于 Hydration”“Dynamic Rendering 是推荐架构”以及“浏览器看到就代表 Google 已索引”。

渲染只是可访问性的一个环节，最终还涉及发现、Canonical 选择、内容质量和索引决策。

迁移策略

从纯 CSR 迁移时，先选择高价值公开 Route 输出完整 HTML，保证 URL 与 Canonical 不变，再逐步减少客户端必需代码。

不要同时更换域名、路由、框架和渲染方式，否则流量变化很难归因。

结论

CSR、SSR 和 SSG决定内容何时在哪里生成；Prerendering提前捕获 HTML；Hydration 恢复交互；Dynamic Rendering按爬虫分流，是临时兼容方案；WRS则是 Google 的渲染执行阶段。

搜索友好的目标不是追求某个标签，而是让匿名请求稳定获得正确状态码、核心 HTML、可抓取链接和一致元数据，并用 Google 工具验证最终结果。

官方参考资料

Google Search Central：JavaScript SEO Basics — https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

Google Search Central：Fix Search-related JavaScript problems — https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript

Google Search Central：Dynamic Rendering as a workaround — https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering

Google Search Central：How Google Search works — https://developers.google.com/search/docs/fundamentals/how-search-works

Google Search Central：Make links crawlable — https://developers.google.com/search/docs/crawling-indexing/links-crawlable

web.dev：Rendering on the Web — https://web.dev/articles/rendering-on-the-web