AI 爬虫不会执行 JavaScript

简短的答案

AI 爬虫不会执行 JavaScript。当 GPTBot、ClaudeBot 或 PerplexityBot 请求一个页面时，它执行的是一次普通的 HTTP GET，取走服务器返回的字节，再按文本解析。没有浏览器，没有 DOM 构建，没有水合，也不会等待 XHR 返回结果。Vercel 与 MERJ 基于单月承载 5.69 亿次 GPTBot 请求和 3.70 亿次 ClaudeBot 请求的网络所做的联合分析发现，没有任何证据表明主流 AI 爬虫会执行 JavaScript。这些爬虫有时确实会下载脚本文件——GPTBot 在 11.50% 的请求中抓取了 JavaScript，ClaudeBot 为 23.84%——但下载之后从不运行它们。

Google 是唯一的例外，这也正是许多团队至今没有察觉到问题的原因。Googlebot 运行着一套无头 Chromium 渲染服务，Gemini 则以这套基础设施作为事实依据。因此，一个客户端渲染的参数化目录完全可以在 Google 搜索中获得很好的排名，同时又在 ChatGPT、Claude 和 Perplexity 中彻底缺席。而这两类受众如今已不再是同一批人：Forrester 的 2026 年采购方研究发现，94% 的企业采购者已在采购过程中使用 AI，Adobe 也测得 2026 年第一季度零售网站的 AI 引荐流量同比增长 393%。

GPTBot 实际收到的是什么

有必要把这里涉及的两份文档说清楚，因为大多数目录团队从头到尾只看过第二份。

原始 HTML 是源服务器写入响应的那段字节流。它就是 curl 打印出来的东西、view-source: 显示的东西，也是纯文本 HTTP 客户端所解析的东西。

渲染后的 DOM 则是浏览器解析完那份 HTML、下载并执行完每一个脚本、完成每一次 fetch() 调用、应用完每一处变更之后，留在内存里的东西。它就是浏览器开发者工具 Elements 面板中显示的内容。

在一个现代 SPA 目录里，这两份文档几乎毫无共同之处。原始 HTML 只是一具空壳：一个 <div id="root">、一份预加载清单，外加上百 KB 的打包文件引用。每一条有意义的字符串——型号、封装、容差、工作温度范围、RoHS 状态、生命周期状态、库存、价格阶梯——都是稍后才到达的，来自一次爬虫永远不会发起的 API 调用。

AI 爬虫看到的只有你的原始 HTML，此外别无他物。如果某项规格没有出现在服务器返回的字节里，那么对模型而言，这项规格就不存在。

哪些客户端会渲染，哪些不会

表中每一个“否”都是 Vercel 与 MERJ 数据集中实测到的行为，而不是推断。每一个“是”都有运营方的公开文档支持：Google 公布了自己的渲染流程，Apple 自家的爬虫文档也写明 Applebot“可能在浏览器中渲染你网站的内容”。Anthropic 较新的 Claude-SearchBot 与 Claude-User 出现在该研究之后，未被单独测量；此后也没有任何运营方宣布为它们建立渲染流程。

这带来的实际后果，是一种很不利的不对称。渲染是抓取过程中昂贵的那一环，而省掉这一环的运营方，恰恰就是如今横在你的产品与你的买家之间的那些。

为什么参数化目录比其他任何页面都失败得更彻底

Adobe 在 2026 年 4 月的分析中为零售页面的机器可读性打分，结果发现产品详情页只有 66%——所有页面类型中最低的，低于首页（75%）、类目页（74%），甚至低于 FAQ 页面（80%）。这个排序并非偶然。承载着最结构化、最有价值、与决策最相关数据的页面，恰恰也是用 JavaScript 堆得最多的页面。

大部分损失可以归结为五种模式：

1. 01筛选状态只存在于客户端。你的参数选型器是一个从本地 store 取数的 React 组件。“0603、100nF、X7R、50V”这样的组合没有对应的服务端渲染 URL，因此爬虫无从抓取，也无从引用。
2. 02规格表其实是一个 API 响应。页面外壳先渲染出来，然后由一次对 /api/product/attributes 的请求把表格填满。爬虫止步于外壳。
3. 03价格与可用库存被刻意放在客户端。从缓存角度看这很合理，但对机器可见性是致命的，因为看不到库存的模型不会推荐这个型号。
4. 04标签页和折叠面板延迟加载内容。数据手册、应用笔记、合规证书和 CAD 链接通常都是点击之后才加载的。而爬虫从不点击。
5. 05无限滚动取代了分页。从第 51 个产品开始，根本就没有可抓取的 URL。

2026 年 8 月，Partsgraph 审计了全球 984 个分销商与制造商域名，覆盖北美、欧洲和亚洲。AI 可见性得分的中位数是 100 分中的 50 分，而且样本中有 70% 被评为 D 级或 F 级。大约有一半的网站，无法向一个标准的非浏览器客户端提供哪怕一个可读的目录页面。电子元器件分销是其中最弱的细分领域，中位数仅为 34。

我如何测试 AI 爬虫能否读取我的目录？

请针对你自己的源站来做这件事。伪造爬虫 user-agent 去测试竞争对手的网站只会得到假阴性结果，因为企业级机器人管理系统是按来源 IP 而非 user-agent 字符串来验证爬虫的——一个来自未知地址的伪造请求头，无论 robots.txt 怎么写都会被拦下验证。

1. 01抓取原始 HTML。挑出你最有价值的那一个产品页面。

curl -sS --compressed -o page.html -w "status=%{http_code} bytes=%{size_download}" "https://example.com/products/part-number"

1. 01在字节里查找型号。不是在浏览器里查——是在文件里查。

grep -c "MPN-12345" page.html

如果返回的是 0，那么没有任何 AI 爬虫能够识别出这个页面讲的是那个型号。

1. 01查找三个参数值，也就是你认为工程师会拿来筛选的那些参数。

grep -oiE "operating temperature|tolerance|package|rohs|lifecycle" page.html | sort | uniq -c

1. 01数一数结构化数据块的数量。

grep -c "application/ld+json" page.html

结果为零，说明没有任何机器可读的产品记录。结果为一个或多个，那你应当把它提取出来，验证它确实带有 sku、mpn、gtin、brand、offers 以及你关键的 additionalProperty 条目，而不只是一串面包屑导航。

1. 01与渲染后的页面做对比。在禁用 JavaScript 的浏览器中打开同一个 URL。留下来的内容，大致就是爬虫拿到的内容。它与正常页面之间的差距，就是你的不可见部分。

1. 01检查整条路径，而不是单个页面。对类目页、搜索结果页、数据手册链接和 CAD 下载重复上述步骤。一个爬虫即便能读懂产品页，如果无法从可抓取的类目列表走到那里，照样寸步难行。

一个通过测试的页面，会出现几十次型号，参数标签以文本形式存在，并且至少有一个 JSON-LD 块。作为参考，一个构建良好的产品页面通常会返回 60–200 KB 的 HTML，其中包含完整的规格表；而一个失效的 SPA 外壳只返回 4–15 KB，里面除了打包文件引用什么都没有。

如何在不重写网站的前提下修好它？

你不需要更换技术平台，你需要的是让源站返回的字节里包含事实。有四条路径，而且它们并不互斥。

对产品路由和类目路由做服务端渲染，是可持续的答案。如果你所用的框架本来就支持它，那么把目录路由迁到服务端组件、或迁到带增量重新验证的静态生成，通常是以周为单位的工作量，而不是以季度计，因为数据层早就存在了——只不过一直是从错误的一侧调用的。

预渲染是诚实的过渡方案。在构建时或按计划把每个产品页面渲染一次，把 HTML 缓存在边缘节点，再对所有访问者提供同一份内容。给人和机器提供同一份文档；向爬虫伪装投放另一个版本的页面，既是合规风险，实际上也是自毁长城，因为模型只会引用它收到的那个版本。

服务端渲染的 JSON-LD 是投入最小、杠杆最高的改动。把它放进服务器输出的 HTML 里，而不是放进标签管理器。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "sku": "MPN-12345",
  "mpn": "MPN-12345",
  "name": "100 nF 50 V X7R 0603 ceramic capacitor",
  "brand": { "@type": "Brand", "name": "Example Components" },
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Capacitance", "value": "100 nF" },
    { "@type": "PropertyValue", "name": "Voltage rating", "value": "50 V" },
    { "@type": "PropertyValue", "name": "Dielectric", "value": "X7R" },
    { "@type": "PropertyValue", "name": "Operating temperature", "value": "-55 to +125 C" }
  ],
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "0.042",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Markdown 镜像是让一个页面变得毫无歧义的最廉价手段。为每个产品页面在一个稳定且被链接到的 URL 上提供纯文本版本，规格表以 markdown 表格的形式呈现。纯文本客户端能完美解析它，用同一份数据源生成它几乎不花什么成本，而且它给了你一个规范的机器接触面，前端改版时也不会漂移。请注意 llms.txt 并不是这回事：截至 2026 年，没有任何主流 AI 运营方承诺会读取它，Google 的 Search Relations 团队也明确拒绝为它背书。镜像之所以有效，是因为它们就是普通的、被链接到的页面。

覆盖层则是把上述一切放到现有网站的前面，而不是塞进网站里面。一个 sidecar 服务或边缘 worker 从你现有的 PIM 读取数据，在你自己的域名上提供服务端渲染的、代理可读的页面、JSON-LD、markdown 镜像，以及一个托管的 MCP 端点。面向客户的网站则毫无变化。这正是 Partsgraph 采取的做法，也是越来越多制造商正在自建的东西：Microchip 于 2025 年 11 月发布了面向其产品数据的免费公共 MCP 服务器，ECIA 旗下的 TrustedParts 也在 2026 年 6 月推出了库存 AI 代理服务。

按顺序，先做什么

1. 01对你最重要的十个产品运行上面那套六步测试，并记录字节数。
2. 02在产品页面上以服务端渲染的方式输出 JSON-LD。这是改动最小、可测量效果最大的一步。
3. 03让每一项规格、每一个数据手册链接和 CAD 链接都出现在初始 HTML 里，即便交互版本仍然留在客户端。
4. 04为每一个重要的参数筛选组合，提供一个真实的、可抓取的、服务端渲染的 URL。
5. 05为每个产品发布一份 markdown 镜像，并从页面上链接过去。
6. 06做完这些之后，再去操心排名、提示词和回答占有率。检索先于引用；在内容真正存在于响应正文里之前，没有什么可以优化。

这里的机制既不微妙，也没有争议。模型只能引用它收到的东西，而它收到的就是你的原始 HTML。除此之外的一切，都只是一个从未发生过的渲染步骤。

想知道你的产品目录处在什么水平？Partsgraph 免费的 AI 可见性评分工具会在 [/audit](/audit) 上针对你自己的域名运行本文中的这些检查。