单页应用做 SEO，服务端渲染和预渲染怎么选

能 SSG 就别 SSR，能 SSR 就别预渲染，能预渲染就别硬扛纯客户端渲染。选型只看两件事：内容更新频率、页面数量。

三种方案各自适合谁

SSG（构建时生成 HTML）：文档站、营销页、博客、产品功能介绍页。内容不是每分钟变，页面几千到几万个都在射程内。成本最低、速度最快。2025 年 4 月一个开发者文档站 4200 页改 Next.js 的 SSG，初始 HTML 直接带全文，上线两个月收录率 92%，LCP 也从 4.1 秒降到 1.3 秒。

SSR（请求时服务端渲染）：价格页、搜索结果页、带登录态的个性化页面。需要 Node 服务，运维成本高；缓存配不好，TTFB 会比 SSG 慢一截。适合内容必须实时的场景。

预渲染：给蜘蛛返回提前渲染好的静态快照，真实用户还是走原 SPA。适合改造成本卡死、只求先被收录的团队。代价是快照会过期，要定时刷新，百度对快照的识别也不如 Google 稳定。

2025 年 7 月的救急改造

一个 SaaS 站 600 个页面，前端是纯 React SPA，初始 HTML 只有挂载点。团队排不出重写排期，先用预渲染顶上：三周内收录从 180 涨到 520。

问题随之而来。价格页的快照一周才刷一次，中间改价后展示的是旧价格，客服接到一堆投诉。后来把价格页单独改成 SSR，其余页面保留预渲染，才稳定下来。这个组合很常见——高频变化的少数页面走 SSR，长尾页面走静态。

判断清单

• 内容一周才变一次，页面是列表型 → SSG
• 内容每次请求都可能不同 → SSR
• 已有 Node 服务、团队有人维护 → SSR 成本可接受
• 只求收录、不求实时 → 预渲染
• 以上都做不到 → 至少把 title、H1、正文前三段、内链塞进初始 HTML，别全靠 JS

成本对照

我们报过价的三个方案，以 800 个页面的 SaaS 站为例：纯预渲染接入大约 2 到 3 人周，主要成本在快照刷新和监控；SSG 改造 6 到 8 人周，要动路由和数据层；SSR 改造 10 人周以上，还得配 Node 服务、缓存和日志。预算差距在五倍左右，所以选型不能只看"哪个先进"。

改之前先确认到底缺什么

用 curl 拉一下页面，看初始 HTML 里有没有正文。有的站其实 SSR 做了，只是 H1 和正文用了懒加载；有的站缺的只是内链。整站重构之前先定位缺口，能省下一大笔预算。

我们接过一个客户，被外包公司报了 40 万的 SSR 改造，实际问题是模板里把正文渲染在 JS 之后，改模板花了两天。