React/Next.js框架站怎么做SEO？渲染模式选错就抓成空壳

摘要：用React、Next.js这类JS框架搭的独立站和SaaS，最容易踩的SEO坑不是“谷歌读不懂JavaScript”——它早就读得懂了。真正的风险在于：你把核心内容放到了Googlebot“渲染”这一步之后，而渲染是排在抓取之后的第二道独立队列，要排队、要花算力，还可能因为一个客户端请求失败就抓到一个空壳。解法不是纠结能不能被抓，而是按页面类型选对渲染模式：能静态就静态（SSG/ISR），要动态就服务端渲染（SSR），别让主内容吊在浏览器端JS执行完之后（纯CSR）。这篇讲清楚谷歌处理JS的三阶段、四种渲染模式怎么按页面挑、Next.js App Router的渲染模型和几个致命默认值、hydration和路由的坑，以及怎么用URL检查工具看到Googlebot眼里的真实页面。

先把问题定性：框架站的SEO，是“渲染问题”不是“抓取问题”

很多人一听说“React站对SEO不友好”，第一反应是“谷歌不认JavaScript”。这个认知停留在十年前。今天的Googlebot用的是常青版的Chromium，跟你桌面上的Chrome同代内核，执行JS毫无压力。所以问题从来不是“能不能执行JS”，而是“执行JS这件事，被谷歌排在了什么位置、要付出什么代价”。

谷歌处理一个页面分三步走：先抓取（crawling），把HTML拉回来、解析里面的链接；再渲染（rendering），把页面丢进一个专门的队列，用无头Chromium跑一遍JS，生成最终的DOM；最后才是索引（indexing），拿渲染完的HTML去建库。关键就在中间那步——渲染不是抓取时顺手做的，而是排在后面单独一道队列。你的内容如果只存在于“JS执行之后”，那它就得等这道队列轮到自己，才有机会进索引。这跟传统的PHP、静态HTML站完全不同：那些站抓回来的HTML里内容就是全的，一步到位。

所以框架站SEO的全部功夫，本质上就一句话：想办法让核心内容尽早出现在谷歌拿到的那份HTML里，别把它藏在渲染队列的后面。想清楚这个定性，后面所有的技术选择——用哪种渲染模式、数据在哪取、路由怎么写——都是围着它转的。

Googlebot到底怎么处理JS：三阶段与那道渲染队列

把三阶段的机制讲细一点，因为几乎所有的坑都从这里长出来。谷歌官方在JavaScript SEO基础这份文档里说得很明白：所有返回200状态码的页面，都会被送进渲染队列，不管它有没有JS。也就是说渲染这道工序对每个页面都发生，只不过内容全在HTML里的页面渲染完还是那些内容，而靠JS才吐出内容的页面，渲染完才第一次“看见”真身。

这道队列要等多久？官方的说法是“页面可能在队列里停留几秒，但也可能更久”。Ahrefs实测给的数字是中位数五秒左右到达渲染器，但九十分位就到分钟级了。对绝大多数站，这点延迟无所谓；但对一个每天上新几百个页面、又指望它们被快速收录的站，抓取和渲染之间这道时间差就会变成实打实的收录滞后。谷歌的渲染机制这几年怎么演化、移动优先索引之后又变了什么，我在移动优先索引与Googlebot渲染机制那篇里拆得更细，这里只强调一个结论：渲染是有成本、有排队的，你越依赖它，风险越大。

顺带纠正一个流传极广的误区：很多人说“Googlebot渲染有五秒超时，超过就放弃”。Ahrefs明确辟过谣——渲染器没有固定超时，谷歌用的是缓存资源加上监控事件循环的机制，而不是掐一个死表。那个“五秒”多半是测试工具为了快速出结果自己设的限，被以讹传讹当成了谷歌的规则。所以别为了“抢五秒”去做一些奇怪的优化，方向就错了。

四种渲染模式：CSR、SSR、SSG、ISR到底怎么选

框架站的渲染模式说到底就四种，理解它们各自把“生成HTML”这件事放在了什么时间、什么机器上，就知道该怎么选了。web.dev那篇经典的Rendering on the Web把这套概念讲得最系统，我用中文和SEO的视角重新梳理一遍。

选择的第一性原则很简单：爬虫抓到的那份首份HTML里，内容是不是全的。SSR、SSG、ISR三种都能做到内容完整，区别只在“新鲜度和服务器成本怎么权衡”；只有CSR抓到的是空壳，需要爬虫额外渲染才能看见内容。所以对任何你指望被搜到的公开页面，默认就该在SSR、SSG、ISR里选，把CSR留给那些本来就不需要被索引的登录态界面。

再往下细分：内容基本不变的（关于页、博客文章、文档），用SSG最划算，构建时生成一次，之后每次访问都是秒开的静态文件，首字节时间（TTFB）和首次内容绘制（FCP）都最快；内容会变但没必要每次请求都实时算的（成千上万的商品页），用ISR，兼顾静态的速度和内容的新鲜；只有真正需要千人千面、或者每次请求内容都不同的（带登录态的仪表盘、实时报价），才值得为它付SSR每次请求都算一遍的服务器成本。Ahrefs在它的JavaScript SEO指南里把这套排序说得很直白：静态和SSR是SEO最优解，预渲染次之，纯CSR最成问题。

为什么纯CSR是框架站最大的坑

单独拎出CSR说，因为它是新手用create-react-app、Vite起一个纯前端项目最容易掉进去的默认状态，也是外贸独立站排查“收录不上去”时最常见的根因。

纯CSR的问题有三层。第一层，爬虫抓到的首份HTML几乎是空的，通常就一个根节点div挂载点加一堆script标签，真正的标题、正文、链接全靠浏览器跑完JS才填进去。谷歌还愿意帮你渲染补上，但正如前面说的，那要排队、有成本。第二层，也是很多人忽略的：谷歌之外的引擎对JS渲染的支持差得多。Ahrefs特别提醒，纯CSR排除了Bing、Yandex、百度这些引擎——它们要么不渲染、要么渲染得很不完整，你做出海、做多市场，等于主动放弃了Google之外的所有入口。第三层，就算谷歌渲染了，首屏在渲染完成前是空白的，用户体验和首屏内容对排名的影响都会连带受损，这一点我在首屏内容怎么影响SEO里展开过。

维基百科对单页应用（SPA）的词条里有句话点破了历史根源：“由于一些主流搜索引擎的爬虫缺乏JavaScript执行能力，SEO一直是想采用SPA模式的公开站点面临的一个难题。”谷歌早年甚至搞过一套hashbang的AJAX抓取方案来救急，2015年就把它废弃了，转而推荐大家干脆在服务端把首屏渲染好。二十年过去，结论没变：想被搜到的SPA，必须想办法让首份HTML里有内容，纯CSR是逆着搜索引擎的工作方式在做站。

Next.js App Router的渲染模型：默认静态，一碰运行时API就转动态

Next.js是目前React生态里做SEO最省心的框架，因为它把“内容进首份HTML”做成了默认行为。但它的App Router（较新的路由体系）有一套自己的渲染判定逻辑，不搞清楚就会莫名其妙把一个本该静态的页面弄成了每次请求实时算的动态页，白白拖慢速度、增加服务器负担。

核心规则是：Next.js默认尽量把路由静态化（构建时预渲染成静态shell），但只要你的组件里碰了“运行时API”——读cookies、读请求头headers、读URL查询参数searchParams——这个路由就会被判定为动态，退回到每次请求实时渲染。很多人无意中在一个内容页里读了下cookie判断主题色，就把整页从“秒开的静态”打成了“每次都算的动态”，自己还不知道。

Next.js较新的做法是用部分预渲染把这两者揉到一页里。官方在部分预渲染（PPR）文档里的思路是：把页面里确定不变的部分（导航、正文、商品基本信息）预渲染进静态shell，随首份HTML一起秒发出去；把真正需要运行时才知道的部分（购物车、个性化推荐）用 <Suspense> 包起来，先给个占位，再在请求时流式补上。这样对SEO最关键的正文永远在静态shell里、第一时间就在HTML中，而动态的边角料该慢就慢，两不耽误。对做内容的人来说，记住一条就够：把你要被搜到的正文，尽量放在不依赖运行时API的组件里，让它待在静态shell中。

Server Components与Client Components：别把整页标成客户端

App Router还引入了服务端组件和客户端组件的区分，这对SEO有直接影响。默认情况下，组件是服务端组件，在服务器上渲染、产出的HTML直接进首份响应，对搜索引擎最友好。只有当你需要交互（点击、表单、用useState这类hook）时，才在文件顶部加一句 “use client” 把它变成客户端组件。

坑在哪？在于 “use client” 有传染性——你在一个高层组件上标了它，它下面引入的子组件也都跟着变成客户端渲染。有些人图省事，在布局或者页面顶层就加了 “use client”，结果整棵组件树都被拽到客户端去渲染，等于把一个本可以服务端出好HTML的页面，硬生生退化成了偏CSR的行为。正确姿势是把 “use client” 尽量下沉到真正需要交互的那个叶子组件上——一个按钮、一个搜索框——让页面的主体内容留在服务端渲染。判断标准很朴素：这段内容需不需要被谷歌读到？需要，就让它待在服务端组件里出HTML；只是个交互控件、内容本身不重要，才隔离成客户端组件。

Hydration陷阱：FCP很快，但“看着能点其实点不动”

SSR和SSG都绕不开一个叫hydration（注水/激活）的过程。MDN在服务端渲染的词条里把SSR定义为“在服务器上生成HTML内容再发给客户端”，与之相对的是客户端渲染。而hydration，就是这份服务端发来的静态HTML到了浏览器后，客户端JS再跑一遍、给这些已经存在的DOM元素挂上事件处理器，让它从“能看”变成“能交互”的过程。

对SEO来说，hydration本身不是问题——谷歌看的是那份已经带内容的HTML，它不关心你什么时候把按钮激活。真正的问题是hydration带来的用户体验裂缝：web.dev那篇文章点出，服务端渲染带来了很快的FCP（用户很快看到内容），但接下来有一段时间，页面看起来已经完全加载好、可以交互了，实际上要等客户端JS执行完、事件挂上，才真的能响应操作，这段空窗在手机上“可能长达几分钟”。用户点了没反应，跳走了，这种行为信号积累起来会间接拖累排名。

所以hydration的优化方向不是让谷歌看得见（它本来就看得见），而是缩短那段“看着能用其实不能用”的空窗：别在一个页面塞太多客户端组件、别让JS包大到迟迟跑不完，把交互尽量下沉、按需加载。这也是为什么“多用服务端组件、少标use client”不只是SEO的事，也是实打实的体验优化。

路由：必须用History API，别用hash路由

框架站的前端路由有两种实现：一种改URL的hash部分（地址栏里带 #），一种用浏览器的History API改成真正的路径。这个选择直接决定谷歌能不能把你的内部页面当成独立URL来抓。

谷歌官方明确要求用History API，别用fragment（hash）来做导航——因为带 # 的URL，Googlebot没法可靠地把它解析成一个个独立页面，你的内页可能压根进不了索引。放到具体框架上：Vue Router要用history模式而不是hash模式，React Router要用BrowserRouter而不是HashRouter。另外一个同源的坑是链接的写法——内部跳转必须用真正的带href的a标签（Next.js里就是 <Link> 组件，它最终渲染成a标签），别用一个绑了onclick的div或button来做跳转。谷歌是顺着href去发现新页面的，onclick里的跳转它不执行也就发现不了，你的内链权重传导全断在这儿。

元数据：每页唯一的title和描述，别靠客户端JS现插

标题和描述对点击率的影响不用多说，框架站在这上面有个特有的坑：如果title、meta description、canonical这些标签是靠客户端JS在运行时才插进去的，就可能赶不上或者干扰谷歌的处理。

Ahrefs提到一个细节：JS插入的canonical标签只有在页面原本没有canonical时才生效，一旦页面里出现多个canonical，谷歌会全部忽略。所以最稳的做法是让这些元数据在服务端就生成好、进首份HTML。Next.js为此提供了 generateMetadata 这类服务端API，能按每个页面的内容动态生成唯一的标题和描述并直接写进HTML。要避免的是那种所有页面共用一个模板标题、或者标题靠前端脚本拼的做法——谷歌本来就有很高比例会重写你的标题（Ahrefs的数据是标题被改写约33%、描述被改写约63%），你再让它读到一个空的或雷同的标题，等于把这件事彻底交给谷歌发挥。

懒加载与无限滚动：内容必须进初始HTML，分页别丢

图片懒加载、列表无限滚动是框架站的标配交互，但它们跟“内容要能被抓”天然有张力。原则还是那句话：你指望被索引的内容，必须存在于初始HTML或者能被谷歌的渲染稳定触发，不能吊在“用户滚动/点击才加载”的事件后面——谷歌不滚动、不点击，触发不了的内容它就看不见。这跟内容折进标签页、手风琴里的道理是一样的，我在内容折进标签页手风琴Google还算不算数里讲过：只要内容写进了初始DOM，折叠起来谷歌照样计权；但如果是“点击才用JS去拉取”，爬虫就抓空。

无限滚动尤其要小心。Ahrefs建议：给无限滚动的列表始终保留一个分页版本（?page=2 这种真实可抓的URL），让谷歌能顺着分页把深层内容都爬到。它还提到一个诡异现象——JS触发的无限滚动在渲染时偶尔会把两个页面的内容当成一页索引。所以别把“无限滚动”当成唯一的内容组织方式，底下垫一套规规矩矩的分页URL，是框架站列表页的保险做法。

最致命的坑：客户端fetch拿的数据，爬虫抓不到

如果只让你记住这篇文章的一件事，就记这条：在浏览器端用fetch/axios请求接口、再把返回的数据渲染到页面上的内容，是框架站被谷歌抓空的头号原因。

为什么？因为这种模式下，服务器发出的首份HTML里根本没有这段内容，它要等浏览器执行JS、发出接口请求、等接口返回、再渲染，才第一次出现。谷歌渲染时确实可能帮你把这套流程跑完，但只要中间任何一环出问题——接口跨域被拦、接口慢到渲染时还没返回、接口对爬虫的UA有限制——谷歌拿到的就是一个没有主内容的空页面。我见过太多外贸站，产品列表、产品详情全靠前端调后端API渲染，本地打开看着好好的，谷歌却只收录了一个空框架。解法就是把数据获取搬到服务端：Next.js里在服务端组件里直接await取数、或者用getStaticProps/getServerSideProps这类在服务端跑的取数方式，让数据在HTML发出前就填好。至于怎么判断谷歌到底有没有抓到你这段动态内容、抓空了从哪查起，可以对着JS渲染的页面Google抓不到先从这几种情况查起那篇一步步排。

动态渲染（Dynamic Rendering）：已经被谷歌降级为权宜之计，别再上

前几年有一套流行的救急方案叫动态渲染：给普通用户发正常的CSR页面，检测到是爬虫就用一个预渲染服务（比如Prerender.io、Rendertron）单独给它一份渲染好的HTML。当年谷歌自己也推荐过。

但现在谷歌的态度变了，官方文档里明确写着“动态渲染是一个权宜之计，而不是解决JavaScript生成内容问题的长期方案”，因为它会带来额外的复杂度和资源开销。谷歌现在推荐的是服务端渲染、静态渲染、hydration这三条正路。原因也好理解：动态渲染要额外维护一套预渲染服务，给爬虫和用户发两套东西，本身就接近“对爬虫和用户区别对待”的灰色地带，还容易出维护事故。如果你在开一个新的框架项目，别再往动态渲染这条老路上走了，直接用Next.js这类自带SSR/SSG的框架，从根上就不需要它。

两个基础但常被忽略的配置：别封JS/CSS，给文件加指纹

有两个配置层面的坑，简单但杀伤力不小。第一，别在robots.txt里封掉JS和CSS文件。有些站出于“节省抓取”或者老习惯，在robots.txt里Disallow了 /static/ 或者 .js、.css，结果谷歌渲染时加载不到这些资源，渲染出来的页面缺样式、缺内容，判断全错。Ahrefs的建议是显式地 Allow: .js 和 Allow: .css，确保渲染资源可达。

第二，给静态资源文件加指纹（fingerprinting）。框架打包出来的JS文件名最好带上内容哈希，比如 main.a1b2c3.js。这样每次内容有大改动、文件名一变，谷歌就知道要重新下载，不会拿着缓存的旧版本渲染出一个过时的页面。文件名一成不变而内容偷偷改了，谷歌可能长期用着缓存的老资源，你的更新迟迟不生效。这两条都是一次性配置，配好就一劳永逸。

怎么看到Googlebot眼里的真实页面：URL检查工具是唯一真相

说了这么多“可能抓空”“可能没进HTML”，怎么确认自己的页面到底行不行？有一个权威方法和几个坑要避开。

权威方法是Google Search Console里的URL检查工具。Ahrefs把它称为“你的真相来源”——它能直接给你看谷歌渲染后的HTML，你可以在里面搜一段正文文字，搜得到，说明这段内容谷歌看见了；搜不到，就是抓空了。这是唯一能代表谷歌视角的工具，别的都是旁证。

要避开的错误方法：一，别用“禁用JavaScript再看页面”来判断——Ahrefs说得很直接，“你关掉JS看到的，跟谷歌看到的完全不是一回事”。二，别信谷歌网页快照，它经常只显示原始HTML、资源还因为跨域坏掉，不可靠。三，看渲染后的DOM要用浏览器的“检查”（Inspect）而不是“查看网页源代码”（View Source）——源代码是服务器发来的原始HTML，检查看到的才是JS执行后的最终DOM，后者更接近Googlebot渲染后看见的东西。养成用URL检查工具搜正文这个习惯，比读十篇理论都管用。

一个真实的排查：Next.js站产品页收录空壳

去年有个做户外储能的外贸独立站找过来，症状是：站是拿Next.js搭的，首页、博客收录都正常，唯独几百个产品详情页在谷歌里要么不收录，要么收录了标题却搜不到正文，排名自然一直起不来。

用URL检查工具一看渲染后的HTML，产品的规格、描述、参数全是空的，只有一个加载动画的占位。翻代码发现根因：产品页虽然是Next.js，但开发图省事，整个产品信息区标了 “use client”，数据是组件挂载后在浏览器端fetch后端接口拿的——典型的“框架是SSR的壳，内容是CSR的芯”。更糟的是那个接口对非浏览器UA加了限制，谷歌渲染时请求直接被挡，于是永远抓到空壳。改法很直接：把产品信息区从客户端组件改回服务端组件，数据在服务端就await取好、随首份HTML一起发出去，同时给产品页配上ISR，让它既有静态的速度、又能按周期更新库存价格。改完重新提交，两周内那批产品页陆续被正常收录，正文能搜到了，长尾词也开始有排名。整件事没动一个字的文案，纯粹是把内容从渲染队列后面挪到了首份HTML里。

五个常见误解

误解一：谷歌不认JavaScript，React站做不了SEO。过时了。谷歌用常青Chromium能执行JS，React/Next.js站完全能做好SEO，前提是把内容放进首份HTML，而不是吊在客户端渲染之后。

误解二：用了Next.js就自动SEO友好。不一定。Next.js给了你SSR/SSG的能力，但你若在页面顶层乱标use client、在客户端fetch数据，照样能把它用成偏CSR的效果，收录空壳。框架是工具，用法才决定结果。

误解三：Googlebot渲染有五秒超时。没有固定超时，这是被测试工具的默认值传出来的误区。但渲染确实要排队、有延迟，这才是你该在意的。

误解四：只要谷歌能渲染，纯CSR也无所谓。谷歌能渲染不代表Bing、Yandex、百度也能。做出海、做多引擎，纯CSR等于放弃Google之外的所有流量入口。

误解五：动态渲染是给爬虫的标准方案。谷歌已经把它降级为权宜之计、不再推荐。新项目直接上SSR/SSG，别再单独维护一套给爬虫的预渲染服务。

保哥的判断：先定内容在哪渲染，再谈框架怎么选

做了这些年，保哥的一个经验是：框架站的SEO讨论，很容易被“用React还是Vue”“上不上Next.js”这种工具之争带偏，其实真正该先定的是一件更底层的事——你这个页面的核心内容，打算在哪一步、由哪台机器渲染出来。这件事定了，用什么框架反而是次要的。

我给团队定的判断顺序永远是三步：第一步，这个页面要不要被搜到？不要（登录后的后台、纯工具界面），随便你CSR，怎么方便怎么来。第二步，要被搜到的话，它的内容变不变？基本不变的走SSG，会变但不必实时的走ISR，非得实时/个性化的才走SSR。第三步，落到框架里，把要被索引的内容尽量留在服务端渲染的部分，客户端组件只包真正需要交互的叶子。把这三步走顺了，React也好、Next.js也好、Nuxt也好，SEO都不会出大问题；三步走反了，再高级的框架也救不了一个内容吊在客户端fetch后面的空壳站。工具是末，渲染时机是本。

常见问题解答

React单页应用（SPA）到底能不能做好SEO？

能，但不能用纯客户端渲染的默认形态。纯CSR的SPA首份HTML是空壳，谷歌虽能渲染补上，但要排队、有成本，且Bing、百度等引擎支持很差。正确做法是给SPA加上服务端渲染或预渲染（用Next.js、Nuxt，或对React Router项目上SSR），让首份HTML里就带着内容。

Next.js默认就是SEO友好的吗？

它给了你SEO友好的能力，但不会自动替你用对。Next.js默认倾向静态化、内容进首份HTML；可一旦你在页面顶层标 “use client”、或在客户端fetch数据，就会把它退化成偏CSR的行为，照样收录空壳。关键是让要被索引的内容留在服务端组件里、数据在服务端取。

CSR、SSR、SSG、ISR这几种我该怎么选？

看两个问题：要不要被搜到、内容变不变。不需要被搜到的登录态界面用CSR；需要被搜到且内容基本不变的用SSG；内容会变但不必实时的用ISR；必须实时或个性化的才用SSR。对公开、想排名的页面，默认在SSR/SSG/ISR里选，别用纯CSR。

怎么确认谷歌到底有没有抓到我JS渲染的内容？

用Google Search Console的URL检查工具，看渲染后的HTML，在里面搜一段你的正文文字——搜得到就是看见了，搜不到就是抓空了。别用“关掉JS看页面”或谷歌快照来判断，那跟谷歌的真实视角不一致。

客户端用fetch拿数据渲染的内容，谷歌能收录吗？

有风险，是框架站被抓空的头号原因。这种内容不在首份HTML里，要等浏览器执行JS、请求接口、返回再渲染，中间任何一环（跨域、超时、UA限制）出问题，谷歌就抓到空页面。稳妥做法是把取数搬到服务端，让数据在HTML发出前填好。

动态渲染（给爬虫单独发预渲染HTML）现在还推荐吗？

不推荐了。谷歌官方已明确动态渲染是权宜之计而非长期方案，因为它增加复杂度和维护成本，还接近对爬虫和用户区别对待的灰色地带。新项目直接用SSR/SSG的框架，从根上就不需要它。

权威参考资料

• Google Search Central — JavaScript SEO基础：官方讲清抓取、渲染、索引三阶段与渲染队列，所有200页面都进渲染队列、常青Chromium、History API路由等一手规则。
• web.dev — Rendering on the Web：CSR/SSR/静态/hydration各种渲染模式的系统定义与性能权衡，hydration空窗“手机上可能长达几分钟”的出处。
• Next.js — Partial Prerendering（部分预渲染）：官方讲静态shell与Suspense流式如何在一页里共存，以及碰运行时API会转动态渲染的判定逻辑。
• Ahrefs — JavaScript SEO指南：破“五秒超时”误区、渲染模式优劣排序、URL检查工具是真相来源、robots放行JS/CSS等大量实操细节。
• Wikipedia — Single-page application：SPA的定义、历史SEO难题，以及2015年谷歌废弃hashbang抓取方案、转向服务端首屏渲染的来龙去脉。
• MDN — Server-side rendering（SSR）术语：服务端渲染与客户端渲染的中立技术定义，理解hydration前后关系的基础。