JavaScript 渲染，正在吃掉你喂给大模型的内容
有个场景很常见：一个定价页排在 Google 第一页，稳定吃自然流量，技术检查全过。但它从没在 AI 关于这个品类的回答里出现过。
一个可能的原因：答案不在 HTML 里。
很多 AI 爬虫抓页面时不执行 JavaScript。它们拿到的是服务器返回的原始 HTML，而只有 JS 跑完才出现的内容，可能永远进不到它们能读的范围里。
这事容易被忽略，因为 Google 能渲染 JS，你的用户当然也能。所以页面在浏览器里看着正常，在搜索里排着名，分析后台流量也正常。
问题通常不是整页消失，而是某些部分消失了。定价、产品参数、对比表、评价、FAQ、门店信息——这些恰恰是常从 API 拉、或在客户端渲染的组件。而它们，正是买家问 AI 助手的问题的答案。
下面说怎么查清楚，你的站到底把哪些答案发出去了。
一、JS 渲染改变了机器看到的东西
一个网页有两版，得分开看：
- 第一版：有人请求 URL 时，服务器发出来的 HTML
- 第二版：浏览器下载完页面、执行脚本、增改内容后，构建出来的 DOM
人看到的是第二版。不执行 JS 的爬虫，拿到的是第一版。
最常见的三种渲染模式：
- 客户端渲染（CSR）：靠浏览器里的 JS 生成或填充页面部分内容
- 服务端渲染（SSR）：内容在服务器端生成，直接进 HTML 响应
- 静态生成：提前把成品 HTML 做好
这不只是 React 的问题。任何框架都可能用不同方式发内容，大站通常是混着用。
真正要问的问题很简单：你想让机器理解的信息，服务器发 HTML 时就已经在了吗？
二、哪些 AI 爬虫能渲染 JS
Google 能。
Google 把自己的 JS 处理分成三步：抓取、渲染、索引。页面进渲染队列后，Google 的网页渲染服务（web rendering service）会在处理索引前执行 JS。
但不是每个 AI 爬虫都这么干。
Vercel 和 MERJ 跨 Vercel 网络、Next.js 和其他技术栈分析过 AI 爬虫行为，测试发现：GPTBot、OAI-SearchBot、ChatGPT-User、ClaudeBot、Meta-ExternalAgent、Bytespider、PerplexityBot 都不渲染 JS。 因为用 Googlebot 的基础设施，Google 的 Gemini 例外；Applebot 在 Vercel/MERJ 测试里也渲染了 JS。
数据里有个有意思的细节：ChatGPT 相关的爬虫在 11.5% 的请求里抓取了 JS 文件，Claude 是 23.84%。
它们把文件下下来了，但没执行。
所以一个爬虫可以把你的 JS 当文本收走，却始终没构建出用户看到的那个页面。
还有个原因别把这当成简单的"ChatGPT 爬虫"问题：AI 公司为了不同目的跑多个爬虫。最稳的做法，是不依赖某一个爬虫"恰好能正确执行 JS"。
三、真正的失效是局部的
整站不可见，一眼就能发现。局部不可见，发现不了。
多数站不会全客户端渲染。静态的营销文案、编辑内容可能已经在服务器响应里了，而连着数据库、API、第三方工具的组件是后来才加上的。
贵就贵在这。
常见的例子：
- 定价是页面加载后从 API 拉来的
- 产品参数和对比网格在客户端拼出来
- 评价数和星级是第三方插件插进来的
- FAQ 答案是手风琴展开时才加进 DOM 的
- 产品信息藏在标签页后面
- 无限滚动列表没有分页的 HTML 替代
- 门店/经销商/地点查找器要交互后才出结果
现在把这些组件当"答案"看，而不是"网站部件"：
- 多少钱？
- 怎么比？
- 好不好？
- 有没有这个功能？
- 我附近能买到吗？
这些都是购买问题。
那篇讲"怎么保养产品"的博客，AI 爬虫可能读得顺顺的。而能让你产品被推荐的参数和定价，可能读不到。
对电商站尤其如此——这也是为什么 JS 渲染要跟产品网格、分面导航、内链、可爬性这些更大的电商 SEO 工作一起看。
四、为什么 Google 能原谅，LLM 爬虫未必
Google 给 JS 内容第二次机会。
初次抓取后，Google 可以把页面放进渲染队列执行 JS。Google 自己说渲染可能几秒完成，也可能更久。你不能假设 AI 爬虫也会这样，它收到的响应里没有那信息，可能就真的没有那信息了。
这点更关键，当你想想 AI 爬虫到底为什么来抓内容：训练、搜索检索、智能体（agent）、其他功能，Cloudflare 已经在自己的 AI 爬虫报告和控制里把这几类分开了。
也就是说，一个答案的缺失，不总是"漏了一次实时检索"那么简单。如果一个系统在为语料库收集信息，而你的产品细节没在它收到的 HTML 里，那你就丢了"让信息从你站被收集"的机会，检索之后也许能补，也许补不上。
这也是为什么 LLM SEO 不能当成叠在传统技术 SEO 之上的一层。机器得先拿到信息，才能拿信息干点什么。
这也是"GEO 依赖 SEO"的一个例子：很多让内容对搜索引擎可达的技术底子，同样决定 AI 系统能不能拿到、能不能读懂。
客户端渲染有它存在的道理
不是说客户端渲染不好。它把活推到用户设备、能减服务器压力、让交互状态好管。现代组件框架也让它成了很正常的建站方式。
"别用 React 了"不是有用的建议。更好的问题是：哪些组件必须存在于初始 HTML 里，哪些其实是加载后的增强？ 这能变成一个工程需求单。
五、raw HTML 里必须有什么
从"帮爬虫理解页面、发现另一个页面、回答别人关于你业务的提问"的任何东西开始。
页面级信号：标题和 meta 描述尽量不依赖客户端渲染就能拿到。canonical 要特别留意，Google 建议用 HTML 指定 canonical URL。可以用 JS，但 Google 警告别把 canonical 改成和原始 HTML 里不同的 URL。meta robots 指令、hreflang 和其他重要页面元数据，同样审查一遍。对不渲染的爬虫，规则很直白：信息不在它收到的响应里，JS 之后也不会补上。
内容和链接：H1、标题结构、正文主体、回答重要问题的内容，得在 HTML 里。包括标签页和手风琴里展示的内容。你仍可以用 JS 控制内容"展开还是收起"，但不该由 JS 决定内容"存不存在"。链接也得像个链接，Google 建议用带 href 的可爬 <a> 元素，一个绑了 JS 点击事件的 <div> 不是可靠的发现路径。无限滚动要提供可爬的分页 URL，别让更深的库存依赖交互。
结构化数据：Google 能处理用 JS 生成的 JSON-LD（在受支持的实现里）。不执行 JS 的爬虫，收不到只在脚本跑完才生成的结构化数据。如果产品、组织、评价这类结构化数据对机器理解页面很重要，尽量放进初始 HTML。
分析与追踪：GA4 在这儿给不了全貌。不执行你分析 JS 的 AI 爬虫，不会在 GA4 里显示为正常访问。所以仪表盘看起来健康，爬虫收到的却是差别很大的版本。能直接看到这些请求的，是服务器日志和 CDN 的爬虫报告。这个测量缺口，正是这类问题能活那么久的原因。
六、怎么看"不渲染的爬虫"看到了什么
第 1 步：看"查看源代码"，不是"检查"
最容易犯的错。Chrome 的 Elements 面板显示的是 JS 跑完后的 DOM。想看服务器发来什么，那个视图是错的。
Windows 按 Ctrl+U，Mac 按 Cmd+Option+U，打开"查看网页源代码"（View Page Source）。然后搜具体的东西——别搜公司名或页面 H1，搜你怕丢的那样：一个价格、一个参数、一条 FAQ 答案、一条评价、一个地点、一个对比点。那行字不在，不渲染的爬虫就从初始 HTML 里拿不到它。
要看原始响应，我更习惯用 Network 标签：刷新页面，点 document 请求，开 Response 标签。
第 2 步：禁用 JavaScript
开 Chrome DevTools：
- 按 Ctrl+Shift+P 或 Cmd+Shift+P 打开命令菜单
- 搜 "Disable JavaScript"
- 选中它
- DevTools 还开着的状态下刷新页面
- 看剩什么
这不是对每个爬虫的完美模拟，但是最快找出"完全依赖 JS 的组件"的办法。
第 3 步：Screaming Frog 里跑两次爬取做对比
这才是把抽查变成审计。
进 Configuration → Spider → Rendering，用 Text Only 模式跑你的重点 URL 集。再用 JavaScript 渲染开着爬同一批 URL。开始前打开 Store HTML 和 Store Rendered HTML，Screaming Frog 就能让你对比原始和渲染后的 HTML。
看差异：字数、H1、标题、可索引性、内链、重要页面文案。两次爬取的差，就是你的起点缺口清单。Screaming Frog 的 JS 报告还能标出"内容只在渲染后 HTML 里出现"的页面，以及被挡的资源、渲染截图。
第 4 步：在 Search Console 里看 Google 的版本
同一个 URL 过一遍 Search Console 的 URL Inspection 工具。选 Test Live URL，再查测出来的 HTML 和截图。这告诉你 Googlebot 能渲染什么。别用它替掉查 raw 响应——两个一起用。Google 看到了、raw HTML 却没有，正是我们要找的那种缺口。
第 5 步：不用浏览器抓页面
对自己站一个 URL 跑个基本 curl 请求，返回的 HTML 响应里没有浏览器执行 JS。这是审计里最快的 sanity check。浏览器给你用户最终拿到什么，响应给你服务器实际发了什么。
七、答案单元审查
多数技术审查按"页面"组织。在这个问题上，我认为理解错了。
一个页面几乎能过所有技术检查，却仍能藏起 AI 系统回答一个购买问题所需的那一条信息。所以别审查页面，而是审查答案单元。答案单元，是你网站用来回答"你希望品牌被引用的那个问题"的具体内容。
怎么做：
- 我在哪能买到 [产品]？
- [产品] 带 [某功能] 吗？
- [产品] 适合 [某用法] 吗？
- [产品 A] 和 [产品 B] 差在哪？
- [产品] 多少钱？
一个站技术审查能过 98%，却在每个高意图问题上栽在答案单元审计上。两种结果都可能准确——它们量的是不同的东西。
八、JS 与 LLM 可见性修复清单
找到缺口后，按优先级修：
- 服务端渲染或静态生成那些回答购买问题的内容
- 标签页和手风琴的内容发进初始 HTML
用 JS 控制"可见"，不控制"存在" - 标题、meta 描述、canonical、重要 JSON-LD 放进服务器响应
- 无限滚动后面提供可爬的分页
- 导航和内链用带 href 的真
<a>标签 - 查你的 CDN 和机器人管理设置
在边缘就被挡的爬虫，根本走不到"渲染"那一步 - 看服务器日志或 CDN 报告里的 AI 爬虫活动
GA4 不够 - 大版本发布后，重跑"纯文本 vs 渲染"对比
这些修复也属于站点的整体技术健康。机器人管理在 2026 年更值得盯——Cloudflare 已经给 AI Search、AI Training、AI 用户操作三类爬虫分了独立开关，站长更能控制哪类自动化系统能访问内容。如果爬虫连 URL 都进不来，渲染只是半截问题。
九、你的站能排名，却仍藏起最好的答案
这就是为什么我不会拿 Google 排名当"站已准备好迎接 AI 搜索"的证据。
Google 能渲染页面。
查看 HTML。更关键的是，查看 HTML 里那些真正要紧的答案在不在。
我担心的不是你的保养指南。是你的价格、参数、对比、评价、库存在不在页面中显示。
如果这些答案要等 JS 跑完才存在，那当一个品牌在传统搜索排得好、却总在 AI 回答里消失时，要先去这儿看。