Google如何在索引中处理JavaScript
注：Vercel 是 Next.js 的前端云平台；MERJ 是数据驱动的营销公司；本文是他们通过实际测试揭开 Google 渲染的真实情况；本文翻译自 Vercel 的 Blog 文章《How Google handles JavaScript throughout the indexing process》。
了解搜索引擎如何抓取、渲染和索引网页是网站 SEO 的重要基础。然而，随着 Google 等搜索引擎的技术不断变化，尤其是涉及客户端 JavaScript，掌握有效的优化方法变得更加困难。
也有许多过时的观点仍然存在，导致大家对应用 SEO 的最佳实践感到困惑：
- “Google 无法渲染客户端 JavaScript”
- “Google 对待 JavaScript 页面有不同的处理方式”
- “渲染队列和时间对 SEO 的影响显著”
- “以 JavaScript 为主的网站页面抓取速度较慢”
为了验证这些观点，Vercel 与数据工程咨询公司 MERJ 合作，进行了关于 Google 抓取行为的实验，分析了超过 100,000 次 Googlebot 抓取，涵盖了各种类型的网站，以测试并验证 Googlebot 处理 JavaScript 的能力。
我们先回顾 Google 渲染技术的发展历程，然后探讨我们的研究发现及其对现代 Web 应用程序的实际影响。
Google 渲染功能的演变
多年来，Google 在抓取和索引网页内容的能力上发生了显著变化，了解这一演变对于掌握现代 Web 应用的 SEO 现状至关重要。
2009 年之前：JavaScript 支持有限
在搜索引擎早期，Google 主要索引静态 HTML 内容。由 JavaScript 生成的内容在很大程度上对搜索引擎不可见，因此静态 HTML 被广泛应用于 SEO 。
2009-2015：AJAX 动态渲染方案
Google 推出了 AJAX 动态渲染，允许网站提供动态生成内容的 HTML 快照。这是一种权宜之计，需要开发者为页面创建单独的可抓取版本（针对爬虫使用服务器端渲染 SSR，针对用户采用客户端渲染 CSR）。
2015-2018：早期 JavaScript 渲染
Google 开始使用没有头部的 Chrome 渲染页面，这是一次重要进步，然而这一早期浏览器版本在处理现在的 JavaScript 功能上仍存在局限性。
2018年至今：现代渲染能力
如今，Google 使用最新版本的 Chrome 进行渲染，与最新的 Web 技术保持同步。关键功能有：
- 通用渲染：Google 现在尝试渲染所有 HTML 页面，而不仅仅是某些子集。
- 最新的浏览器：Googlebot 使用最新稳定版的 Chrome/Chromium，支持现代 JavaScript 功能。
- 无状态的渲染：每次页面渲染都在一个全新的浏览器会话中进行，不会保留 cookies 或之前渲染的状态（Google 不会点击页面上的内容，如选项卡或 cookie 横幅）
- 避免内容伪装：Google 禁止为用户和搜索引擎提供不同内容以操纵排名，避免基于 User-Agent 修改内容的代码。所以优化 Web 应用的无状态渲染，并通过有状态方法实现个性化。
- 资源缓存：Google 通过缓存资源加速网页渲染，这对共享资源的页面和重复渲染的页面非常有用。Google 的网页渲染服务（Web Rendering Service）使用内部算法决定缓存资源是否仍然有效，而不是依赖 HTTP Cache-Control 头部。
今天，Google 的索引过程看起来是这样的：
研究方法
先简单说下研究方法，我们分析了 2024 年 4 月期间从多个网站收集的数据，研究了 Googlebot 如何渲染网站。
通过特殊工具跟踪爬虫行为，我们确认了哪些页面被成功渲染、渲染所需时间，以及不同内容的处理方法。本次研究涉及 37,000 多个页面，为验证相关说法提供了可靠的数据支持。
误解 1：“Google 无法渲染客户端 JavaScript”
这一误解让许多开发者避免使用 JavaScript 框架，或者采用复杂的解决方案来适配 SEO。
测试情况
为验证 Google 渲染 JavaScript 内容的能力，我们重点测试了以下方面：
- 测试 Googlebot 在抓取时，静态预渲染、服务器端渲染（SSR）、客户端渲染（CSR）的表现
- 动态内容索引：检查通过 API 异步加载内容的页面，确认 Googlebot 是否能处理并索引这些不在初始 HTML 中的内容
- 测试 Googlebot 如何处理逐步传输到页面的内容。
- 渲染成功率：对比服务器日志中 Googlebot 的抓取请求数量与成功渲染的页面信号，评估渲染完成的比例。
测试结论
我们发现，在分析超过 10 万次 Googlebot 抓取后（排除错误和不可索引页面），所有 HTML 页面均被成功完整渲染，包括具有复杂 JavaScript 交互的页面。
- 动态加载的内容（通过 API 异步获取）也被成功索引，证明 Googlebot 能处理动态内容。
- 基于 React 的 Next.js 框架完全兼容 Googlebot
- 逐步加载的内容同样成功渲染，说明这种技术对 SEO 没有负面影响。
- Google 会尝试渲染几乎所有抓取的 HTML 页面，而不仅限于少量复杂的 JavaScript 页面。
误解 2: “Google 对待 JavaScript 页面有不同的处理方式”
测试情况
我们通过以下方法测试了 Google 是否会对 JavaScript 密集型页面进行不同处理：
- CSS @import 测试：创建一个不使用 JavaScript 的测试页面，通过 CSS 文件的嵌套导入检查 Google 是否会在渲染时正确处理 CSS，并与启用 JavaScript 的页面行为进行对比。
- 状态码与 meta 标签处理：用 Next.js 构建一个测试应用，测试不同 HTTP 状态码（如 200、304、3xx、4xx、5xx）和 noindex 元标签的处理情况，以了解是否对 JavaScript 密集型页面有不同对待。
- JavaScript 复杂度分析：对比渲染不同 JavaScript 复杂度页面（简单 JS、中等交互、高度动态渲染页面）的行为，并测量初次抓取到完成渲染的时间差，评估复杂 JavaScript 是否会延长渲染时间。
测试结论
- Google 能成功渲染有或没有 JavaScript 的页面。
- 对于状态码为 200 的 HTML 页面，无论是否包含 JS，都会被渲染；304 状态页面使用原始 200 状态内容渲染，而 3xx、4xx、5xx 错误页面不会被渲染。
- 初始 HTML 中包含 noindex 标签的页面不会被渲染，即使通过 JavaScript 移除该标签也无法影响 SEO。
- JS 复杂度对渲染成功率没有显著影响，且在 nextjs.org 的规模下，JS 复杂度与渲染延迟无明显关联。但在更大规模的网站上，更复杂的 JS 可能会影响抓取效率。
误解 3 ：“渲染队列和时间对 SEO 的影响显著”
一些人认为 JavaScript 密集型页面由于渲染队列的存在会导致索引延迟。为验证这一点，我们研究了 Google 渲染页面的时间延迟和模式。
测试情况
- 渲染延迟：分析 Google 抓取页面到完成渲染的时间差（基于 37,000 多条数据）。
- URL 类型：比较带查询参数和不同页面类型的渲染时间。
- 频率模式：研究 Google 多次渲染同一页面的频率和规律。
测试结论
- 25% 的页面在初始抓取后的 4 秒内就渲染完毕；渲染时间中位数为 10 秒；75% 页面在 26 秒内完成。所以并不存在渲染队列而造成严重的索引延迟
- 虽然有少数页面渲染延迟较长（99% 的页面最多延迟约 18 小时），但这只是少数情况，并不普遍。
另外发现 URL 参数和更新频率也会影响渲染速度：
- 带有参数的 URL 会有更长的渲染延迟
- 经常更新的页面，渲染时间更短；更新较少的页面，会被 Google减慢渲染频率
| URL 类型 | 第50%位 | 第75%位 | 第90%位 |
| 所有URL | 10秒 | 26秒 | 约3小时 |
| 无参数的URL | 10秒 | 22秒 | 约2.5小时 |
| 有参数的URL | 13秒 | 31秒 | 约8.5小时 |
误解 4: “以 JavaScript 为主的网站页面抓取速度较慢”
有人认为 JavaScript 为主的网站会让 Google 更慢发现页面，我们的研究对此提出了新见解。
测试情况
- 对比不同页面类型（服务器渲染 SSR 、静态生成、客户端渲染 CSR）的链接发现速度。
- 测试 Google 是否能从未直接显示的 JavaScript 数据中发现链接。
- 分析链接被 Google 发现和抓取的时间差异。
测试结论
- Google 能成功发现和抓取所有渲染后的页面中的链接，不管渲染方式如何。
- Google 可以从 JavaScript 数据（如 JSON 数据）中找到链接，但需要明确的 URL 格式。
- 链接来源（HTML 标签或 JavaScript 数据）不会影响 Google 的抓取优先级。
- 客户端渲染页面需要先被完全渲染后才会被 Google 发现，因此服务器渲染页面有一定时间优势。
- 提供更新的
sitemap.xml能大大缩短不同渲染方式之间的页面发现时间差异。
总体影响和建议
本次研究揭示了 Google 对大量使用 JavaScript 网站的处理方式，打破了一些常见误解，并提供了以下关键结论和建议：
主要结论
- 兼容性：Google 能有效渲染和索引 JavaScript 内容，包括复杂的单页应用和动态加载的内容。
- 渲染一致性：Google 对待 JavaScript 页面和静态 HTML 页面没有本质区别，都会完整渲染。
- 渲染延迟：大多数页面在几分钟内完成渲染，而非数天或数周。
- 页面发现：JavaScript 网站不会因其技术架构在页面发现上受到不利影响。
- 内容时机：页面中的某些元素（如 noindex 标签）的加载时间点很重要，Google可能忽略客户端的动态更改。
- 链接评估：Google 在完整渲染页面后再评估链接的价值，而不仅仅是发现它们。
- 渲染优先级：Google 优先渲染内容新鲜或更新频繁的页面，而不是严格按照提交顺序。
- 渲染和抓取效率：渲染 JavaScript 页面需要更多资源，对于大型网站，优化性能和减少不必要的 JavaScript 能提升抓取效率，让更多页面被索引。
建议
- 放心使用 JavaScript：可以使用 JS 框架来提升用户体验，但要注重性能，并按照 Google 的最佳实践来处理懒加载内容。
- 错误处理：在 React 应用中添加错误处理机制，防止某个组件出错导致整个页面渲染失败。
- 关键 SEO 内容：重要的 SEO 标签和内容应通过服务器渲染或静态生成，在初始 HTML 中直接提供。
- 资源管理：确保关键资源（如 API、JS 和 CSS 文件）未被 robots.txt 阻止。
- 内容更新：需要快速更新的内容应反映在服务器渲染的 HTML 中，而不是仅依赖客户端 JavaScript。
- 内部链接和结构：设计清晰的内部链接结构，重要的导航链接用标准 HTML 标签（如
<a href="...">），而非 JS 导航。 - 站点地图：定期更新 sitemap.xml，对于更新频繁的站点使用
<lastmod>标签提示 Google 最新内容。 - 监控：使用 Google Search Console 检查页面抓取和渲染情况，确保没有因渲染策略引发的问题。
不同渲染策略的优缺点
| 功能 | 静态站点生成 (SSG) | 增量静态生成 (ISR) | 服务器端渲染 (SSR) | 客户端渲染 (CSR) |
| 抓取效率：Google 能多快、多高效地访问、渲染并获取网页内容。 | 优秀 | 优秀 | 很好 | 较差 |
| 页面发现：Google 查找新 URL 进行抓取的能力。 | 优秀 | 优秀 | 优秀 | 一般 |
| 渲染完整性：Google 加载和处理网页的准确性和完整性，是否无错误。 | 稳定 | 稳定 | 稳定 | 可能失败 |
| 渲染时间：Google 完成网页渲染和处理所需的时间长短。 | 优秀 | 优秀 | 优秀 | 较差 |
| 链接结构评估：Google 如何评估网页中的链接以理解网站架构和页面的重要性。 | 渲染后评估 | 渲染后评估 | 渲染后评估 | 渲染失败可能丢失链接 |
| 内容索引：Google 将网站内容存储和组织到搜索索引中的能力。 | 稳定 | 稳定 | 稳定 | 渲染失败可能无法索引 |
- 保持 sitemap.xml 更新可以大大缩短或消除不同渲染方式之间的页面发现时间差异。
- Google 的渲染通常不会失败。如果发生失败，往往是因为资源被 robots.txt 阻止或特定的特殊情况导致的。
尽管渲染方式可能存在细微差异，但无论使用哪种策略，Google 都会快速发现和索引你的网站。与其过度担心 Google 的渲染过程，不如专注于提升网页性能，为用户提供更好的体验。
页面速度仍是一个排名因素，Google 会通过核心网页指标 (Core Web Vitals) 评估网站性能。同时，加载速度更快也能提升用户体验，每节省 100 毫秒的加载时间，网站转化率可能提升 8%。更少的用户跳出页面，也会让 Google 认为页面更相关。性能影响叠加，毫秒决定成败。
参考链接
- 原文链接《How Google handles JavaScript throughout the indexing process》：https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process
- 《将动态渲染作为临时解决方法》https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering?hl=zh-cn