收录分两轮进行
Googlebot 会先抓取您的原始 HTML，并能几乎立即收录该初始响应中已经存在的任何内容。只有在 JavaScript 运行之后才会出现的内容，会被放入第二轮处理队列——即渲染——这一过程使用独立的资源，滞后于初始爬取的时间可能从几秒到（在爬取资源受限的网站上）长得多不等。如果您的内容或内部链接只在第二轮之后才存在，那么您就是在依赖一条更慢、也更不确定的收录路径。
真正会破坏收录的因素
- 只有在客户端发起请求后才渲染的主要内容或内部链接，初始 HTML 中没有任何有意义的内容。
- 内容被锁在需要用户操作——点击、滚动、悬停——之后才能显示，而 Googlebot 没有理由执行这些操作。
- 页面渲染所需的 JS 或 CSS 文件被 robots.txt 屏蔽；参见robots.txt vs noindex了解屏蔽为何可能适得其反。
- 客户端路由从不改变实际的 HTTP 状态码——一个损坏的路由可能渲染出空白页面或显示未找到的提示，却依然返回 200，从而表现为软 404。
- 仅在无头浏览器环境中才会出现的水合或渲染错误，在正常的人工测试中不易被察觉。
如何查看 Google 实际看到的内容
Search Console 的“网址检查”工具中有一个“已测试网页”视图，展示 Google 渲染器运行后得到的渲染 HTML 和截图——而不仅仅是原始响应。将其与您的源 HTML 进行对比：如果关键内容或链接在原始响应中缺失、只在渲染后才出现，那么您就完全依赖于渲染队列，而非更快的初始爬取。
真正有效的做法
- 对于 SEO 而言重要的内容和导航链接，应进行服务端渲染（或静态生成），而不是在页面加载后通过客户端请求获取。
- 对于内部链接，使用真正的
<a href>元素，而不是绑定在非锚点元素上的点击处理程序——Googlebot 会跟随 href，而不会执行任意的 JavaScript 事件绑定。 - 不要屏蔽页面渲染所依赖的 JS/CSS 资源包——Google 需要抓取它们才能完成页面渲染。
- 页面修复完成后，不要只是被动等待下一轮渲染——直接请求重新收录，或通过 IndexNow 推送该网址，让修正后的版本按您的时间表被处理，而不是等待渲染队列。
各框架的注意事项
- 客户端 React 应用：普通的单页应用发送的是一个几乎为空的 HTML 外壳。对于需要获得排名的页面，请使用支持服务端渲染或静态生成的框架。
- Next.js 和 Nuxt：服务端渲染和静态生成默认会将内容放入初始 HTML 中。请留意那些只在客户端副作用（effect）中加载的重要内容。
- Angular 和 Vue：使用 Angular 的服务端渲染，或为 Vue 使用 Nuxt，让页面在送达时 HTML 中就已包含内容。
- 无限滚动：请搭配可独立加载的分页网址，让爬虫能够访问首屏之外的内容。
今天就能做的快速测试
打开页面，选择“查看网页源代码”（而不是“检查”），然后搜索主要内容中的一句话以及几个内部链接网址。如果源代码中找不到它们，说明它们依赖 JavaScript。接着运行免费的可收录性检查，确认页面返回 200、未设置 noindex，并且 canonical 正确。
常见问题
Google 能收录 JavaScript 内容吗？
能。Google 使用较新版本的 Chrome 渲染 JavaScript。问题在于时效性和可靠性：渲染发生在初次抓取之后，而渲染过程中出现的错误可能导致部分内容缺失。
Bing 和其他爬虫会渲染 JavaScript 吗？
Bing 也会渲染 JavaScript，但许多其他爬虫（包括大多数社交媒体爬虫和 AI 爬虫）只读取初始 HTML。服务端渲染能让所有这些爬虫都看到您的内容。
现在还推荐使用动态渲染吗？
不推荐。Google 将动态渲染（向机器人提供预渲染版本）定位为一种权宜之计，而非长期解决方案。推荐的做法是服务端渲染或静态生成。
每个页面都需要服务端渲染吗？
不需要。需要登录才能访问的页面、仪表板以及任何您不希望出现在搜索结果中的内容，都可以继续使用客户端渲染。请优先处理需要获得排名的页面：着陆页、文章，以及产品页和分类页。
如何判断收录问题是否由 JavaScript 引起？
在“网址检查”的实时测试中，比较原始 HTML 和渲染后的 HTML。如果关键内容或链接只在渲染后才出现，或者渲染截图看起来显示异常，那么 JavaScript 很可能就是原因。