# SPA网站做GEO：先让初始HTML有正文
> GEO，即生成式引擎优化，关注的是网站内容能否被生成式人工智能（AI）相关系统发现、读取和理解。这里的爬虫，是平台用来自动访问网页、读取信息的程序。要判断一个网站是否便于AI爬虫读取，不能只看页面在浏览器里显示得是否完整。
来源：https://www.starbox.work/insights/geo-guide/geo127/（星盒AI 知识中心，更新于 2026-10-10）
GEO，即生成式引擎优化，关注的是网站内容能否被生成式人工智能（AI）相关系统发现、读取和理解。这里的爬虫，是平台用来自动访问网页、读取信息的程序。要判断一个网站是否便于AI爬虫读取，不能只看页面在浏览器里显示得是否完整。
如果网站采用SPA，即单页应用，就更需要检查服务器第一次返回的内容。SPA通常先返回基础页面，再由浏览器执行JavaScript，也就是用于加载内容和实现交互的脚本语言，把产品介绍、服务范围、案例、常见问题（FAQ）和文章正文填入页面。
这会造成一种常见误判：用户打开页面时，标题、图片和正文一项不少，开发人员便认为爬虫也能看到同样的内容。实际上，用户看到的是JavaScript运行后的页面；爬虫第一次请求时拿到的，可能只有一个根节点和几行脚本地址。
真正需要检查的是初始HTML。HTML，即超文本标记语言，是构成网页内容和结构的基础代码。初始HTML，就是服务器收到访问请求后，第一次直接返回的网页代码。
判断SPA网站是否满足GEO的基本读取要求，不必先争论用了React、Vue还是其他前端开发工具。先回答一个更具体的问题：
> 服务器返回的初始HTML里，是否已经包含网页标题、页面一级标题、正文、主要链接和结构化数据？
JavaScript可以继续负责筛选、弹窗、表单和局部刷新，但不应负责生成页面上的全部事实内容。
## 不要假设所有爬虫都以同样方式运行JavaScript
“AI爬虫都不执行JavaScript”并不是已经得到所有平台确认的规则。
这里还涉及SEO，即搜索引擎优化。Google在相关官方文档中明确说明，Googlebot，也就是Google的网页抓取程序，会把需要处理的页面加入渲染队列，再使用无头Chromium执行JavaScript。无头Chromium是没有可视操作界面的浏览器程序，可以在后台加载和处理网页。
但Google同时提醒，并不是所有机器人都能运行JavaScript，因此服务端渲染或预渲染仍是合适的处理方式。
OpenAI和Anthropic公开的爬虫文档，主要说明机器人的用途、`robots.txt`控制方式和来源IP信息。`robots.txt`是网站用来告诉爬虫哪些内容允许或禁止访问的文件，IP则是访问来源的网络地址。两家平台都没有在这些文档中承诺：爬虫会像完整浏览器一样执行页面脚本，并等待所有内容加载完成。
因此，工程上没有必要把验收结果建立在猜测上。更稳妥、也更容易检查的标准是：
> 关键公开页面的初始HTML应当直接包含Title（网页标题）、H1（页面一级标题）、正文、主要链接和结构化数据。机器人即使不执行JavaScript，也能读到页面的主要信息。
## 第一步不是更换框架，而是查看原始响应
一个典型的SPA页面，第一次请求时可能只返回：
```html
```
产品介绍、服务范围、案例、FAQ和文章正文，都要等JavaScript运行并从数据接口取回信息后，才会出现在页面中。
普通用户通常感觉不到这个过程，因为浏览器会自动执行脚本。对于不执行脚本、执行能力有限，或者不会等待页面完成渲染的机器人来说，它第一次读到的可能只有一个空的根节点和脚本地址。
检查时，不能只看浏览器开发者工具中的Elements（元素）面板。这个面板显示的是浏览器处理后的页面结构，不是服务器最初返回的HTML。
上线前至少要做三次检查：
1. 查看“网页源代码”，确认服务器第一次返回了哪些内容；
2. 使用命令行直接请求页面地址，并保存原始响应；
3. 关闭JavaScript，或者使用纯文本抓取方式再次查看页面。
例如，可以使用`curl`直接请求页面。`curl`是一种命令行网络请求工具：
```bash
curl -L https://example.com/product/alpha -o page.html
```
这条命令会请求示例页面，并把返回内容保存为`page.html`。随后应在文件中查找产品名称、H1、核心参数和正文首段。
如果这些内容不在文件里，即使浏览器最终显示正常，该页面也没有达到“初始HTML可读”的验收标准。
| 原始HTML检查结果 | 判断 | 处理建议 |
|---|---|---|
| 包含Title、H1、正文、主要链接和关键事实 | 通过 | 保留现有方案，继续检查状态码和内容一致性 |
| 只有摘要，主要正文依赖JavaScript | 有风险 | 优先把关键页面改为静态生成、服务端渲染或预渲染 |
| 只有根节点和脚本地址 | 不通过 | 先调整渲染方式，不要只修改页面文案 |
## SPA不必全部重做，可以按页面选择方案
发现初始HTML没有正文后，不一定要推翻整个SPA。可以根据内容更新频率、公开页面地址（URL）的数量和现有技术条件，在SSG、SSR和按路由预渲染之间选择。
URL就是网页地址。产品页、文章页和案例页都应拥有能够单独访问的URL。
### SSG：在构建网站时生成完整HTML
SSG是Static Site Generation的缩写，中文通常称为静态站点生成或静态生成。
它会在网站构建时，为公开URL提前生成完整HTML。用户或爬虫访问时，服务器可以直接返回已经生成的页面，不必等待浏览器执行脚本后再补充正文。
Next.js官方文档说明，静态生成会在构建时生成HTML，之后可以通过CDN重复使用这些页面文件。CDN，即内容分发网络，可以从不同位置向访问者提供已经生成的文件。
SSG通常适合以下内容：
- 产品介绍、服务说明、品牌介绍和案例页；
- 知识文章、帮助中心等公开内容；
- 内容来自CMS，但发布后不会频繁变化；
- 页面URL能够在构建时确定；
- 需要让大量公开页面稳定返回完整HTML。
CMS，即内容管理系统，是用来编辑、发布和管理网站内容的后台工具。
SSG的限制也很明确：内容发生变化后，通常需要重新构建页面；动态URL则需要提前生成，或者配置增量更新机制。
需要登录才能访问的后台页面，不应为了静态化而变成公开页面。
### SSR：每次收到请求时生成HTML
SSR是Server-Side Rendering的缩写，中文称为服务端渲染。
用户或爬虫每次请求页面时，服务器都会读取当前数据，并生成对应的完整HTML。Next.js官方文档将其定义为每次请求时生成页面HTML。
SSR通常适合：
- 价格、库存、时效等变化较快的公开信息；
- 页面需要根据当前数据生成，但不涉及用户私有信息；
- 每个URL都需要直接返回当下的完整内容；
- 团队已经具备稳定的服务端运行环境。
SSR需要处理服务器计算、缓存、接口超时和故障恢复等问题。它不是把部分前端代码移到服务器就结束了。
如果数据接口超时、返回空数据或发生错误，服务器仍然可能输出一个正文为空、状态码却显示正常的页面。因此，改为SSR后，还要同时处理缓存更新、空数据、错误页面和状态码。
### 按路由预渲染：先处理重点页面
如果短期内无法重构整个SPA，可以先为重点公开URL生成完整HTML快照。这里的路由，可以简单理解为网站中不同页面地址与页面内容之间的对应关系。
可以优先处理：
- 首页；
- 核心产品页；
- 核心服务页；
- 品牌介绍页；
- 重点案例页；
- 已经有访问量或业务价值较高的文章。
这种方式适合作为过渡方案：先让重点页面的初始HTML可读，再逐步迁移到原生SSR或SSG。
需要注意的是，如果只在识别到机器人时返回静态页面，而用户访问时看到另一种页面，这类动态渲染被Google视为变通方案，不建议长期依赖。
无论采用哪种方式，机器人和用户看到的核心事实都必须一致，不能长期维护两套内容不同的页面。
| 方案 | HTML生成时间 | 适合页面 | 主要代价 |
|---|---|---|---|
| SSG静态生成 | 构建网站时 | 产品、服务、文章、案例等稳定内容 | 更新时需要重新生成或增量更新 |
| SSR服务端渲染 | 每次收到请求时 | 公开且变化较快的内容 | 服务器计算、缓存和故障处理 |
| 按路由预渲染 | 发布或定时任务执行时 | 暂时无法整体改造的重点URL | 快照更新和内容一致性维护 |
## 初始HTML有正文，不等于放弃SPA交互
调整渲染方式后，页面仍然可以保留筛选、计算器、轮播、表单、登录状态和局部刷新等功能。
常见做法是，先由服务器或构建流程输出完整HTML，再由JavaScript接管页面交互。这个接管过程通常称为“水合”。
改造时，可以把页面内容分成两类：
- **事实内容**：品牌介绍、产品名称、服务范围、参数、案例、FAQ、作者和发布日期。这些内容应当出现在初始HTML中；
- **交互功能**：筛选、排序、弹窗、登录后数据和个性化结果。这些功能可以继续由JavaScript处理。
必须登录才能查看的页面，本来就不属于公开抓取范围。不能为了让爬虫读取，把用户私有数据或后台内容写进公开HTML。
## 正文可以读取后，还要检查六项基础设置
初始HTML包含正文，只解决了最直接的问题。URL、状态码、页面头部信息、结构化数据、链接和接口容错，也会影响页面能否被发现和正确读取。
### 1. 每个页面都要有独立URL
产品、服务、文章和案例应当拥有独立、稳定、可以直接访问的URL，不要只依赖`#/product/1`一类地址片段切换内容。
Google建议SPA使用History API，也就是浏览器的历史记录接口，并通过带有`href`属性的真实链接连接各个页面。这样，每个URL才能被发现、复制和单独请求。
### 2. 状态码要反映真实结果
状态码是服务器对访问结果的简短说明。正常页面应返回200，表示请求成功；不存在的页面应返回404，表示没有找到；页面跳转则应返回合适的3xx重定向状态码。
SPA的常见问题是，所有路径都返回200和同一个空页面。这样一来，不存在的地址也会被当成正常页面处理。
### 3. 页面头部信息要随URL变化
每个公开URL都应在初始HTML中正确输出以下信息：
- Title，即网页标题；
- Meta description，即页面内容摘要；
- canonical，即用于声明当前页面规范网址的信息；
- 必要的robots指令，即对爬虫访问或收录方式的控制要求。
不要等页面加载完成后，再由前端脚本统一替换这些信息。
### 4. 结构化数据必须与正文一致
结构化数据是按照固定格式说明页面内容的信息。JSON-LD是其中一种常用格式，可以直接放在初始HTML中。
JSON-LD中的品牌、产品、作者、日期、价格和FAQ，必须与页面可见正文一致。结构化数据不能代替正文，也不能证明页面一定会被AI引用。
### 5. 重要链接必须能够直接解析
重要页面之间应使用正常的``链接。
如果链接只绑定点击事件，却没有`href`；或者必须完成鼠标交互后才会出现，机器人发现这些页面的难度就会增加。
### 6. 页面不能依赖接口每次都请求成功
API，即应用程序接口，是不同程序之间请求和传递数据的入口。
进行服务端渲染时，如果API请求失败，页面不应返回空正文和200状态码。网站需要设置缓存、降级内容和明确的错误状态，避免机器人在故障期间抓到一个看似正常、实际没有内容的页面。
## 一套可以直接执行的改造顺序
### 第一步：整理全部公开URL
导出网站所有公开URL，按首页、产品、服务、文章、案例和其他页面分类。
### 第二步：逐类检查原始HTML
记录每类页面的Title、H1、正文首段、核心事实、主要链接和结构化数据是否存在。
不要用一个页面的检查结果代表整个网站。同一套SPA中，不同路由可能采用不同的数据加载方式。
### 第三步：确定改造优先级
不必一次重写整个前端。可以先处理首页、核心产品页、核心服务页、品牌介绍页、重点案例页和已有访问量的文章。
### 第四步：为每类页面选择渲染方式
- 内容发布后较稳定：优先使用SSG；
- 公开内容变化较快：考虑SSR；
- 暂时无法重构：先对重点路由进行预渲染。
### 第五步：把关键信息写入初始HTML
至少应包括Title、H1、正文、canonical、JSON-LD和核心链接，同时保留原有前端交互。
### 第六步：对比三份页面结果
在测试环境中同时检查：
1. 服务器返回的原始HTML；
2. 浏览器执行脚本后的页面结构；
3. 用户最终看到的页面。
三者的核心事实应当一致。
### 第七步：上线后检查服务器日志
确认相关机器人是否实际访问网站，并检查返回状态码、响应内容大小和被访问页面是否正常。
User-Agent是请求信息中用于标识客户端的字段，但它只能作为判断线索，不能单独证明请求来自某个平台。还需要结合平台官方公布的IP验证方式进行确认。
### 第八步：保存记录并观察结果
保存改造前后的原始页面样本、发布日期和版本，再观察页面是否被纳入可检索范围、是否获得引用，以及是否出现来自相关平台的访问。
改成SSR或SSG，只解决“内容能否被读取”的问题，不保证页面一定会被抓取、纳入索引或引用。
## 上线验收清单
1. 每个重要页面都有独立、稳定的URL；
2. 直接请求URL时，服务器返回200和完整正文；
3. 原始HTML包含Title、H1、正文首段和核心事实；
4. 页面内的重要链接使用真实`href`；
5. 不存在的页面返回真实404；
6. canonical指向正确URL；
7. JSON-LD与可见正文一致；
8. 关闭JavaScript后仍能读到主要内容；
9. 浏览器中的交互功能仍然可用；
10. 原始HTML与执行脚本后的页面不存在事实冲突；
11. `robots.txt`没有误拦截关键页面和必要资源；
12. 上线后可以在服务器日志中看到正常访问和响应。
## 改造解决的是“可读取”，不是“保证被引用”
SPA网站是否便于AI爬虫读取，关键不在于用了哪种前端框架，而在于服务器第一次响应时有没有返回真实正文。
与其反复猜测某个机器人能否执行JavaScript，不如采用可以直接检查的标准：公开页面的初始HTML包含完整事实内容，JavaScript负责后续交互。
内容稳定时优先考虑SSG；公开信息变化较快时考虑SSR；短期内无法整体重构时，先预渲染重点路由。
改造完成后，还要逐项检查原始HTML、状态码、URL、链接、结构化数据和服务器日志。只有这些检查结果都符合预期，才能确认网站已经解决内容可读取的问题。至于页面会不会被抓取、收录或引用，还需要结合访问控制、内容质量、事实依据、来源关系和平台自身机制继续观察。
## FAQ
### 1. AI爬虫都不执行JavaScript吗？
不能一概而论。
Googlebot明确会执行JavaScript；OpenAI和Anthropic公开的爬虫文档，则没有承诺提供与完整浏览器相同的脚本渲染能力。
工程验收应以关键正文能否从初始HTML中直接读取为标准，而不是等待机器人替网站完成脚本运行。
### 2. SPA网站一定要全部重做吗？
不一定。
可以先处理首页、产品页、服务页、案例页和重点文章，为这些公开路由增加SSG、SSR或预渲染，再逐步扩大改造范围。
### 3. SSG和SSR怎么选？
内容发布后较稳定，优先考虑SSG；公开内容需要随请求更新，再考虑SSR。
两者都能让初始响应包含完整HTML，主要区别在于HTML的生成时间、缓存方式和运行成本。
### 4. 可以只给机器人返回静态页面吗？
Google把动态渲染视为变通方案，不建议长期依赖。
机器人版和用户版的核心内容必须一致。长期方案应考虑SSR、SSG，或者预渲染后再由JavaScript接管交互。
### 5. 改成SSR后就会被AI引用吗？
不能保证。
SSR只解决内容能否从初始响应中读取。页面是否会被抓取、纳入索引或引用，还取决于访问控制、内容质量、事实依据、来源关系和平台自身机制。
### 6. 怎么证明改造已经生效？
保存同一URL的原始响应，确认其中包含Title、H1、正文和链接；再检查状态码、关闭JavaScript后的页面、结构化数据和服务器日志。
不能只看浏览器最终显示的页面。
## 官方资料
- [Google JavaScript SEO基础](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
- [Google动态渲染说明](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering)
- [OpenAI爬虫说明](https://developers.openai.com/api/docs/bots)
- [Anthropic爬虫说明](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler)
- [Next.js静态生成](https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation)
- [Next.js服务端渲染](https://nextjs.org/docs/pages/building-your-application/rendering/server-side-rendering)