前年帮一个SaaS团队排查收录问题。他们用Vue3+Element Plus搭了一套产品展示站，做得很好看，路由有200多个页面，上线两个月了。site一下百度——只收了首页。查了站长平台的数据，蜘蛛确实来爬过，但每次爬完就跑了，除了首页什么都没带走。
问题出在SPA的工作方式上。传统多页面网站，每个URL对应一个真实的HTML文件，服务器直接把带内容的页面发给爬虫。SPA不一样——你访问任何URL，服务器都返回同一个"空壳HTML"：一个<div id="app"></div>，里面什么都没有。真正的页面内容靠JavaScript在浏览器里动态渲染出来。问题就在这里：百度爬虫虽然支持执行JavaScript，但执行JS要消耗大量计算资源——它会优先抓取那些"不用等渲染就能看到内容"的页面。你的SPA页面在爬虫眼里就是个空壳，它为什么要花资源去渲染一个看起来什么都没有的页面？
一、SPA到底是个什么东西，和普通网站比好在哪差在哪
SPA（Single Page Application，单页面应用）不是指"网站只有一个页面"，而是指"整个应用只有一个HTML文件"。用户点击导航时，页面不刷新，JavaScript动态替换页面内容，体验像原生APP一样流畅。Gmail、飞书网页版、Notion都是SPA。
对用户体验来说，SPA是升级——页面不刷新、交互流畅、加载过一次之后切换路由几乎是瞬时的。但对搜索引擎来说，SPA是降级——因为爬虫拿到的HTML里没有内容，需要执行JavaScript才能看到正文。而执行JavaScript这件事，Google做得好一点（有专门的渲染队列），百度做得差一点（渲染资源有限、优先级低），其他国内搜索引擎基本不做。如果你的网站依赖搜索引擎流量，SPA的SEO问题就是绕不开的硬伤。
二、百度到底能不能渲染SPA页面，2026年的实际情况
很多人会问：百度不是支持JS渲染吗？确实支持，但"支持"和"优先收录"是两码事。
百度爬虫的工作流程分两步：第一步是抓取HTML源码，这个环节非常快——爬虫一次性抓回页面源码，如果源码里就有完整的文本内容，直接进入索引。第二步是JS渲染——如果源码里没有内容（SPA的典型特征），爬虫会把页面放进渲染队列，等有空了再用无头浏览器执行JS，拿到渲染后的内容。这个队列的优先级很低，因为渲染一个SPA页面消耗的计算资源是抓取一个静态页面的几十倍。结果是：你的SPA页面可能几周甚至几个月后才被渲染和索引，而一个静态HTML页面可能当天就被收了。
用百度站长平台的数据可以验证这一点：看"抓取诊断"，如果你的SPA页面抓取到的源码是空的（只有一个div id="app"），而渲染后的快照里才有内容——说明爬虫抓到了但没渲染。如果渲染快照也是空的——说明渲染队列还没排到你。无论哪种情况，收录都遥遥无期。
三、四个解决方案，按推荐程度从高到低
SPA的SEO问题不是无解的，但每种方案的代价不同。以下四个方案按推荐程度排列：
原理：服务器收到请求后，先在服务端执行JS渲染出完整HTML，再返回给浏览器。爬虫拿到的就是带内容的HTML，不需要二次渲染。
实现：React用Next.js，Vue用Nuxt。这两个框架已经把SSR封装好了，配置一下就能用。代码改动量取决于现有项目的架构——如果一开始就是按Next.js/Nuxt的规范写的，几乎零改动。
代价：需要Node.js服务器（不能用纯静态托管了），服务器成本略高。每次请求都要执行一次渲染，QPS高的时候服务器压力大。
适合：新项目、或者有Node.js部署能力的团队。这是目前最成熟、搜索引擎支持最好的方案。
原理：构建阶段就把所有页面预先生成静态HTML文件。部署后每个URL直接访问对应的HTML文件，不需要服务器端实时渲染，也不需要浏览器端JS执行。
实现：Next.js的Static Generation、Vue的prerender-spa-plugin、Astro框架。写一个路由列表，构建工具自动遍历每个路由、渲染出HTML。
代价：只适合内容相对固定的页面。如果页面数据实时变化（比如价格、库存），预渲染的内容就是过时的。页面数量多的话构建时间会很长。
适合：博客、产品展示、文档站、营销落地页——内容更新频率低、页面数量可预见的场景。成本最低，因为生成的是纯静态文件，可以免费托管。
原理：服务器前面加一层中间件，检测请求来源。如果是普通用户，正常返回SPA页面；如果是爬虫，用Puppeteer（无头Chrome）渲染出完整HTML再返回。
实现：Puppeteer+Express中间层，或者直接用Rendertron（Google开源项目）。根据User-Agent判断是不是爬虫。
代价：每次爬虫请求都要启动或复用一个Chrome实例渲染，服务器资源消耗大。而且Google明确表示动态渲染是"变通方案"不是长期推荐做法——有cloaking（伪装）风险。
适合：存量SPA项目没法大改、短期过渡用。长期还是要往SSR或SSG迁移。
原理：不做任何处理，指望百度爬虫自己执行JS渲染你的页面。
结果：上面已经说了——爬虫会渲染，但优先级低、速度慢、可能几周才轮到你一次。如果你的网站依赖SEO流量，这个方案的代价是"几乎没流量"。
四种方案的选择逻辑很简单：新项目直接用SSR框架（Next.js/Nuxt），一步到位；存量项目内容型用SSG预渲染，交互型用SSR改造；短期过渡可以用动态渲染顶着，但不要长期依赖。
四、选方案之前先想清楚：你的网站真的需要SPA吗
这是一个经常被跳过的问题。很多团队选Vue/React做网站不是因为需要SPA的交互能力，而是因为"大家都在用""招人方便""前后端分离更现代"。但你的网站如果只是一个内容展示站——文章列表、产品介绍、公司介绍——SPA带来的体验提升微乎其微（用户根本感觉不到"页面不刷新"和"页面刷新了"的区别），但带来的SEO损失是实实在在的。
一个判断标准：如果你的网站用户打开之后需要"用"而不是"看"——频繁的增删改操作、拖拽交互、实时数据刷新——选SPA是对的。如果用户只是"看"——浏览文章、查看产品信息、阅读文档——用传统多页面或SSG静态生成，性能和SEO都更好。
五、如果已经用SPA搭好了站，有没有不动架构的补救办法
如果SPA项目已经上线了、没法大改架构，下面几个措施能在不动代码框架的前提下缓解一部分SEO问题：
· 写一份完整的sitemap.xml提交到百度站长平台。即使爬虫渲染不了你的页面内容，至少让百度知道你有哪些URL。sitemap里每个URL要带lastmod标签，告诉百度哪些页面最近更新过。
· 把关键页面手动提交到百度站长平台的"快速收录"。普通收录要等爬虫自己来，快速收录主动推送给百度。每天有额度限制（一般是10条），优先提交最重要的页面。
· 用百度站长平台的"抓取诊断"工具逐个检查页面。看爬虫拿到的源码是什么样子的。如果源码里没有内容，说明渲染没生效。如果有内容但快照显示不对，说明渲染出了问题。
· 确保每个路由页面都有独立的title、description、canonical标签。用vue-meta或react-helmet在路由切换时动态更新head标签。虽然不能解决内容渲染的问题，但至少让百度知道每个页面是独立的、不是重复页面。
· 在页面里嵌入JSON-LD结构化数据。Schema标记不依赖JS渲染——它是直接写在HTML源码里的script标签，爬虫不需要渲染就能读取。对于本地商家类页面，加上LocalBusiness+GeoCoordinates的Schema，至少让搜索引擎知道你在哪、做什么。
这些是"创可贴"方案——能止血，但治不了根。真正解决SPA的SEO问题还是要靠SSR或SSG。如果实在没法改架构，用UC建站系统的独立部署方案是个折中思路：把需要SEO的页面用WP+HTML直出重新部署一套，需要交互的部分保留SPA，两套通过域名和链接串联。WP底层天然就是多页面架构，不存在JS渲染的问题，收录速度比SPA快一个数量级。
六、最后说两句
SPA不是一个错误的技术选择——对于需要复杂交互的Web应用来说，SPA是当前最优解。问题出在很多团队把SPA用在了不该用的地方：一个内容展示站，用户只是想看几篇文章，结果要等一个2MB的JS包下载完才能看到第一行字。这种场景下SPA带来的"体验提升"（无刷新切换）远不如它造成的伤害（首屏加载慢+SEO归零）。
技术选型的黄金法则是：工具服务于目标，而不是反过来。如果你的目标是搜索引擎流量——内容展示站、产品站、落地页——选一个对SEO友好的架构比选一个"看起来很现代"的框架重要一百倍。
