JavaScript SEO：让爬虫正确渲染 SPA

用 React、Vue 搭的单页应用（SPA），首屏 HTML 往往是个空壳，内容靠 JS 跑完才填充。这对用户没问题，对爬虫却可能是灾难：它拿到的 HTML 里没有正文，自然无从索引，排名页里根本找不到你，辛苦产出的内容石沉大海，流量始终起不来。

JavaScript SEO 的核心矛盾就在这：现代框架带来好体验，却把内容藏进了执行之后。这篇文章讲清 CSR/SSR/预渲染三种渲染策略的取舍，以及怎么验证你的内容真的被爬虫看到了。抓取资源紧张时，错误渲染会浪费预算，可参考 抓取预算优化，别让爬虫在空壳上白忙一场。

先说我的建议：纯客户端渲染（CSR）默认对爬虫不友好，关键内容可能进不了索引，排名无从谈起。服务端渲染（SSR）或静态生成（SSG）让 HTML 直出内容，是最稳、最省心的方案。改不动架构的，用动态渲染/预渲染给爬虫一份完整 HTML，作为过渡兜底。验证手段是「原始 HTML」与「渲染后」对比，只看前者有没有正文，不看后者。

爬虫到底执行不执行 JS

Google 确实会执行 JS，但有延迟、有预算限制、且不是所有引擎都做得到（Bing、百度、各类聚合爬虫能力差异很大）。把索引命运押在「爬虫会跑 JS」上风险太高。正确做法是：让首屏 HTML 里就包含核心内容，JS 只负责增强交互，而不是承担内容交付，这样最稳。

一个判断标准：如果你的核心内容只存在于 JS 执行之后，那么任何「不跑 JS 的客户端」（RSS 阅读器、部分社媒抓取、轻量爬虫）都拿不到它。SEO 只是其中之一，可访问性、内容分发也都受影响，所以直出 HTML 是更稳妥的底线，也是对所有用户一视同仁的做法。

三种渲染策略怎么选

方案一 SSR：服务器在返回时就渲染好完整 HTML，爬虫和人都拿到内容，适合动态但需被收录的页面，比如带个性化但主体固定的列表。方案二 SSG：构建期生成静态 HTML，性能与可抓性都好，适合内容相对固定的站，比如文档和博客。方案三动态渲染：正常用户走 CSR，检测到爬虫 UA 时返回预渲染完整版。

三种策略不是互斥，可以混合：核心收录页用 SSR/SSG，后台和不收录的交互页用 CSR。完整技术框架见 技术SEO 实战手册。选型时记住一条：凡是要被搜索引擎收录的页面，原始 HTML 必须含正文，这是不可让步的红线，任何「以后再说」都会变成技术债。

怎么验证内容被看到

用 GSC 的 URL 检查工具看「已抓取的 HTML」里有没有正文；再用 curl 直接拉原始 HTML，确认关键文字在源码里而非仅在 JS 里。两者一致，说明渲染链路没问题。若原始 HTML 是空壳，优先改 SSR/SSG，其次上动态渲染，别指望 Google 的二次抓取能兜住所有页面。

验证要覆盖「重要但冷门」的页面——首页通常被特殊处理，反而掩盖了深层页的问题。挑几个分类页、详情页各跑一次，才能确认全站渲染策略真的生效，而不是只在首页做了特例，深层页依旧是空壳。把这些页面加进监控，每月复跑一次最稳。

三个典型症状

症状一：站点收录量远小于页面总数，且收录的都是空壳页，说明爬虫根本没拿到正文。症状二：排名页面里自己的内容，摘要却是「加载中」或一堆 JS 变量名，可读性为零。症状三：换引擎（如百度）后流量断崖，因为它不跑 JS，直接读空壳。出现任一条都应回到渲染策略排查。

把这些症状做成监控看板：每周比一次「已收录页数/总页数」和「收录页首屏是否含正文」。比例长期偏低就是渲染问题在恶化，早干预比晚救火省力。把「原始 HTML 必须含核心内容」写进前端规范，能从根上杜绝回潮，也让新成员一上手就走对路。

预渲染服务的接入

改不动前端架构时，预渲染是最省的兜底：单独起一个服务，对检测到爬虫 UA 的请求返回提前渲染好的静态 HTML，对正常用户仍走 CSR。这样不用动业务代码，就能让爬虫拿到完整正文，收录问题迎刃而解。

接入要点是缓存策略：预渲染结果按 URL 缓存并设置合理 TTL，避免每次请求都现渲染拖慢响应。缓存失效要和发版联动，内容更新后及时刷新对应页的预渲染，否则爬虫会长期拿到过期版本，比不预渲染还糟。更完整实践见 技术SEO 实战手册。

不收录页放心用 CSR

反过来，后台、登录态、纯交互的工具页本就不该被收录，用纯 CSR 完全没问题，别为了「统一」给它们也上 SSR，白白增加服务器负担。判断标准就一条：这个页要不要出现在搜索结果里？要，就直出 HTML；不要，就随便渲染。

把「是否需收录」作为前端渲染选型的第一个开关，能省掉大量不必要的 SSR 改造成本。团队规范里写清楚哪些路由走 SSR、哪些走 CSR，新页面上线时照表选，渲染策略就不会再和系统架构纠缠成一团。

真到动手，顺序是这样的：先列全站 SPA 页面，用 curl 拉原始 HTML，确认核心内容是否在源码里；空壳页面优先改成 SSR 或 SSG，让 HTML 直出正文；改不动架构的，接入动态渲染，给爬虫返回预渲染完整版；再用 GSC 的 URL 检查工具逐页验证「已抓取的 HTML」是否含正文；最后把「原始 HTML 必须含核心内容」写进前端发布规范，防止回潮。渲染这事没有玄学，把握住「要收录就直出 HTML」这一条，SPA 也能在搜索结果里正常露脸。

常见问题（FAQ）

Google 不是会执行 JS 吗，为什么还要担心？

Google 确实会执行，但有延迟和预算限制，Bing、百度等引擎能力更弱。别把索引命运押在「爬虫会跑 JS」上，让首屏 HTML 直出核心内容才最稳。

三种渲染策略该选哪种？

核心收录页用 SSR 或 SSG，让 HTML 直出正文；后台和不收录的交互页用纯 CSR。改不动架构就用动态渲染给爬虫一份预渲染 HTML 兜底。

怎么验证内容真的被爬虫看到了？

用 GSC 的 URL 检查工具看「已抓取的 HTML」有没有正文，再用 curl 拉原始 HTML 确认关键文字在源码里。两者一致，说明渲染链路没问题。

收录的全是空壳页，是什么问题？

说明爬虫没拿到正文，原始 HTML 里没有内容。优先改 SSR/SSG，其次上动态渲染，别指望 Google 二次抓取能兜住所有页面。

后台页面能用纯 CSR 吗？

能。判断标准就一条：这个页要不要出现在搜索结果里？不要，就放心用 CSR，别为「统一」白白增加服务器负担。