SPA网站做GEO：先让初始HTML有正文

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页面，第一次请求时可能只返回：

<div id='app'></div>
<script src='/assets/app.js'></script>

产品介绍、服务范围、案例、FAQ和文章正文，都要等JavaScript运行并从数据接口取回信息后，才会出现在页面中。

普通用户通常感觉不到这个过程，因为浏览器会自动执行脚本。对于不执行脚本、执行能力有限，或者不会等待页面完成渲染的机器人来说，它第一次读到的可能只有一个空的根节点和脚本地址。

检查时，不能只看浏览器开发者工具中的Elements（元素）面板。这个面板显示的是浏览器处理后的页面结构，不是服务器最初返回的HTML。

上线前至少要做三次检查：

1. 查看“网页源代码”，确认服务器第一次返回了哪些内容；
2. 使用命令行直接请求页面地址，并保存原始响应；
3. 关闭JavaScript，或者使用纯文本抓取方式再次查看页面。

例如，可以使用curl直接请求页面。curl是一种命令行网络请求工具：

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. 重要链接必须能够直接解析

重要页面之间应使用正常的<a href='...'>链接。

如果链接只绑定点击事件，却没有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基础
• Google动态渲染说明
• OpenAI爬虫说明
• Anthropic爬虫说明
• Next.js静态生成
• Next.js服务端渲染