JavaScript SEO：确保 Google 能够收录您的 JS 渲染页面

收录分两轮进行

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 推送该网址，让修正后的版本按您的时间表被处理，而不是等待渲染队列。