Appearance
前端框架与 SEO：SPA / SSR / SSG 的可索引性
最后更新：2026-08-19
本主题要回答的问题
- 为什么"前端框架（SPA）SEO 差"？JS 渲染到底挡了什么？
- SSR、SSG 如何解决 SPA 的 SEO 问题？各适合什么场景？
- 前端工程师选框架时，应该把 SEO 放在哪个决策维度？
本文是 前端技术主题 与 SEO 主题 的交叉点：前端框架决定"渲染出的 HTML 里有没有内容"，SEO 决定"这些内容能不能被索引推荐"。
一、SPA 的 SEO 问题：内容在 JS 里
SPA（单页应用）页面加载时，HTML 往往只有一个空的 <div id="root"></div>，真正的正文由 JavaScript 在浏览器里渲染。
| 问题 | 后果 |
|---|---|
| 首屏 HTML 无正文 | 爬虫抓到空壳，索引阶段存不进关键词 |
| 内容靠 JS 拉取 | 依赖 JS 渲染的爬虫处理延迟、不稳定 |
| 前端路由切页 | 切换后 URL 可能不变（早期），无独立索引单元 |
| bundle 巨大 | LCP 慢，Core Web Vitals 差，间接拖累排名 |
现代爬虫（Googlebot 新版）能执行 JS，但"能执行"≠"都执行"：它受渲染预算限制、渲染结果有延迟、失败时不索引。所以把关键内容放到服务端渲染出来的 HTML 里，仍是稳健的做法。
二、三类方案的 SEO 对比
| 方案 | 首屏 HTML 是否有内容 | SEO 表现 | 适用 |
|---|---|---|---|
| 纯 SPA（CSR） | 空壳 | 差（依赖 JS 渲染） | 登录后台、内部工具 |
| SSR | 服务端渲染出完整 HTML | 好 | 动态内容电商、新闻 |
| SSG | 构建期生成静态 HTML | 最好 | 博客、文档站 |
| 混合（SSG+SSR/ISR） | 看页面配置 | 好且灵活 | 内容+动态混搭 |
详细原理见 SSR/SSG 与元框架。核心结论：内容是否在"爬虫直接拿到的 HTML"里，决定了它 SEO 好不好。
三、SSG：文档站的 SEO 最优解
对内容在构建期已知的站点（博客、文档、手册），SSG 是 SEO 的最优选择：
| 优势 | 说明 |
|---|---|
| 完整静态 HTML | 每个页面直接落盘完整正文，爬虫零 JS 也能索引 |
| 首屏极快 | 无 JS 渲染等待，LCP 优，CWV 达标 |
| 资源指纹 | 静态文件加 hash，缓存友好 |
| 部署简单 | 任意静态托管/CDN 即可 |
四、SSR/SSG 仍有要注意的 SEO 细节
即使用了 SSR/SSG，前端工程师还要处理这些技术点（对应技术 SEO）：
| 细节 | 作用 |
|---|---|
每页唯一 <title> 与 description | 排名 + CTR |
canonical 统一 URL | 去重，防止同一页多版本 |
| 结构化数据（JSON-LD） | 富摘要，让引擎懂语义 |
| 语义化标签 | h1/h2、article、nav 辅助内容解析 |
| 站点地图 | 提交 sitemap 帮助发现页面 |
| 预渲染检查 | 验证"爬虫视角"的 HTML 是否含正文 |
五、前端选型的 SEO 决策框架
| 站点类型 | 建议方案 |
|---|---|
| 博客 / 文档 / 官网 | SSG（VitePress、Next.js 静态导出、Astro） |
| 电商 / 动态内容 | SSR（Next.js、Nuxt）或 SSG+ISR |
| 登录后台 / 内部工具 | 纯 SPA 可接受（对 SEO 无需求） |
决策原则：内容是否需要被搜索引擎推荐，决定了首屏 HTML 里必须有没有内容。这个决策应在选框架时就做，而不是上线后补救。
一句话总结
前端框架的渲染方式直接决定 SEO 的成败：纯 SPA 把内容藏在 JS 里，爬虫可能只看到空壳；SSR 把内容渲染进服务端 HTML，SSG 更进一步在构建期生成静态全文——对文档、博客这类内容构建期已知的站点，SSG 是最优解；而对任何需要被搜索的页面，"关键内容出现在爬虫直接拿到的 HTML 里"是必须守住的红线。