起因：Google Search Console 里的一片空白
产品上线三个月，打开 Google Search Console，曝光量几乎是零。
当时的第一反应是：没做推广当然没流量。但仔细一想不对——我们做的是英文工具站，目标用户在海外，Google 是他们找工具的第一入口。如果搜索流量为零，要么是关键词没选对，要么是 Google 根本就没有索引我们的页面。
把 URL 手动提交给 Google 抓取，看到了一行让人沉默的提示：
页面已抓取，但内容为空。
Google 爬到了我们的页面，但渲染出来什么都没有。原因很简单，也很致命：我们的产品是一个标准的 Vite SPA。
为什么 Vite SPA 对 SEO 是灾难
SPA 的工作方式是这样的：服务器只吐出一个空的 HTML 文件，所有内容靠 JavaScript 在浏览器里动态渲染。用户打开页面时，浏览器下载 JS、执行 JS、然后才看到内容——整个过程对用户来说快得感知不到。
但搜索引擎的爬虫不一样。Google 的爬虫会抓取 HTML，而 SPA 返回的 HTML 里只有一个 <div id="root"></div>，正文一个字都没有。虽然 Googlebot 声称支持 JavaScript 渲染，但实际上：
- 渲染队列有延迟：Googlebot 的 JS 渲染是异步的，可能落后于 HTML 爬取几天甚至几周
- 渲染资源有上限：复杂的 SPA 渲染成本高，Google 会限制预算
- 动态内容基本没戏：需要登录或交互才能触发的内容，爬虫永远看不到
对于一个主要靠 Google 搜索获客的出海工具产品，这三点加起来等于：你花了大半年做的内容，在搜索引擎眼里几乎不存在。
为什么一开始选了 Vite
其实从一开始选 Vite 的时候就模糊地知道 SEO 是个隐患，但当时的理由也很充分：
- 团队熟悉 React，Vite 上手快，能快速验证产品方向
- 早期产品能不能活下来都不知道，SEO 是后面的事
- 「Googlebot 支持 JS 渲染」——这句话让人产生了一种错误的安全感
结果就是一直把 SEO 当成「之后再说的问题」，直到三个月后看到 Search Console 的数据，才意识到一直在还债。
面对的选择
意识到问题之后，坐下来评估了几条路。
修补现有 SPA
工具是预渲染插件，构建时用无头浏览器把每个路由快照成静态 HTML。改动最小，但本质是打补丁——内容更新需要重新构建，动态数据渲染不了，根本问题没解决。
在 Vite 上自己搭 SSR
Vite 支持 SSR，React 有 renderToString。但自己搭需要处理 hydration、数据获取策略重写、路由改造，以及一个常驻的 Node.js 服务。翻了两天文档之后放弃了——等于重造了半个 Next.js，还没 Next.js 成熟。
迁移到 Next.js
最彻底，也改动最大。Next.js 的核心优势是渲染策略可以按页面粒度决定：SEO 关键页面做 SSG，动态内容做 SSR，纯交互的内部页面继续 CSR。
这三条路放在一起，选项二基本排除。剩下的问题是：选项一（打补丁）还是选项三（迁 Next.js）？
答案取决于项目规模。
小型应用：直接迁到 Next.js
如果项目代码量不大，路由有限，组件结构清晰，迁 Next.js 的成本是可控的。
从 React + Vite 到 React + Next.js，组件代码几乎不需要改，主要改的是两处：
数据获取方式：原来习惯在 useEffect 里 fetch，迁过去之后改成 Server Component 里直接 async/await，或者 getStaticProps/getServerSideProps（Pages Router）。让数据在服务端就填进 HTML，爬虫直接读，不用等 JS 执行。
路由结构：Vite 一般配合 React Router，Next.js 是文件目录即路由。这块改动有一点机械工作量，但逻辑上不复杂。
迁完之后，SEO 关键页面（首页、功能介绍、价格页）全部变成静态 HTML，Google 抓取没有任何障碍。附带的好处是：next/image 自动处理图片格式和懒加载，Core Web Vitals 跟着一起改善；API Routes 让简单的后端逻辑可以直接写在项目里，不用单独维护一个服务。
大型应用：创建独立官网，曲线救国
如果项目已经跑了一两年，SPA 里沉淀了大量业务逻辑和组件，全量迁 Next.js 的成本是真实的风险——不只是工作量，更大的风险是迁移过程中引入 regression，影响在用用户。
这种情况有一条代价更低的路：不动主应用，单独建一个对外的官网落地页。
逻辑是这样的：真正需要被 Google 索引的页面，其实就那几种——首页、功能介绍页、定价页、博客文章。这些页面的共同特点是：内容静态、不需要登录、面向新用户。
而用户登录之后用到的那些核心功能页面——Dashboard、编辑器、设置页——Google 根本不需要索引它们，也索引不了（登录墙拦着）。
所以实际需要 SSR/SSG 的页面数量，远比整个 SPA 少得多。
具体做法：
用 Next.js（或者 Astro，Astro 对纯内容页面更轻量）单独起一个仓库，专门做官网落地页。域名上用子路径区分：
yourdomain.com→ 官网落地页（Next.js/Astro，完整 SEO）yourdomain.com/app或app.yourdomain.com→ 主应用（Vite SPA，保持不变）
这样 Google 抓到的是官网，索引的是干净的静态 HTML。用户从搜索结果点进来，看到的是专业的落地页，转化完再跳进 SPA 应用——两者体验是连贯的。
官网落地页的维护成本远低于全量迁移，而且独立出来之后，官网可以做更激进的内容 SEO：博客文章、用户案例、关键词落地页，这些在 SPA 里做很别扭，在独立官网里反而更顺手。
决策路径总结
出海应用 SEO 很差
│
▼
项目规模大吗？
/ \
是 否
│ │
▼ ▼
单独建官网落地页 直接迁 Next.js
（曲线救国） （一步到位）两条路的核心逻辑是一样的：让 Google 能抓到的页面，在服务端就有完整的 HTML。区别只在于用多大的代价达到这个目标。
最后
Vite SPA 是快速验证产品想法的好选择，但一旦产品进入增长阶段，SEO 是绕不过去的坎。
不是说所有项目都要上 Next.js，但至少应该在早期就把这个问题想清楚：你的用户怎么找到你？
如果主要靠内容驱动的 SEO 获客，从一开始就选一个对 SEO 友好的技术栈，省去后来的迁移成本。如果主要靠付费推广或者邀请码增长，SPA 完全没有问题。
技术选型最终还是要回答业务问题。SEO 的坑，踩一次就够了。