AI爬虫不渲染JavaScript——我审计了自己的11个生产站点

来自《期刊》·2026年7月27日

你的网站欢迎AI爬虫。而我的网站只向它们提供了六个词。

Google的爬虫会运行JavaScript。ChatGPT的爬虫不会。我测量了这一差异对我十一个生产站点造成的代价——其中三个完全不可见。

作者：Maasi J. Smith博士 · 阅读时间9分钟 · 发布于2026年7月27日

关键要点

AI爬虫不执行JavaScript。GPTBot、ClaudeBot和PerplexityBot只读取你的原始HTML一次然后离开。Googlebot会渲染JavaScript，但它们不会。

因此，一个客户端渲染的单页应用对它们来说是不可见的——不是排名差，而是不可见。

我测量了自己的十一个生产站点。其中三个向AI爬虫提供了不到十个词。这三个站点的robots.txt文件都完美无缺，明确邀请这些爬虫进入。

我通过构建时预渲染修复了这三个站点：词量从5、6、8词分别提升到1,442、3,048、3,021词。渲染器花了一个下午。而阻止它部署出更差东西的防护措施花了更长时间——每一个都捕获了一个真实的bug。

你可以在大约四秒内检查任何站点。脚本如下，我更希望你亲自在自己的站点上运行它，而不是相信我的任何话。

两分钟版本

我曾以为我有内容问题

上周我让ChatGPT推荐一个给分居父母使用的、能生成法庭认可沟通记录的应用程序。我正巧构建了这样一个产品。它已经上线数月。但ChatGPT没有推荐它。

我原以为是内容问题：博客文章不够多，反向链接不够多，等等。

实际上是管道问题：我的服务器向AI爬虫发送了一个空房间。

背后的机制

实际发生了什么

现在互联网上有两种爬虫，它们的行为完全不同。

Googlebot运行一个无头Chrome。它获取你的页面，执行JavaScript，等待框架构建DOM，然后索引结果。这就是为什么单页应用在Google中存活了十年。

AI爬虫——GPTBot、OAI-SearchBot、ClaudeBot、PerplexityBot、CCBot——不会这样做。它们只发送一个HTTP请求，解析返回的任何HTML，然后离开。没有渲染。没有第二次尝试。没有等待。

Google的爬虫运行JavaScript。ChatGPT的爬虫不会。这唯一的一个差异决定了AI助手能否推荐你的产品。

这不是猜测。对超过5亿次GPTBot获取的分析发现零个JavaScript执行证据。爬虫日志研究显示GPTBot在大约11.5%的请求中下载JavaScript文件，ClaudeBot大约23.8%——但两者从未被观察到运行它们。它们拉取文件，但不打开。

所以，如果你的营销页面是一个React或Vue应用，启动后只有空壳，那么AI助手关于你公司的全部信息就是：你的标题标签和元描述。

就这些。这就是整个语料库。

审计结果

我在自己站点上发现了什么

我运营着八个消费者产品、一个B2B平台、一个Web3市场和一个工作室网站。我写了一个四行脚本，指向所有十一个站点，然后去泡咖啡。回来时看到这些数据：

（2026年7月27日使用GPTBot用户代理测量。脚本见下文——请验证我。）

站点服务词数判定

FamilyCare.Help5不可见

CoParent.Help6不可见

PostPilot.Help8不可见

Inmigrante.Help2,479良好

FamilyCare Facility2,523良好

Nexaria Digital2,276良好

ExamPilot.Help2,212良好

Zari.Help2,178良好

PayLess.Help2,116良好

Smith App Studio2,120良好

ProfilePhoto.Help1,561良好

三个产品。分别只有5、6、8个词。

最刺痛的部分是：我去查看这三个站点的robots.txt文件，期望在那里找到问题。结果却看到：

AI助手与答案引擎——明确欢迎以便发现性

User-agent: GPTBot User-agent: OAI-SearchBot User-agent: ChatGPT-User User-agent: ClaudeBot User-agent: PerplexityBot User-agent: Google-Extended User-agent: CCBot Allow: /

完美无缺。这三个站点也都提供了有效的llms.txt。它们都有规范标签、开放图谱图片、Twitter卡片以及JSON-LD结构化数据。

我铺好了红地毯，用七种语言打印了欢迎标志，却全部指向了一个空房间。

得分良好的八个站点并不是市场做得更好。它们只是构建在服务器端渲染的框架上。这就是全部区别。两年产品工作，其可发现性却归结于一个下午做出的构建时决策。

为什么是现在

为什么今年比去年更重要

在2024年你还可以合理地忽略这一点。但现在不行了，有三个可测量的原因。

第一，排名和引用已经分离。Seer Interactive分析了超过5,000个URL在ChatGPT、Perplexity和AI概览中的表现，发现Google前十结果与AI引用来源的重叠率从大约70%下降到了不到20%。你的Google排名不再是AI可见性的代理。它们现在是两个独立的分销渠道，具有两种不同的机制。

第二，AI助手压倒性地引用品牌自身网站。Yext分析了ChatGPT、Gemini和Perplexity中的680万次引用，发现86%来自品牌管理的来源。关于你产品的被引用最多的来源本该是你自己。如果你只提供六个词，你等于默认放弃了这一表面积。

第三，产品发现正在转移。人们不再搜索“最佳共同养育应用”然后比较十个蓝色链接。他们直接询问AI助手并接受推荐列表。如果你不在推荐列表中，你就不在考虑范围内，而且没有第二页可待。

llms.txt能做什么和不能做什么

我想谨慎地说，因为关于这个有很多自信的废话。

llms.txt是一个提议的约定：一个位于域名根目录的纯文本文件，为语言模型总结你的网站。它廉价、静态、由服务器提供，我认为你应该有一个。

但它不是这个问题的解决方案。它是一个采用率参差不齐的自愿约定，它不取代任何爬虫索引中的实际页面，而且——这是重要的一点——我的站点中已经有了。所有三个不可见站点都提供了完美的llms.txt，但它没有拯救它们，因为一个110词的摘要不能替代一个网站。

把llms.txt当作名片。有用。但不是一栋建筑。

自己动手

在四秒内检查你的站点

以下是脚本。它以GPTBot的身份获取URL，剥离脚本、样式、注释和标签，并计算实际剩下的内容——即爬虫实际读取的内容。

（脚本内容略）

运行它：

chmod +x ai-visibility.sh ./ai-visibility.sh https://yoursite.com/ https://yoursite.com/pricing

解读结果。这些阈值是判断性而非标准化的——但在我测试的所有站点中都适用：

词数含义

200以下客户端渲染。AI助手只知道你的标题标签，其他一无所知。

200–600部分。可能是混合应用，或懒加载真实内容的页面。

600以上服务器端渲染。爬虫正在获取你的实际论点。

两个诚实的提醒。第一，词数是内容的代理，而非衡量标准——2000词导航链接和法律模板并非2000词价值。第二，perl随macOS和Linux一起提供；在Windows上使用Git Bash或WSL。

修复方法

如何修复

按努力程度排序。从顶部开始，直到你的数字改善。

预渲染你的营销路由。对于Vite或CRA应用，这通常是一个半天内的改动，是最高杠杆的修复。一个构建后步骤在无头浏览器中爬取你的路由，并将真实HTML文件写入磁盘。你的应用继续保持现有工作方式；服务器只是在JavaScript启动前有了可提供的内容。

将营销站点迁移至服务器端渲染框架。Next.js、Astro、Remix、Nuxt。如果你正在重建，这是持久的答案。注意，你只需要对公开页面这样做——登录后的所有页面可以永远保持客户端渲染，因为任何爬虫都不应看到它们。

将营销站点从应用中分离。被低估了。在yourdomain.com上的静态站点和app.yourdomain.com上的应用，提供了完美的可爬取性和更快的营销站点，并消除了整个类别的路由问题。

不要使用动态渲染。根据用户代理向机器人和人类提供不同HTML曾是标准建议。但它脆弱，存在伪装风险，而预渲染解决了同样的问题，无需任何人信任你的用户代理检测。

然后做那些廉价的事情。向必应网站管理员工具提交每个站点地图——ChatGPT的搜索依赖于Bing的索引，这是二十分钟的工作，几乎没人做。添加Article和FAQPage架构。放置一个真正的llms.txt。将你的标题写成问题，并在第一句回答，因为这是AI系统实际提取的单位。

结果

我做了什么

我为所有三个站点构建了预渲染器。以下是差异：

站点之前之后

FamilyCare.Help51,442

CoParent.Help63,048

PostPilot.Help83,021

大约270个页面现在提供了真实的HTML。没有一个低于200词阈值。

有三件我未预料到的事，而它们正是真正的教训：

天真的版本悄无声息地让事情变得更糟

我的第一个可用版本写了54个页面，但这些页面都带有首页的标题，因为我为每个路由的元数据应用等待了固定的500ms，而在四个并发无头标签下，有时元数据尚未应用。五十四个URL共享一个标题就是重复内容。我仅在对比了标题后才捕获到它。

预渲染凭空创造了一个规范标签错误

HTML外壳硬编码了rel="canonical" href="/"。当爬虫只获取一个文件时无害。但一旦每个路由都是自己的文件，每个页面就会携带两个规范标签——一个真实指向自身，一个坚持它是首页。这比没有预渲染更糟糕，而且我们的一个博客之前已经因完全相同的错误被去索引。

构建发现了一个没人注意到的损坏页面

PostPilot的/platforms页面从未设置自己的标题、描述或规范标签——它一直提供通用首页元数据。其他所有公开页面都有。没什么曾暴露这个问题，因为在单页应用中，除非你刻意去查找，否则看不到差别。

所以诚实的总结是：预渲染是容易的部分。防护措施才是工作。如果你这样做，在编写渲染器之前先编写那些能使构建失败的检查——我的每一个检查都捕获了真实问题。

前两个生产部署也直接失败了，因为构建镜像没有Chrome，后来又没有运行Chrome所需的系统库。两个失败都没有影响到任何人：脚本在任何问题时都会以非零退出，所以之前的正常工作部署保持了活跃。这就是构建时防护措施应严格失败而非发出警告的理由。

常见问题

AI爬虫执行JavaScript吗？

不。GPTBot、ClaudeBot和PerplexityBot获取原始HTML，不运行JavaScript。对超过5亿次GPTBot获取的分析没有发现JavaScript执行的证据。Googlebot是例外——它使用无头Chrome引擎渲染JavaScript。

ChatGPT能看到我的React网站吗？

只有当网站内容在服务器端渲染或预渲染后才可见。否则，ChatGPT只会看到你的标题标签和元描述。

（由于AI成本控制，原文被截断。）