JavaScript SEO 就是确保用 JavaScript 构建的内容仍然能被找到和读取。Google 会运行 JavaScript，通常是在第二轮抓取时。而主要的 AI 爬虫根本不运行 JavaScript，所以一个只有等 JavaScript 运行后才会出现文本的页面，对它们来说几乎是空的。解决办法是让文本直接出现在 HTML 里，通过服务端渲染或预渲染。
下面是不那么舒服的JavaScript SEO版本：我自己网站的一个早期版本，对我一直告诉客户要重视的那些 AI 爬虫来说，几乎是隐形的。页面在浏览器里看起来是完整的。但它实际发送出去的，是一个近乎空白的文件和一段之后才构建页面的脚本。Google 最终会运行那段脚本。ChatGPT 的爬虫不会。
JavaScript SEO 就是确保用 JavaScript 构建的内容仍然能被找到、读取和索引的工作。这份指南会解释 Google 对 JavaScript 做什么、AI 爬虫又改怎么做、我在 50 个真实网站上测量到了什么，以及如何用一个下午检查并修复你自己的网站。
JavaScript SEO 到底是什么意思
每个网页到达访客的方式只有两种，而这一区别决定了 JavaScript SEO 的大部分内容。
- 服务端渲染（SSR）或静态 HTML。服务器发送一个完整的页面。文字、标题和链接都已经在 HTML 文件里。任何读取这个文件的东西——无论是人还是机器人——都能立刻得到内容。
- 客户端渲染（CSR）。服务器发送一个几乎空白的壳，通常是一个单独的
<div id="root"></div>，外加一个 JavaScript 包。访客的浏览器运行这个包，然后页面才会出现。
在浏览器里，这两种看起来一模一样，这就是问题藏得这么好的原因。只有在遇到不运行 JavaScript 的访客时，差异才会显现。那个访客看到的是壳，而一个壳没有任何可以参与排名、引用或标注的内容。
作为单页应用构建的 React、Vue 和 Svelte 应用，默认在客户端渲染。许多用 AI 网站构建器制作的网站也是如此。Next.js、Nuxt 和 Astro 等框架可以改发送完整的 HTML，但前提是网站按那种方式配置。光看框架名字说明不了任何问题：你必须看服务器实际发送了什么。
Google 如何处理 JavaScript：抓取、渲染、索引
Google 确实会运行 JavaScript。Google 自己的文档明确说明，它主要通过三个阶段处理 JavaScript 网页应用：抓取、渲染和索引。
重要的细节是前两个阶段之间的间隔。Googlebot 先抓取 HTML，然后把页面放入队列，交给无头 Chromium 浏览器渲染。用 Google 的话说：
页面可能会在这个队列里停留几秒钟，但也可能更久。（Google Search Central，JavaScript SEO 基础知识）
所以客户端渲染的页面确实会被 Google 索引，但要走两轮；而且第二轮中任何出错的地方（脚本错误、被屏蔽的文件、缓慢的 API 调用）都可能让 Google 拿到空壳。Google 还警告说，它不会渲染来自被屏蔽文件的 JavaScript，所以 robots.txt 里一条屏蔽你的 JavaScript 或 CSS 文件夹的规则，会在它面前悄悄把你的页面变成空白。
Google 自己的建议（同一份指南里）是不要依赖那第二轮渲染：
并不是所有机器人都会运行 JavaScript。（Google Search Central，JavaScript SEO 基础知识）
这句话就是这篇文章的全部论点。Google 能应付 JavaScript。而读取你网站的大多数其他系统不能。
AI 爬虫会渲染 JavaScript 吗？
不会。这是大部分 JavaScript SEO 建议写得太早、没来得及覆盖的部分。Vercel 和 MERJ 分析了 Vercel 网络上的爬虫流量，并于 2024 年 12 月公布了结果。他们在渲染问题上的发现毫不含糊：
目前主流 AI 爬虫都不会渲染 JavaScript。（Vercel 和 MERJ，AI 爬虫的崛起）
他们测试的名单包括 OpenAI 的 GPTBot、OAI-SearchBot 和 ChatGPT-User，Anthropic 的 ClaudeBot，以及 PerplexityBot。他们发现这些爬虫确实会抓取 JavaScript 文件，但不会执行它们。有两个例外值得知道：Google 的 Gemini 使用 Googlebot 的基础设施，所以它像 Google 一样渲染；Applebot 通过基于浏览器的爬虫渲染页面。
对客户端渲染的网站来说，这意味着：人们越来越常用来代替搜索的答案引擎，读到的是空壳。如果你的文本不在 HTML 里，ChatGPT、Claude 和 Perplexity 就没有任何你的内容可以引用。
两个诚实的提醒。那份研究来自 2024 年底，而爬虫是会变化的；它是我所知道的公开发表的最好的测量结果，但不是一条永久定律。另外，一些平台现在只为它们认识的爬虫预渲染页面。例如，Lovable 的文档描述了在较旧的应用上为经过验证的搜索和 AI 爬虫做预渲染。那只会帮到名单上的爬虫，帮不到别人：链接预览、较小的 AI 工具以及任何新东西，仍然会拿到壳。
我在 50 个 AI 构建的网站上测量到的结果
为了看看这有多普遍，2026 年 9 月 20 日我测量了 50 个网站，它们按顺序取自三家 AI 网站构建器的公开展示区：20 个来自 Lovable，17 个来自 Bolt，13 个来自 Replit。每个首页都被抓取两次：一次是普通的、不带 JavaScript 的请求，也就是 AI 爬虫读取它的方式；一次是无头浏览器里带 JavaScript 的请求，也就是人看到它的方式。然后我统计了每个版本里的可见单词数。
- 32 个中的 20 个网站的大部分或全部文本都依赖 JavaScript
- 7 个单词是对它隐形的那批网站中，爬虫收到的中位数
- 631 个单词是同样的那些网站上，带 JavaScript 的人看到的中位数
内容太少无法判断、或无法访问的网站被排除在外。50 个中有 32 个可以判断。
这 20 个网站中的 18 个，发给爬虫的只有 1 到 11 个单词。另外两个展示了部分文本。这些网站并没有坏。在浏览器里它们是完整的页面，中位数是 631 个单词。它们只是被构建成在浏览器里自行组装。
head 标签看起来没问题，这才是陷阱
下面就是这个问题能挺过那么多审计的原因。SEO 工具最先检查的页面部分几乎总是存在的，即使在那些完全没发送内容的网站上也是如此。
| 爬虫收到的 HTML 中 | 网站数量（共抓取 38 个） |
|---|---|
| title 标签 | 37 |
| meta description | 36 |
| canonical 标签 | 22 |
| H1 标题 | 15 |
| 等待 JavaScript 的空 root div | 20 |
一份只看 title 和 meta description 的检查清单会让这些网站通过。缺失的是页面正文。在 20 个依赖 JavaScript 的网站中，只有 2 个的 HTML 里有一个 H1，而有 17 个发货时带着空的 root div。完整的方法、样本规则和原始结果都在 50 站研究里。
这不能说明什么：三个展示区的 50 个首页只是一个样本，说明这个问题很普遍，而不是在整个网络上普遍到什么程度；而且内页可能与首页不同。
我自己的网站也有同样的问题
我是在自己的网站上发现这个问题的，早于在任何其他人的网站上发现它。我某个页面的第一个版本（一个叫 /future 的页面）是一个客户端渲染的壳。它发送的 HTML 是1,984 字节，而我的名字在里面只出现了两次，两次都在 meta 标签里。读者看到的一切都是之后由 JavaScript 构建的。
对一个卖点就是"可被搜索引擎和 AI 读取"的网站来说，这等于用自己的文案打了自己的脸。所以我把网站重建为把每个页面都以成品 HTML 发布：现在构建步骤会在任何内容上线前把网站内容变成完整的页面，而且页面上没有任何东西需要 JavaScript 才能存在。动画和聊天助手仍然使用 JavaScript。文字不需要。
你可以自己验证这个说法：打开 growwithram.in 上的任意页面，按 Ctrl+U（Mac 上是 Cmd+Option+U），然后在源码里搜索页面上能看到的一句话。它会在那里。
如何在五分钟内检查你自己的网站
第一次检查你不需要 SEO 工具。你需要的是"你的服务器发送了什么"和"你的浏览器显示了什么"之间的差异。
- 查看页面源码。打开页面，按 Ctrl+U，用 Ctrl+F 搜索页面中间的一句话。如果它不在源码里，那么不运行 JavaScript 的爬虫就看不到它。
- 寻找壳。如果源码大部分是 script 标签和一个空的
<div id="root">或<div id="app">，那么这个页面是客户端渲染的。 - 检查 Google 渲染了什么。在 Search Console 里使用 URL Inspection，然后选 View crawled page，阅读 HTML。那是 Google 的第二轮：它告诉你 Google 的渲染是否成功，而不是 AI 爬虫看到了什么。
- 检查你的 robots.txt。确保它没有屏蔽你的 JavaScript 和 CSS 加载自的文件夹。Google 不会用它不被允许抓取的文件来渲染。
- 每个模板选一个页面重复检查：首页、产品或服务页、博客文章、分类页。渲染问题属于模板，所以每个模板查一个页面就能覆盖整个网站。
如果你习惯用终端，一条命令就能给你爬虫视角的单词数：
curl -s https://yoursite.com/ | sed -e 's/<[^>]*>/ /g' | tr -s ' \n' ' ' | wc -w在那项研究里，我用这个标准把低于 50 个单词的页面判定为"对爬虫隐形"。
如何修复：服务端渲染、预渲染，或一个临时方案
有三个真正的选项，其中一个是权宜之计。
| 方案 | 爬虫收到什么 | 什么时候用它 |
|---|---|---|
| 服务端渲染（SSR） | 完整页面，每次请求时构建 | 内容频繁变化或需要个性化 |
| 静态生成 / 预渲染 | 完整页面，提前构建好 | 内容在发布时才变化：大多数营销网站和博客 |
| 动态渲染 | 一份预渲染副本，只提供给被识别的机器人 | 只作为迁移期间的临时桥梁 |
对大多数商业网站来说，预渲染是最简单的答案：页面在两次发布之间很少变化，所以构建一次，然后给所有人提供成品 HTML。Next.js、Nuxt、Astro 等框架都支持它。如果用的是 AI 构建器，看看平台现在提供什么：比如 Lovable 的文档说，自 2026 年 5 月 13 日起，新应用已使用服务端渲染。
Google 对第三个选项的态度很直接：
动态渲染是一种变通方案，不是推荐的解决方案（Google Search Central，动态渲染作为变通方案）
它只帮到你的服务器认识的机器人，而且它让你不得不保持每个页面的两个版本同步。用它来争取时间，而不是把它当作修复本身。
这些都不意味着要移除 JavaScript。Vercel 的研究把实用要点说得很清楚：客户端渲染对计数器、聊天组件和交互元素这类增强功能仍然有效。规则比"不要用 JavaScript"更窄、更容易：你想被找到的文字必须放在 HTML 里。
JavaScript SEO 最佳实践：一份检查清单
一旦内容进入 HTML，下面这些检查能抓住其余问题。每一条都来自 Google 的 JavaScript SEO 指南，或来自我在审计中看到的东西。
- 链接是真正的链接。Google 说它只能发现带
href的<a>元素形式的链接。带 onclick 处理器的按钮，对爬虫来说不是链接。 - 路由使用真正的 URL，而不是片段。
/services是一个页面；#/services不是。单页应用应该使用 History API。 - 缺失页面返回真正的 404。一个用 200 状态显示"未找到"的客户端应用会制造软 404。Google 的指南给出两种修复：重定向到一个返回 404 的 URL，或者给错误视图加一个 noindex 标签。
- title、description 和 canonical 要出现在初始 HTML 里。JavaScript 可以设置它们，但 Google 说设置 canonical 的最佳方式是在 HTML 里，而且 JavaScript 不应该把它改成不同的 URL。
- 没有重要内容在等待点击。只有打开标签页或按下按钮才加载的文本，可能不会被爬虫看到，因为它不会点击。
- JavaScript 和 CSS 可被爬取。robots.txt 里不能有屏蔽页面渲染所需文件的规则。
- 结构化数据尽量放在 HTML 里。Google 能读取 JavaScript 注入的 JSON-LD；不运行 JavaScript 的 AI 爬虫不能。
JavaScript SEO 审计会检查什么
五分钟检查告诉你有没有问题。审计告诉你问题在哪里、波及网站的多少、以及先修什么。当我审计一个 JavaScript 网站时，工作遵循与上面研究相同的"两次抓取"方法，但应用于每个模板，而不是单个首页。
- 每个模板的原始对比渲染。对每种页面类型，比较服务器发送的 HTML 与 JavaScript 运行后的页面：单词数、标题、链接和图片。两者之间的差距就是问题的规模，而且它几乎总是模板问题，而不是页面问题。
- 只在渲染后出现的链接。如果导航、相关文章或分页只在 JavaScript 运行后才出现，那么不渲染的爬虫找到的页面会少得多。统计每个模板两个版本里的内链数量。
- 两个版本的 head 标签。title、description、canonical 和 robots meta 在原始版和渲染版之间可能不同。JavaScript 在加载后改变的 canonical 或 noindex 是最有破坏性的发现之一，因为它可能悄悄与 HTML 里的那个互相矛盾。
- 缺失页面上的状态码。请求一个本不该存在的 URL。一个用 200 和一条友好的"未找到"消息应答的单页应用，正在制造软 404。
- robots.txt 对照页面自身的文件。检查页面渲染所需的任何东西都没被屏蔽，另外还要单独检查你允许了哪些 AI 爬虫。
- Google 实际渲染了什么。每个模板选一个页面做 URL Inspection，与浏览器显示的内容比较。如果 Google 的渲染 HTML 缺内容，问题出在渲染本身，而不只是跳过渲染的爬虫。
每一条发现都附有它出现的页面和一种你自己验证的方法，因为渲染问题很容易声称，也很容易证伪。如果一个发现无法从外部复现，它就不会进入报告。
接下来做什么
JavaScript SEO 曾经是一个只属于 Google 的问题，也只有 Google 式的答案：耐心点，渲染器总会到的。那些从不运行 JavaScript 的 AI 爬虫的出现改变了一切。今天，一个客户端渲染的页面会被 Google 延迟索引，并且被大多数在网络上回答问题的系统当作空白内容来读取。
先从每个模板的一个页面的五分钟检查开始。如果文本在源码里，你就没问题，可以继续走检查清单。如果不在，那就是全站最有价值的那个技术修复，因为其他每一件 SEO 工作都依赖内容首先可被读取。
常见问题
JavaScript 会影响 SEO 吗？
只有当内容依赖它时才会。Google 会运行 JavaScript，通常在抓取之后的第二轮，所以客户端渲染的页面可能被延迟或不完整地索引。大多数 AI 爬虫根本不运行 JavaScript。如果你的文本在服务器发送的 HTML 里，页面上的 JavaScript 就没有害处。
客户端渲染对 SEO 不好吗？
对你想被找到的内容来说，在实践中是的。Google 可以索引它但要走两轮，而主流 AI 爬虫只读取空壳。客户端渲染对不需要被索引的交互功能没有问题。
AI 爬虫会渲染 JavaScript 吗？
主流爬虫不会。Vercel 和 MERJ 发现 GPTBot、OAI-SearchBot、ChatGPT-User、ClaudeBot 和 PerplexityBot 会抓取 JavaScript 文件，但不会执行它们。使用 Google 基础设施的 Gemini 以及 Applebot 会渲染。
服务端渲染 vs 客户端渲染：哪个对 SEO 更好？
对任何你想被找到的页面，是服务端渲染或静态预渲染。爬虫一次请求就收到成品页面。客户端渲染让索引依赖一个大多数 AI 爬虫永远不会执行的第二步渲染。
如何检查 Google 是否能看到我的 JavaScript 内容？
在 Search Console 里使用 URL Inspection，打开 View crawled page，阅读 Google 渲染出的 HTML。要看非渲染爬虫得到什么，查看页面源码（Ctrl+U）并搜索页面里的一句话。
相关阅读（延伸外链）
以下为推荐的相关技术教程，来自致知笔记：
- 如何将笔记本电脑连接到外接显示器
- 如何检查 IP 地址是静态还是动态（Static/Dynamic IP）
- 如何在 Windows 11/10 中创建密码重置盘
