JavaScript 正在影响我们的 AI 可见性吗？AI 爬虫似乎抓取不到我们的动态内容

你的怀疑是正确的。大多数 AI 爬虫不会执行 JavaScript。

不同爬虫如何处理 JS：

为什么重要： 如果你的内容是通过客户端 JS 渲染，AI 爬虫看到的是：

<div id="app"></div>

而不是你的实际内容。

解决方案优先级：

1. 服务端渲染（SSR）——内容在初始 HTML 响应中
2. 静态站点生成（SSG）——预生成 HTML 页面
3. 预渲染服务——为机器人渲染 JS
4. 混合渲染——关键内容用 SSR，互动部分用客户端

你的 React 应用可以实现这些中的任何一种。Next.js 实现 SSR/SSG 非常简单。

我们做过这种迁移。实际经验如下：

迁移前（React SPA）：

• 客户端渲染
• 内容通过 API 调用
• AI 可见性：零

迁移后（Next.js SSR）：

• 所有内容页面用服务端渲染
• 文档用静态生成
• AI 可见性：每周提升

实现建议：

1. 用 App Router 和服务端组件 默认就是 SSR——内容直接输出

2. 服务端获取数据

   // 在服务器运行，内容在 HTML 内
   async function Page() {
     const data = await fetch('...');
     return <Article data={data} />;
   }
   

3. 避免内容组件加 ‘use client’ 只有交互部分才用客户端组件

4. Metadata API 做 SEO/AI 优化

   export const metadata = {
     title: '...',
     description: '...',
   };
   

迁移工作量： 中等规模站点大约 3 周。非常值得。

结果： 上线 SSR 站点 6 周内出现了首批 AI 引用。

如果无法迁移，预渲染是一个选择：

预渲染的作用：

• 服务为机器人请求渲染 JS
• 向爬虫返回完整 HTML
• 真实用户仍然访问你的 SPA

常用服务：

• Prerender.io
• Rendertron
• 基于 Puppeteer 的方案

实现方式： 中间件检测机器人 User-Agent 并转发到预渲染服务。

优点：

• 无需更改代码库
• 兼容任意框架
• 实施速度快

缺点：

• 有额外费用
• 机器人请求有延迟
• 缓存复杂
• 依赖第三方

适用场景：

• 大型遗留代码库
• 短期内无法迁移
• 需要快速提升 AI 可见性

不适合场景：

• 新项目（直接用 SSR）
• 小型站点（迁移更简单）
• 预算有限（预渲染有成本）

预渲染是过渡方案，不是理想的长期策略。

适合 AI 友好网站的框架选项：

场景推荐：

• 新项目： Next.js、Nuxt 或 SvelteKit
• React 迁移： Next.js
• Vue 迁移： Nuxt
• 内容为主： Gatsby 或 Astro
• 博客/文档： Hugo、Eleventy 或 Astro

要想 AI 可见，SSR/SSG 都可以。纯客户端渲染则不可见。

复杂应用的混合渲染方案：

挑战： 应用某些部分需要客户端渲染（如仪表盘、交互工具），但内容要 SSR。

解决方案：混合渲染

1. 内容页面： 完全 SSR

   • 博客、文档
   • 营销页面
   • FAQ 与知识库

2. 交互功能： 客户端渲染

   • 仪表盘
   • 表单与工具
   • 用户个性化内容

Next.js App Router 非常方便：

• 内容用服务端组件
• 交互用客户端组件
• 可在同一页面自由混用

结构示例：

// 页面为服务端渲染
export default function Page() {
  return (
    <>
      <ServerRenderedContent /> {/* AI 能看到 */}
      <ClientInteractiveWidget /> {/* AI 不需要看到 */}
    </>
  );
}

原则： 希望 AI 看到的内容：服务器渲染。 其他内容：客户端渲染即可。

测试你的内容是否 AI 可见：

方法一：查看源码

• 右键 → 查看页面源代码
• 如果能看到内容 = AI 能看到
• 如果只有 <div id="root"></div> = AI 看不到

方法二：禁用 JavaScript

• 浏览器开发者工具 → 设置 → 禁用 JavaScript
• 刷新页面
• 如果内容消失 = AI 看不到

方法三：curl 测试

curl -A "GPTBot" https://yoursite.com/page | grep "your content"

如果返回内容，说明没问题。

方法四：Google 富媒体测试

• 检查渲染内容
• 查看 Googlebot 能看到什么
• 与 AI 机器人看到的类似

实施 SSR 后： 再次运行这些测试。所有方法内容都应可见。

专业建议： 设置监控以避免回归。SSR 失效时可能没有明显症状。

SSR 的性能考量：

SSR 会增加服务器负载：

• 每个请求都要服务器渲染
• 比静态文件消耗更多计算资源
• 缓存非常关键

缓解策略：

1. 尽可能静态生成

   • 博客和文档 = 静态
   • 动态内容 = SSR

2. 增量静态再生（ISR）

   • 定期重建静态页面
   • 两全其美

3. 边缘渲染

   • 在 CDN 边缘渲染
   • 全球更快的 TTFB

4. 多层缓存

   • 页面级缓存
   • 组件级缓存

权衡： SSR 计算成本更高，但 AI 可见性提升。对大多数企业来说，可见性远胜于基础设施成本。

监控： SSR 实施后注意 TTFB。如果过慢，爬虫可能在获取内容前就超时。

问题已经明确，解决方案也很清晰。我们的行动计划：

立即（本周）：

1. 用 curl 测试审计当前渲染方式
2. 确定对 AI 可见性最重要的内容页面
3. 检查 robots.txt 是否允许 AI 机器人访问

短期（下季度）：

1. 启动内容页的 Next.js 迁移
2. 博客、文档、营销页实现 SSR/SSG
3. 仪表盘/应用仍用客户端渲染

实现步骤：

1. 从价值最高的内容页开始
2. 每批上线后测试 AI 可见性
3. 高频更新内容用 ISR
4. 全程监控 TTFB

技术决策：

• Next.js App Router + 服务端组件
• 文档静态生成
• 博客与营销用 SSR
• 只在必要处使用客户端组件

测试计划：

1. 每次发布后 curl 测试
2. 查看源码确认
3. 持续监控 AI 引用
4. 跟踪被引用页面

核心观点： 客户端渲染 = AI 不可见。SSR/SSG = 可见。为了 AI 可见性，迁移是必选项。

感谢大家——现在路径很明确！