Vibe Coding的渲染盲区：AI搜索看不见你的应用

Vibe coding 在 2026 年已经成为 Web 开发的主流方式。输入一段提示词，30 秒得到一个可运行的应用，直接部署上线。Lovable、Bolt、v0 这类工具让不写一行代码就能完成原型和发布成为现实。

这些应用在浏览器里看起来不错，功能也正常。但它们对 AI 搜索引擎来说是隐形的。

问题的根源：默认客户端渲染

Vibe coding 工具链中的每一个环节，默认产出的都是客户端渲染的 SPA。服务器返回一个 HTML 外壳，里面只有一个 <div id="root"></div> 和一个 <script> 标签。浏览器下载脚本、执行脚本、渲染内容。在浏览器里，这没问题。对机器人来说，这不行。

GPTBot、ClaudeBot、PerplexityBot 和 Googlebot 并不会像浏览器那样执行 JavaScript。它们抓取 HTML、解析、然后结束。如果内容不在 HTML 里，对检索管线来说它就不存在。

这不是新问题。自从 React 让客户端渲染流行起来，SPA 就一直被这个渲染问题困扰。新的是规模：2026 年，数以万计的站点由 vibe coding 工具生成，每一个都带着相同的默认配置——空的 HTML 外壳、JavaScript 渲染的内容、对爬虫隐形。

SPA（单页应用） 是一种 Web 应用架构：首次加载时服务器只返回一个极简 HTML 外壳，后续所有页面切换和内容渲染都由浏览器中的 JavaScript 完成。它让交互体验接近原生应用，但对不执行 JS 的爬虫来说，得到的始终是同一个空壳。

CSR / SSR / SSG 是三种渲染时机。CSR（客户端渲染）在浏览器里跑 JS 生成内容；SSR（服务端渲染）在每次请求时由服务器生成完整 HTML；SSG（静态生成）在构建阶段就把 HTML 文件生成好。三者对用户观感可能几乎一致，但只有后两者能让爬虫在首次请求时直接读到内容。

GPTBot、ClaudeBot、PerplexityBot 分别是 OpenAI、Anthropic、Perplexity 的抓取机器人，用于为 AI 搜索和问答提供网页内容。它们与 Googlebot 的早期行为类似：请求 HTML、解析文本，不运行页面脚本。因此内容是否出现在初始 HTML 中，直接决定它能否进入 AI 的检索管线。

如何自查：两行命令

不必等到分析后台显示自然流量为零才意识到问题。用 curl 就能快速判断：

curl -s https://your-vibe-coded-site.com | wc -c

如果响应只有几百字节，你拿到的是外壳。如果达到几千字节甚至更多，内容就在 HTML 里。

进一步验证可以检查页面源代码（而非渲染后的 DOM）：

curl -s https://your-vibe-coded-site.com | grep -i "你的主要内容文本"

如果 grep 没有任何返回，说明你的内容是 JavaScript 渲染的，没有 AI 搜索引擎能读到它。

llms.txt 救不了这个问题

过去几个月，GEO 圈子的讨论几乎被 llms.txt 占据。Google 建议忽略它，Chrome Lighthouse^广告 对它做审计，四项独立研究显示它对 AI 引用没有效果。

但即使 llms.txt 完美工作，也解决不了渲染问题。llms.txt 文件链接到你的页面，当 AI 机器人沿着这些链接抓取 HTML 时，如果 HTML 是空的，机器人读了文件、访问了页面，却什么也找不到。这个文件只是一张通往空房间的地图。

Ahrefs 的研究证实了这一模式：AI 机器人抓取的是 HTML 页面，不是辅助文件。Limy 的研究追踪了 5.15 亿次机器人事件，发现机器人绝大多数直接请求 HTML。决定引用什么的检索步骤读的是你的 HTML。如果 HTML 里没有内容，你就是隐形的。

llms.txt 是一种提议中的纯文本文件，放在网站根目录，用 Markdown 格式列出站点的重要页面和简介，供大语言模型快速了解站点结构。它的定位类似 robots.txt 或 sitemap，但面向的是 AI 理解和引用，而非抓取权限。争议在于：主流 AI 公司并未承诺读取它，Google 明确表示不建议依赖，多项独立测试也未观察到它对引用率有可测量影响。

GEO（生成引擎优化） 指针对 AI 搜索和生成式回答的优化实践，目标是让内容更容易被大模型检索、引用和总结。它与传统 SEO 共享底层前提——内容必须可被抓取和解析——但在内容结构、可引用段落、实体清晰度等层面有额外要求。渲染问题属于 GEO 的前置条件，而非 GEO 策略本身。

三种修复路径

修复方法并不专门针对 AI，它和 SPA 流行以来的老方案是同一套：

方案一：静态生成。 在构建时生成完整 HTML。Astro、配置了 output: export 的 Next.js、Gatsby 等默认就是这样。每个页面都是完整的 HTML 文件，机器人第一次请求就能拿到全部内容。

方案二：服务端渲染。 每次请求时在服务端渲染 HTML。Next.js App Router、Nuxt、SvelteKit 都支持。服务器发送完整 HTML，机器人可以读取。

方案三：预渲染。 生成页面的静态快照并提供给机器人。这是一种变通方案，会增加复杂度，且如果预渲染内容与用户看到的不同，可能被判定为 cloaking。除非别无选择，否则应避免。

预渲染与 cloaking 的边界：预渲染（prerendering）是在构建或请求时生成静态 HTML 快照，专门提供给爬虫，而真实用户仍使用 SPA。搜索引擎将“向爬虫和用户展示不同内容”定义为 cloaking（伪装），属于违反站长指南的行为，可能导致降权。风险点在于快照与用户实际看到的内容不一致——例如快照包含完整商品信息，而用户端因登录或交互才显示。若预渲染内容与用户首屏内容完全一致，通常不被视为 cloaking，但判断权在搜索引擎，因此文中建议优先选择 SSG 或 SSR。

Next.js 的 output: export：这是 Next.js 的静态导出模式，构建时把每个路由预生成对应的 HTML 文件，可部署到任意静态托管。它与 App Router 的 SSR 模式相对：前者在构建时生成 HTML，后者在请求时生成。两者都能让爬虫拿到完整内容，选择取决于页面是否需要动态数据。

工具默认值才是关键

生成 SPA 的工具应该默认采用静态生成或 SSR。目前它们默认 CSR，因为那是通往可运行原型的最短路径：用户输入提示词，工具生成 React 应用，应用在浏览器里跑起来。至于它对爬虫隐形这件事，用户在看分析数据、疑惑为什么自然流量为零之前，根本不会察觉。

部分工具已经开始应对。Lovable 增加了 SSR 选项，Bolt 支持部署到处理预渲染的平台。但默认值仍然偏向 CSR，而大多数用户不会去改默认值。

渲染是 AI 可见性的地基

渲染问题是 AI 搜索可见性的最底层。如果你的内容不在 HTML 里，其他一切都不重要——llms.txt、Schema、内容结构、值得被引用的段落，全都无从谈起。机器人必须先能读到你的页面，更高层的信号才有意义。

在维护的审计工具 geo-optimizer-skill 中，渲染检查是第一项测试信号：分别用和不带无头浏览器抓取页面并对比结果。如果内容差异显著，就标记为 JS 依赖。这是最常见的失败模式，也是修复路径最清晰的一个。

如果你在用 vibe coding，先检查 HTML 输出。如果是空的，切换到 SSG 或 SSR。用户看到的界面不变，但每一个重要的搜索引擎和 AI 爬虫都能看见你。这不是一套 GEO 策略，只是一个配置改动。