什么是服务端渲染？| SEO 术语表

服务端渲染（SSR）是一种渲染策略，页面的 HTML 在请求时由服务器完整组装，并作为完整文档发送到浏览器。首次响应就已包含文本、链接和元标签，因此在任何 JavaScript 执行之前，页面就已具备含义。

为什么重要

搜索引擎和 AI 爬虫会在 JavaScript 执行上花费真金白银的预算。Googlebot 采用两段式模型，先解析初始 HTML，再进行延迟的 JS 渲染阶段，而交付一个空白的客户端渲染外壳可能会延迟甚至完全跳过索引。像 GPTBot、PerplexityBot 和 ClaudeBot 这样的 AI 爬虫大多根本不执行 JS，这意味着 CSR 对答案引擎来说实际上是不可见的。SSR 一举解决了这个问题，同时还改善了 Core Web Vitals，它是 SEO 和 GEO 中杠杆率最高的技术决策之一。

CSR、SSR、SSG 与 ISR 对比

策略	渲染位置	首屏 HTML	适合 SEO	适用场景
CSR（客户端渲染）	浏览器	空白外壳	弱	登录后的仪表盘
SSR（服务端渲染）	服务器，每次请求	完整	强	动态、个性化内容
SSG（静态站点生成）	构建时	完整	最强	博客、文档、营销页
ISR（增量静态再生成）	构建 + 周期性再生成	完整	最强	频繁更新的静态页面

SEO 优先级大致为 SSG ≈ ISR > SSR > CSR。Next.js、Nuxt、Remix 和 SvelteKit 等框架允许你在同一个代码库中混用这些模式。

对 SEO 和 GEO 的影响

即时索引：内容在 Googlebot 的首次抓取中即可见，无需等待延迟的渲染阶段。新页面的索引时间从数天缩短到数小时。

AI 爬虫兼容性：GPTBot 及同类爬虫不执行 JS。没有 SSR，你的内容对 LLM 训练和搜索来说实际上并不存在。

改善 Core Web Vitals：LCP 在首屏 HTML 到达时触发，而非等到 JS 包下载并运行之后。FCP、LCP 和 TTI 都会得到改善。

可靠的元标签：Open Graph、搜索摘要和结构化数据必须出现在首次响应中才能被信任。CSR 会向 Twitter、Facebook 等社交爬虫发送空的元标签。

渐进增强：即使在禁用 JS、网络缓慢或设备老旧的情况下，内容依然可访问。

SSR 的权衡

更高的服务器成本：每次请求生成 HTML 都会消耗 CPU、内存和基础设施资源。CDN 缓存和 ISR 可以缓解这一问题。

可能增加 TTFB：繁重的服务端逻辑会延迟首字节时间。数据库查询和外部 API 会成为瓶颈。

复杂性：水合不匹配、服务端与客户端的环境差异，以及缓存失效，都会增加调试成本。

个性化限制：针对每个用户的 SSR 难以缓存。常见模式是共享外壳加客户端个性化。

水合及其陷阱

SSR 交付 HTML 后，客户端通过重新挂载 JavaScript 使其具备交互性，这一过程称为"水合"。可能出错的地方包括：

水合不匹配：当服务端渲染的 HTML 与客户端首次渲染的结果出现分歧时，React/Vue 会抛出警告，往往表现为可见的闪烁或行为异常。

水合成本：对大型页面进行水合会阻塞主线程，损害 INP。部分水合、React Server Components 和 Astro islands 是替代方案。

SSR ≠ 更小的包：SSR 并不会缩减客户端包体积。两者仍都需要优化。

何时使用 SSR

内容依赖 SEO/GEO 流量（博客、新闻、电商、文档）
用户专属数据必须出现在首次绘制中（个性化仪表盘）
动态 OG 标签对社交分享很重要
你的目标是获得 AI 搜索引用

何时 SSR 属于过度设计

需登录的仪表盘（无 SEO 顾虑）
静态内容，SSG 更快也更便宜
极小型站点，单个静态 HTML 文件就足够

常见错误

对所有内容都做 SSR：静态内容以 SSG/ISR 形式交付更快也更便宜。为每条路由选择正确的模式。

未做缓存就访问 API：每次请求都拉取数据而不缓存会让 TTFB 暴增。使用 SWR 或缓存头。

忽视水合不匹配：控制台警告意味着 Google 看到的 HTML 与用户看到的不同，这是 SEO 风险。

仅在客户端设置元标签：元标签必须存在于 SSR 响应的 head 中，爬虫才能读取到。

盲信框架默认值：Next.js 和 Nuxt 不会总是自动选对模式。请为每条路由显式设置。

Sources: