打开一家公司的官网，产品介绍、价格、联系方式一样不少。换一个角度，用程序直接请求同一个网址，拿回来的 HTML 里可能只有一个空的容器和几行脚本引用。前一种是浏览器执行完 JavaScript 之后的样子，后一种才是爬虫最先拿到的东西。
两者之间的差距，决定了 AI 平台能不能读到这个网站。
客户端渲染的页面，爬虫拿到的是什么
现代网站常见的一种做法叫客户端渲染：服务器只返回一个几乎空白的 HTML 骨架，页面内容由浏览器下载并执行 JavaScript 之后，再从接口取数据、拼出来。用户感觉不到任何差别，因为这些步骤都由浏览器在后台完成。
爬虫不一定会做这些步骤。它发起请求，收到 HTML，从中提取文本和链接。如果它不执行 JavaScript，看到的就是那个骨架：没有标题，没有正文，没有价格，也没有指向其他页面的链接。这样的页面对它来说是一个空壳，背后投入的所有内容工作都等于不存在。
问题在于这件事在浏览器里完全察觉不到。网站看起来一切正常，运营人员也就没有理由去怀疑。
Google 会渲染 JavaScript，其他爬虫呢
关于 JavaScript 渲染，目前说得最清楚的官方文档来自 Google。Google Search Central 的文档写明，Google 处理 JavaScript 网页分为抓取、渲染、编入索引三个阶段；页面在渲染队列里可能只停留几秒，也可能更久。即便如此，文档依然建议采用服务端渲染或预渲染，理由之一是并非所有爬虫都能运行 JavaScript。
Google 在另一份讲动态渲染的文档里说得更直接：其他搜索引擎可能会忽略 JavaScript，看不到由 JavaScript 生成的内容。
国内的情况，百度搜索资源平台的《百度移动搜索建站优化白皮书》提醒站长，移动端的 H5 页面很多采用 JS 方式加载，更容易产生空短页面；爬虫如果发现一个网站大面积是低价值的空短页面，会认为整个站点价值偏低。这份白皮书的最近更新日期是 2017 年，引用时应当把年份考虑进去；它说明的至少是国内搜索引擎很早就面对过同样的问题。
AI 平台的爬虫文档则几乎不谈这个话题。OpenAI 公开的爬虫说明列出了 OAI-SearchBot、GPTBot、ChatGPT-User 等几个 User-Agent 各自的用途，也说明了 robots.txt 更新后搜索系统大约需要 24 小时才会调整，但对是否执行 JavaScript 只字未提。
国内几家 AI 平台的情况更不透明。豆包、DeepSeek、文心一言、通义千问在联网回答时如何获取网页，我们没有找到任何一家公开说明其爬虫是否执行 JavaScript 的技术文档。它们在联网时用的是哪一套抓取和检索链路，外界也无从逐一核实。文档缺席的地方，只能按最保守的情况准备。
| 文档来源 | 对 JavaScript 的说法 | 可以得出的判断 |
|---|---|---|
| Google Search Central | Googlebot 会渲染，但要排队；并非所有爬虫都能运行 JavaScript | 连 Google 自己都建议服务端渲染 |
| Google 动态渲染文档 | 其他搜索引擎可能忽略 JavaScript | 不能拿 Google 的能力推断别人 |
| 百度移动搜索建站优化白皮书 | JS 加载的 H5 页面更容易产生空短页面 | 国内搜索引擎同样存在这个问题 |
| OpenAI 爬虫说明 | 未提及 JavaScript 渲染 | 没有承诺，就不能假设它会渲染 |
把这几份文档放在一起，稳妥的结论只有一个：除了 Google 明确说明会渲染之外，对其他爬虫都应当按「不执行 JavaScript」来准备。 这不是说它们一定不渲染，而是没有任何一家作出过承诺，而网站的可见度不该押在一个没有承诺的能力上。
现代网页的 JavaScript 有多重
这个问题之所以普遍，是因为今天的网页本来就高度依赖 JavaScript。HTTP Archive 发布的 2024 年《Web Almanac》JavaScript 章节统计显示，移动端网页加载的 JavaScript 体积中位数是 558 KB，桌面端是 613 KB；移动端中位数页面加载时有 206 KB，也就是约 44% 的 JavaScript 字节在页面加载过程中并未被用到。
JavaScript 体积大不等于页面一定是客户端渲染，很多网站在服务端输出完整 HTML 之后才加载脚本。这组数字说明的只是背景：脚本已经是网页的常态，内容到底由谁生成，必须逐个页面去看，不能凭网站看起来正常就下结论。
页面可渲染性怎么自查
最简单的方法不需要任何工具：在浏览器设置里关闭 JavaScript，重新打开页面。剩下的内容，大致就是一个不执行脚本的爬虫能看到的东西。
稍微严谨一点，可以对比「查看网页源代码」和开发者工具里的元素面板。前者是服务器返回的原始 HTML，后者是脚本运行之后的结果。关键内容如果只出现在后者里，这一页就依赖客户端渲染。
还有两个经常一起暴露的问题。一是未知路径返回 200 状态码和首页内容，也就是所谓软 404，单页应用尤其容易出现；二是防火墙或 CDN 把陌生的 User-Agent 当作攻击流量拦截。前者会让爬虫抓到大量重复内容，后者会让它什么都抓不到。只读 robots.txt 发现不了这两个问题，得用各家爬虫的 User-Agent 实际发起请求才行。
改成服务端渲染要付出什么
Google 推荐的解决方案是服务端渲染、静态渲染，或者在服务端输出内容后由浏览器接管交互的水合方式。它同时明确表示，动态渲染只是一种权宜之计，不是长期方案，因为它会带来额外的复杂度和资源开销。
这类改造的难点通常不在技术，而在排期。它需要工程团队动手，而工程团队手上永远有更紧急的需求。实际推进时，比改造本身更耗时的往往是协调。我们的 官网 AI 可读性体检 把渲染检查和爬虫访问测试放在一起做，交付的是可以直接排进工程计划的改造清单，修复默认由企业自己的团队实施。
也要承认这件事的边界。页面能被读到，只是被引用的前提，不是结果。一个渲染完全正常、但内容空泛的页面，照样不会出现在 AI 的答案里。反过来，内容写得再好，如果藏在客户端渲染后面，前面的努力都会被静默地作废。
另外，各家爬虫的行为会随版本变化，今天没有写进文档的能力，明天可能就有了。所以改造完成之后，最好隔一段时间用同样的方法再测一次，而不是做完一次就认为问题解决了。渲染可读性这个概念的更多解释，见词条 渲染可读性。
参考来源
- Google Search Central (n.d.). Understand the JavaScript SEO basics. Google.
- Google Search Central (n.d.). Dynamic Rendering as a Workaround. Google.
- 百度搜索资源平台 (2017). 百度移动搜索建站优化白皮书. 百度.
- OpenAI (n.d.). Overview of OpenAI Crawlers. OpenAI.
- Amjad, A. H. & Goel, N. (2024). JavaScript. Web Almanac 2024, HTTP Archive.