AI 搜索需要预渲染吗？我们的 React 站点在 AI 上毫无可见性

你的猜测是对的。这是 SPA 常见问题。

核心问题：

AI 爬虫看到的内容：

它们请求页面时，收到的是：

<div id="root"></div>
<script src="bundle.js"></script>

就这些。没有内容。没有文本。没有可索引或可引用的东西。

数据统计：

• 25% 的 AI 爬虫能获取但不能执行 JavaScript
• AI 爬虫有 1-5 秒超时
• 你的 SPA 可能需要 2-3 秒才能渲染
• AI 在看到内容前就放弃了

解决方案：

预渲染你的内容，让 AI 爬虫能立刻获得完整的 HTML。

我们完成了这个迁移，给你分享下经历。

迁移前（CRA）：

• 完全客户端渲染
• AI 可见性为零
• 用户体验很快

迁移后（Next.js SSG）：

• 构建时预渲染页面
• AI 可见性全面提升
• 用户体验依然很快

迁移过程：

第1周：

• 搭建 Next.js 项目
• 配置构建流程
• 测试基本页面

第2周：

• 迁移组件
• 适配路由变动
• 设置静态导出

第3周：

• 测试与质控
• 性能优化
• 上线部署

迁移结果：

值得投入吗？

如果 AI 搜索对业务重要，绝对值得。

预渲染服务使用心得。

我们的情况：

• 大型 React SPA
• 目前无法做全面迁移
• 需要快速提升 AI 可见性

解决方案：Prerender.io

工作方式：

1. 安装中间件
2. 配置爬虫识别
3. 服务生成 HTML 快照
4. 爬虫收到预渲染版本
5. 用户浏览正常 SPA

实施时间：

实际只花了2小时就搞定。

实施效果：

• AI 爬虫现在能看到内容
• 数周内开始在 AI 答案中出现
• 用户体验无变化

局限性：

• 缓存刷新有延迟
• 需要额外服务费用
• 没有原生 SSG 那么干净

但作为短期方案：

预渲染服务为我们争取到了迁移的时间。

费用：

约 $100-500/月，视规模而定。

投资回报：

如果你正因 AI 搜索失去流量/曝光，ROI 很容易回正。

技术实现细节。

测试 AI 爬虫可访问性：

在变更前，先确认问题：

方法1：禁用 JavaScript

• 禁用 JS 访问你的网站
• 能看到内容吗？
• 如果不能，AI 也看不到

方法2：curl 测试

curl -A "Mozilla/5.0" https://yoursite.com

• 查看原始 HTML 响应
• 里面有内容还是只有空 div？

方法3：用 AI Eyes 扩展

• 展示 AI 爬虫可见与不可见内容
• 高亮依赖 JS 的内容

预渲染实现方式：

Next.js SSG:

export async function getStaticProps() {
  return { props: { data } }
}

Gatsby:

• 默认构建时渲染
• 所有页面均预渲染

Hugo/Jekyll/等：

• 天生静态
• 零 JS 依赖

验证方法：

实施后再测试：

• curl 应返回完整 HTML
• 禁用 JS 也应能看到内容
• 用 Am I Cited 监控可见性变化

更广义的 JavaScript SEO 背景。

发展历程：

2015年： “JavaScript 站点不利于 SEO” 2020年： “Googlebot 能渲染 JavaScript，没问题” 2025年： “AI 爬虫不能渲染 JavaScript”

我们又回到原点。

为什么重要：

很多公司转向 SPA，因为认为：

• Google 能渲染 JS
• 现代化就是更好
• 用户体验提升

但他们没预料到：

• AI 搜索变得重要
• AI 爬虫不执行 JS
• 可见性鸿沟出现

当前现实：

战略问题：

如果现在 AI 搜索占发现流量的 10-20%，而且还在增长，你能承受对它不可见吗？

对大多数企业来说：不能。

建议：

预渲染不是 AI 可见性的可选项。计划迁移吧。

内容可访问性不止渲染问题。

预渲染解决了大问题，但还要注意：

隐藏内容：

• 需要点击的标签页
• 折叠的手风琴内容
• 包含重要信息的弹窗
• 懒加载文本

即使 SSR/SSG，这些内容可能也不在初始 HTML 里。

解决办法：

重要内容应当：

• 出现在初始 HTML
• 无需交互即可见
• 在首屏或有明确链接

测试检查表：

• 关键内容在初始 HTML 响应中
• 重要文本不只在标签页/手风琴里
• 商品描述无需点击即可见
• 价格信息可直接访问
• FAQ 答案出现在页面源代码中

原则：

如果 AI 在 HTML 里看不到（无需 JS），那对 AI 搜索来说就不存在。

预渲染的性能视角。

常见担忧： “预渲染会不会影响性能？”

事实： 通常是提升性能。

原因：

客户端渲染：

1. 浏览器请求 HTML（几乎空的）
2. 浏览器下载 JS 包（很大）
3. 浏览器执行 JS（CPU 密集）
4. JS 拉取数据（网络往返）
5. JS 渲染内容（终于可见）

预渲染：

1. 浏览器请求 HTML（完整内容）
2. 内容立即可见
3. JS 负责交互

性能指标：

额外好处：

更好的 Core Web Vitals = 更佳的传统 SEO 与 AI 可访问性。

预渲染往往让两者都更好。

迁移规划框架。

决策树：

AI 可见性重要吗？
├── 否 → 保持 CSR
└── 是
    ├── 能否彻底迁移？
    │   ├── 能 → Next.js/Gatsby SSG
    │   └── 不能 → 预渲染服务
    └── 时间线？
        ├── 越快越好 → 先用预渲染服务，后续迁移
        └── 不急 → 规划全面迁移

迁移优先级：

阶段1（快速见效）：

• 添加预渲染服务
• 验证 AI 爬虫访问
• 监控可见性提升

阶段2（打基础）：

• 选定 SSG/SSR 框架
• 搭建平行环境
• 迁移关键页面

阶段3（全面完成）：

• 全部内容迁移
• 移除预渲染服务
• 优化构建流程

资源估算：

建议：

先用预渲染服务实现立竿见影，再规划长期迁移。

本帖让我思路清晰了。

我现在的理解：

1. AI 爬虫不执行 JS —— 我们的 SPA 完全不可见
2. 预渲染是必须的 —— 对 AI 可见性来说不是可选项
3. 有多种实现方式 —— 从临时方案到彻底迁移

我的计划：

立即（本周）：

• 禁用 JS 测试当前站点
• 验证 AI 爬虫看到的内容
• 启用 Am I Cited 监控

短期（下月）：

• 实现预渲染服务（Prerender.io）
• 为迁移争取时间，快速见效
• 验证 AI 可见性提升

中期（下季度）：

• 迁移到 Next.js SSG
• 构建时彻底预渲染
• 最终长期方案

我的体会：

我们“现代化”的 React SPA 架构，实际上让我们与搜索（AI）未来脱节。是时候转变了。

感谢大家提供的实用建议！