JS渲染的网站怎么做SEO优化？202X实用避坑指南

很多中小站长、前端转运营的朋友最近都在问：为啥我用vue、react、Next.js或者纯原生JS撸出来的页面看着挺酷炫，百度、谷歌的收录量却只有个位数，排名更是几乎没有？其实问题大概率出在JS渲染机制上——传统搜索引擎爬虫对js资源的抓取、渲染、解析能力虽然这些年有进步，但还是有不少“盲区”和“慢节奏”，如果不针对性优化，再好的内容都会被“藏”在浏览器执行后的代码堆里，爬虫看不见，自然谈不上海量曝光，接下来咱们就用最接地气的问答方式，把JS渲染SEO的核心痛点、解决方案、常见坑点全说透，看完保证能动手优化自己的项目。

什么是JS渲染？为什么会影响seo？

这是所有优化的基础,搞不懂机制就别谈落地，先掰扯明白。

JS渲染的三种主流形式

现在做前端开发,渲染方式基本逃不开三类，咱们先对应看看各自对SEO的友好度：

1. 客户端渲染（CSR）这是最常见的坑点高发区，简单说就是：浏览器先从服务器拿到一个几乎空壳的html文件（只有根标签、几个meta、script/CSS链接），然后下载JS/css资源，等JS加载完、执行完，再用JS去请求后端API拿数据，最后把DOM（页面结构）拼出来、渲染到屏幕上。举个例子，你用纯vue.js写个商品列表页，用F12看“网络”→“响应”里的index.HTML，大概率只有<div id="APP"></div>和一堆引入；但在“元素”面板里就能看到完整的商品卡片、价格、链接——那就是浏览器替JS擦屁股拼的。早期的搜索引擎爬虫（比如2018年前的百度普通爬虫）根本不会去“等待”或者“模拟浏览器执行”JS，拿到空壳HTML就走了，所以你的内容等于白写；现在虽然普通爬虫也能爬，但“等待时间有限制”“某些复杂JS交互用的第三方库识别不了”“API返回的动态metA标签爬取不到”这些问题还是存在。

2. 服务端渲染（SSR）既然浏览器拼dom慢还藏内容，那干脆让服务器来拼！SSR的逻辑是：用户/爬虫发起请求→服务器拿到请求路径→调用后端API拿数据→用前端框架的SSR能力（比如Next.js的getServerSideprops、VUE SSR的rendertoString）把数据和模板拼好，生成完整的、包含所有可见内容和必要meta标签的HTML字符串→直接把这个完整HTML返回给浏览器/爬虫。浏览器拿到完整HTML后，不用等太多JS就能先显示出内容（首屏加载快，用户体验好）；爬虫拿到的也是现成的、能直接解析的文本和链接，SEO友好度拉满，不过SSR也有缺点：服务器压力大（每个请求都要拼一遍HTML）、部署麻烦（得搭node.js服务器，不能直接丢CDN静态托管）、开发时要注意“水合（Hydration）”问题（就是浏览器拿到HTML后，把它和本地执行的JS关联起来，让后续交互能正常用）。

3. 预渲染（PRerendering）这是介于CSR和SSR之间的折中方案，适合内容更新频率不高、不需要个性化展示的页面（比如企业官网、博客文章列表页、单页产品介绍页），预渲染的逻辑是：在项目打包上线前，或者有定时任务触发时，用headLessChrome（无头浏览器，没有界面，能在后台模拟chrome访问页面并执行JS）访问所有指定的路由，生成对应的完整HTML文件→把这些HTML文件和原来的CSR资源一起丢CDN或者静态托管服务器。用户/普通请求访问时，CDN直接返回对应的预渲染HTML（首屏体验好），然后水合成CSR页面；搜索引擎爬虫爬的时候，也是直接拿预渲染好的完整HTML，SEO效果和SSR差不多，预渲染的优点是开发成本低（不用改太多前端代码，只用加个预渲染插件就行）、部署简单（丢静态托管就行，不用搭Node.js）、服务器压力小（只在预渲染的时候用一次资源）；缺点是内容更新时需要重新触发预渲染（不然爬虫拿到的是旧内容）、不适合超大规模路由（比如有10万+商品的电商网站，预渲染一次可能要几小时甚至几天）、个性化内容预渲染不出来（比如登录后的个人中心页面，预渲染的时候是未登录状态，内容全是空的）。

现在搜索引擎爬虫对JS的支持到底怎么样？

很多人会说“现在谷歌百度都支持JS了，不用优化了”——这是个大误区！咱们得客观说说现在的情况：

1. 支持但有选择地爬主流搜索引擎（谷歌、百度、必应）的普通爬虫现在都能爬取并解析大部分基础JS，但不会爬取所有内容：它们有自己的“渲染预算”，如果你的页面加载JS太慢（比如单个JS文件超过500KB）、嵌套太深（比如有10层以上的异步请求，最后一层才拿内容）、或者用了复杂的动态DOM操作（比如用setTimeout延迟3秒以上才加载内容），它们可能会直接放弃渲染，拿个部分渲染或者未渲染的HTML就走了。

2. 动态meta标签处理有差异meta标签（比如title、description、og:image这些）是SEO的核心，但如果是用JS动态修改的，不同搜索引擎的处理速度不一样：谷歌的普通爬虫一般能识别延迟1-2秒以内的动态meta；百度普通爬虫的识别率和速度会慢一些，有时候可能要靠百度站长平台的“url提交”或者“站点地图”里的补充信息才能收录；必应的话，普通爬虫对动态meta的支持和谷歌差不多。

3. 第三方库和异步交互内容识别不全如果你的页面用了一些小众的动画库、图表库，或者是用了无限滚动（Infinite scroll）、懒加载（Lazy load）这些异步交互来展示内容，主流爬虫可能会识别不全：比如无限滚动只爬取第一屏的内容，懒加载只爬取可见区域的图片（虽然现在很多库支持用intersection Observer+loading="lazy"属性来让爬虫识别，但还是有部分老版本的插件不支持）。

JS渲染SEO优化的核心方案有哪些？怎么选？

搞懂了机制和现状,接下来就是核心的解决方案了，咱们先列出来，再说说每种方案的适用场景：

直接上服务端渲染（SSR）

如果你的项目是内容更新频率高（比如新闻资讯站、电商网站的商品详情页）、需要个性化展示但核心通用内容要优先让爬虫看到（比如电商网站的商品描述、价格是通用的，推荐商品可以等登录后用水合加载）、预算充足能搭node.js服务器的情况，直接上SSR是最优解。

具体怎么落地？

现在主流的前端框架都有官方或者社区成熟的SSR方案,不用自己从零开始写：

1. React生态：用Next.jsNext.js是现在React SSR的首选，它内置了很多SEO优化的功能，不用自己写太多配置：

• getServerSideprops：适合每次请求都要拿最新数据的页面（比如实时新闻详情页、电商的限时秒杀页），每次用户/爬虫访问时，服务器都会调用这个API拿数据、拼HTML，返回的是最新内容。

• getStaticProps+getStaticPaths：适合内容更新频率不高但路由很多的页面（比如博客文章详情页、电商网站的历史商品详情页），在项目打包上线前，或者有增量静态再生（Incremental Static Regeneration，ISR）触发时，服务器会先调用getStaticPaths拿到所有需要预渲染的路由，再调用getStaticProps拿每个路由的数据、拼HTML，生成静态HTML文件；普通请求访问时，CDN直接返回静态HTML，速度极快；如果内容更新了，ISR会在后台自动重新生成这个路由的静态HTML，不用重新打包整个项目。

• 选这两个API的好处是：Next.js会自动把拿到的数据注入到HTML里，生成完整的、包含所有可见内容的HTML字符串；还会自动处理动态meta标签（比如用next/head组件修改title、description，这些修改会直接写到预渲染/服务器渲染的HTML里，爬虫能直接识别）。

• 首屏渲染用getServerSideProps/getStaticProps/getStaticPaths：这三个API是Next.js的核心渲染API，咱们要根据页面类型选对：

• 增量静态再生（ISR）是杀手锏：刚才说了ISR，这个功能太香了！比如你的博客有1000篇文章，打包上线前预渲染了所有文章，现在你更新了其中一篇，不用重新打包部署，Next.js会在下次有人访问这篇文章的时候，或者你设置的定时时间（比如每小时），自动在后台重新生成这篇文章的静态HTML，然后替换掉CDN上的旧版本——既保留了静态托管的速度，又解决了内容更新的问题。

• 其他优化细节：Next.js还内置了图片优化（next/image组件，能自动压缩图片、生成不同尺寸的图片供不同设备使用、支持懒加载，对SEO和用户体验都好）、代码分割（自动把代码分成多个小文件，只加载当前页面需要的代码，加快首屏加载）、字体优化（next/font组件，能自动加载googlefonts或本地字体，避免阻塞渲染）这些功能，都是免费的SEO加分项。

2. Vue生态：用Nuxt.jsNUXt.js是Vue SSR的首选，功能和Next.js差不多，只是API名字不一样：

• 类似Next.js的getServerSideProps，Nuxt.js用的是useasyncdata（Nuxt 3）或者AsyncData（Nuxt 2）+fetch（Nuxt 2）；类似getStaticProps+getStaticPaths，Nuxt 3用的是useAsyncData+generate.routes，Nuxt 2用的是asyncData/Fetch+generate.routes；类似ISR，Nuxt 3用的是useAsyncData+reValidate，或者Nitro的静态缓存（Static CAChe）。

• Nuxt.js也内置了meta标签优化（Nuxt 3用useHead，Nuxt 2用head属性）、图片优化（Nuxt Image模块）、代码分割、字体优化这些功能，上手也很快。

3. 纯原生JS项目：用Express+EJS/Pug模板引擎如果你的项目是用纯原生JS写的，不想换框架，可以搭一个简单的express.js Node.js服务器，用EJS、Pug这些服务端模板引擎来拼HTML：具体逻辑就是用户/爬虫发起请求→Express服务器拿到路径→调用后端API拿数据→把数据传给模板引擎→模板引擎把数据和模板拼好生成HTML→返回给浏览器/爬虫，不过这种方式开发成本会比用Next.js/Nuxt.js高很多，而且没有内置的增量静态再生、图片优化这些功能，不太推荐新项目使用。

用预渲染（Prerendering）替代SSR

如果你的项目是内容更新频率低（比如企业官网、个人博客、单页产品介绍页）、路由数量少（一般不超过1000个）、预算有限不想搭Node.js服务器的情况，预渲染是最好的折中方案。

具体怎么落地？

预渲染的落地也很简单,主流的前端框架都有成熟的预渲染插件：

1. React生态：用react-snap或者prerender-spa-plugin

• react-snap：这是一个轻量级的预渲染插件，不用搭服务器，只用在package.json里加个脚本命令就行，适合React CSR项目；它的原理是在项目打包后，自动用Headless Chrome访问package.JSON里配置的所有路由，生成对应的完整HTML文件，替换掉原来的空壳HTML；还支持动态meta标签、懒加载图片识别、预加载字体这些功能，上手非常快。

• prerender-spa-plugin：这是一个webpack插件，比react-snap重一些，但更灵活，适合所有用Webpack打包的前端项目（不管是React、Vue还是纯原生JS）；它的原理和react-snap差不多，也是用Headless Chrome预渲染路由，但支持更多的配置（比如设置等待时间、过滤不需要预渲染的路由、配置代理访问本地后端API）。

2. Vue生态：用vue-snap或者prerender-spa-pluginvue-snap的功能和react-snap差不多，是专门针对Vue CSR项目的轻量级预渲染插件；prerender-spa-plugin刚才说了，也适合Vue项目。

3. 通用预渲染服务：用Prerender.io或者Netlify Prerendering如果你不想在项目里加任何插件，也可以用第三方的通用预渲染服务：

• Prerender.io：这是一个老牌的预渲染服务，原理是你把你的网站托管在CDN或者静态服务器上，然后把CDN的请求拦截一下：如果是搜索引擎爬虫发起的请求，就把请求转发到Prerender.io的服务器，Prerender.io会用Headless Chrome访问你的页面，生成完整的HTML返回给爬虫；如果是普通用户发起的请求，就直接返回原来的CSR资源，不过Prerender.io是收费的，免费版每月只能预渲染250个页面。

• Netlify Prerendering：如果你的网站是托管在Netlify上的，可以直接开启Netlify Prerendering功能，这是Netlify免费提供的预渲染服务，原理和Prerender.io差不多，适合中小项目使用。

预渲染的常见坑点怎么避？

预渲染虽然简单,但也有不少坑，咱们提前说一下：

1. 预渲染不出来：比如登录后的个人中心页面，预渲染的时候是未登录状态，内容全是空的——解决方法就是不要把这些个性化页面加入预渲染列表，或者用条件渲染把未登录状态的通用提示信息加进去，更新时预渲染不及时**：比如你更新了企业官网的新闻资讯，但是预渲染的HTML还是旧的——解决方法就是：如果用的是react-snap/vue-snap，更新内容后重新打包部署一次；如果用的是prerender-spa-plugin，可以写个定时脚本自动重新预渲染；如果用的是第三方预渲染服务，可以调用它们的API手动触发单个路由的重新预渲染。

2. 第三方统计/广告代码导致预渲染失败：比如你加了百度统计、Google AdSense的代码，这些代码可能会在页面加载时弹出弹窗或者发起跨域请求，导致Headless Chrome停止渲染——解决方法就是在预渲染的时候屏蔽这些第三方代码，或者用条件判断：如果是Headless Chrome访问，就不加载这些代码（可以用navigator.UserAgent判断，Headless Chrome的userAgent里一般会有HeadlessChrome或者Prerender字样）。

CSR项目+优化搜索引擎爬虫的抓取体验

如果你的项目已经是CSR项目，不想大改（比如是已经上线很久的老项目，重构成本太高）、内容更新频率不高、路由数量少的情况，可以用这个方案，虽然效果不如SSR和预渲染，但比不优化强很多。

具体怎么优化？

这个方案的核心就是：让搜索引擎爬虫能“更快”“更完整”地爬取并解析你的CSR页面，主要做以下几件事：

1. 优化JS/CSS资源的加载速度搜索引擎爬虫的渲染预算有限，加载速度越快，爬虫越愿意等待渲染完页面：

• 代码分割：把代码分成多个小文件，只加载当前页面需要的代码——React用React.lazy+Suspense，Vue用异步组件+defineAsyncComponent。

• 压缩JS/CSS文件：用WebPack/vite的内置压缩插件压缩JS/CSS文件，去掉注释、空格、换行符，减少文件体积。

• 使用CDN加速：把JS/CSS/图片这些静态资源丢到CDN上，让用户/爬虫从离自己最近的节点下载资源，加快加载速度。

• 预加载关键资源：用<link rel="preload">标签预加载当前页面需要的关键JS/CSS/字体资源，避免阻塞渲染。

• 延迟加载非关键资源：用<script defer>或者<script async>标签延迟加载非关键的JS资源（比如第三方统计/广告代码），不要阻塞页面的首次渲染和水合。

2. 优化动态meta标签的处理虽然普通爬虫对动态meta标签的支持有差异，但还是要做好：

• 不要用settimeout延迟修改meta标签：最好在页面加载的第一时间（比如React的useEffect(() => {}, [])、Vue的onMounted(() => {})或者更早的生命周期钩子）就修改meta标签。

• 提交包含补充meta标签的站点地图：在百度站长平台、Google Search Console提交包含title、description、lastmod这些补充信息的xml站点地图，帮助搜索引擎爬虫识别页面内容。

• 使用预渲染的meta标签作为兜底：虽然是CSR项目，但可以在空壳HTML里先写一些通用的meta标签，作为爬虫没有渲染完页面时的兜底。

3. 优化异步交互内容的展示主流爬虫可能识别不全无限滚动、懒加载这些异步交互内容，要做好优化：

• 无限滚动：加上分页链接作为兜底：不要只靠无限滚动加载内容，还要在页面底部加上“上一页”“下一页”“第1页”“第2页”这些分页链接，让搜索引擎爬虫能通过这些链接爬取所有内容；同时可以用Intersection Observer+window.history.pushState()来更新URL，让每个分页都有独立的URL，方便爬虫爬取和收录。

• 懒加载：用标准的loading="lazy"属性，同时给图片加上宽高属性：loading="lazy"属性是W3C官方推荐的懒加载属性，主流搜索引擎爬虫都能识别；给图片加上宽高属性可以避免页面加载时的布局偏移（CLS），提升用户体验和SEO排名；同时可以给图片加上alt属性（描述图片内容），提升图片SEO的效果。

4. 提交URL到搜索引擎站长平台虽然搜索引擎爬虫会自己爬取网页，但手动提交URL能加快收录速度：

• 百度站长平台：可以用“普通收录”里的“主动推送”“自动推送”“Sitemap提交”这三种方式提交URL，主动推送的速度最快。

• Google Search console：可以用“URL检查工具”手动提交单个URL，或者提交XML站点地图。

• 必应站长工具：和Google Search Console差不多，也是用URL检查工具或者提交XML站点地图。

5. 使用百度移动专区的“MIP改造”？这里要提一下MIP（mobile Instant Pages，移动即时页面），这是百度官方推出的一套针对移动网页的加速方案，对百度移动搜索的排名有一定的加成——但MIP现在已经不太推荐新项目使用了，因为它的限制太多（只能用MIP官方提供的组件，不能用自己写的复杂JS），而且Next.js/Nuxt.js的首屏加载速度已经很快了，百度移动搜索对SSR/预渲染的移动页面也有很好的排名；不过如果是已经是CSR项目、不想大改、主要做百度移动搜索的话，可以试试MIP改造。

JS渲染SEO优化的常见测试工具有哪些？

优化完之后,一定要测试一下效果，看看搜索引擎爬虫能不能“看到”你的页面内容，推荐几个常用的测试工具：

1. 百度站长平台的“抓取诊断”工具这是专门针对百度普通爬虫的测试工具，能模拟百度普通爬虫访问你的页面，生成抓取报告，告诉你抓取是否成功、HTML里有没有包含关键内容、有没有抓取错误。

2. Google Search Console的“URL检查工具”这是专门针对Google普通爬虫的测试工具，功能和百度的抓取诊断差不多，还能告诉你页面在Google搜索里的表现情况。

3. Chrome DevTools的“元素”面板+“网络”面板+“Lighthouse”工具这是前端开发常用的测试工具，也能用来测试SEO：

• “元素”面板：能看到浏览器渲染后的完整DOM，但这是浏览器执行完JS后的结果，不是爬虫拿到的原始HTML，不能完全参考。

• “网络”面板：能看到“响应”里的原始HTML，这才是爬虫一开始拿到的内容——如果原始HTML里包含所有可见内容和必要meta标签，说明SEO优化成功；如果只有空壳，说明还要优化。

• “Lighthouse”工具：能测试页面的SEO得分、首屏加载速度（LCP）、交互性（FID）、视觉稳定性（CLS）这些核心指标，这些指标都是搜索引擎排名的重要因素。

4. Headless Chrome的“截图”功能可以用Headless Chrome的截图功能，模拟搜索引擎爬虫访问你的页面，看看截图里有没有包含所有可见内容——如果截图里只有空壳，说明还要优化。

最后总结一下：JS渲染SEO优化的核心原则是什么？

不管你用哪种方案,JS渲染SEO优化的核心原则只有一个：让搜索引擎爬虫能“更快”“更完整”“更直接”地拿到包含所有可见内容和必要meta标签的HTML字符串——符合这个原则的方案就是好方案，不符合的就要调整。

另外还要提醒大家：SEO优化是一个长期的过程，不是优化完一次就能立马有海量曝光和排名的，还要持续更新优质内容、优化页面的核心指标（LCP、FID、CLS）、建设高质量的外链——这些都是SEO的基础，不管是传统HTML网站还是JS渲染网站都要做。

好了,今天的问答就到这里，如果你还有其他关于JS渲染SEO优化的问题，可以在评论区留言，咱们一起讨论。