SEO guide: server-side rendering for React
Server-side rendering solves the core problem...
```
The content, meta tags, Open Graph tags, and internal links are all in the source HTML. Google finds pages efficiently and does not depend on the render queue.
As of March 2026, these frameworks provide SSR:
- **Next.js** for React, the most common choice.
- **Nuxt** for Vue.
- **Angular SSR** (`@angular/ssr`), which replaced Angular Universal in Angular 17 in 2023.
- **SvelteKit** for Svelte.
- **React Router 7**, which absorbed Remix in November 2024, with an SSR-first design.
Use SSR for content-heavy sites such as blogs, documentation, and marketing sites. Use it for ecommerce product pages that must be indexed fast, and for SaaS landing, feature, and pricing pages. Use it for news and media that need immediate indexing.
SSR has four costs:
- **Server load.** Each request renders on the server, which uses CPU.
- **Hosting.** Pure static hosting does not work; you need a Node.js server or a serverless runtime.
- **Complexity.** More parts can fail, and debugging is harder than in CSR.
- **Time to first byte (TTFB).** The first response is slower, because the server renders before it sends.
## Use static site generation where content allows
SSG renders pages at build time and serves the static HTML from a CDN:
1. At build time, the framework renders each route to HTML.
2. You deploy the static files to a CDN such as Vercel, Netlify, or Cloudflare Pages.
3. The CDN serves the pre-rendered HTML on each request.
4. JavaScript hydrates the page for interactivity.
SSG keeps all the SEO benefits of SSR and adds speed, because no server renders per request. It costs less, because a CDN serves the files. TTFB from a CDN edge is near-instant, which helps Core Web Vitals.
SSG has limits. The pages must be known at build time. A content change needs a rebuild and a redeploy. Personalized or real-time data needs client-side JavaScript after load.
Frameworks with SSG include Next.js, Gatsby, Nuxt (through `nuxt generate`), SvelteKit (through adapters), and Astro, which mixes React, Vue, and Svelte components. Use SSG for blogs, documentation that rebuilds on each Git push, marketing sites, and portfolio or agency sites.
**Incremental Static Regeneration (ISR)** in Next.js combines the two. Pages are static but regenerate in the background when they go stale. For example, an ecommerce product page is generated at build time and revalidates every 60 seconds. If the product changes, the next request after the cache expires triggers a new version. Users get a fast static page with fresh content.
On very large sites, full SSG builds take a long time. Generate the popular pages at build time and the rest on demand with ISR. Or use SSR for rarely visited pages.
## Treat dynamic rendering as a stopgap
Dynamic rendering detects bots and serves them pre-rendered HTML, while users get the normal CSR app:
1. The server checks the user agent: Googlebot and Bingbot, or a browser.
2. Bots get pre-rendered HTML from a headless browser.
3. Users get the CSR app.
Tools include Prerender.io, a hosted service that charges by cached page, and Puppeteer, for a custom pre-renderer on headless Chrome. Google's own Rendertron project is deprecated.
Dynamic rendering needs no application code changes, it ships faster than a move to SSR or SSG, and users keep the CSR experience. It also has four drawbacks:
- **Google calls it a workaround.** Its guidance recommends SSR, static rendering, or hydration instead.
- **Two versions to maintain.** The bot HTML and the user content can drift apart. The result can look like cloaking, which Google's spam policies forbid.
- **Cost** grows with the number of cached pages.
- **Fragility.** User-agent detection can break or be misconfigured.
Use it only in three cases: a short-term fix during a move to SSR, a legacy app that you cannot refactor, or a small site. Do not detect Googlebot to serve different content by any other method; that is cloaking.
## Diagnose rendering issues in four tests
**View source against the inspector.** Open the page source (Ctrl+U) to see the raw HTML from the server. Open the inspector to see the DOM after JavaScript runs. If the content appears in both, SSR or SSG works. If it appears only in the inspector, you have a CSR problem.
**URL Inspection in Search Console.** Enter the URL, select "View crawled page", and compare the HTML with the screenshot. If the screenshot shows content that the HTML lacks, Google depends on rendering for that content.
**Rich Results Test or the live URL test.** Google retired the Mobile-Friendly Test in December 2023. Use the Rich Results Test or the live test in URL Inspection instead. Open the rendered HTML and confirm that the title, meta tags, and content appear.
**Chrome with JavaScript turned off.** Open DevTools (F12), press Ctrl+Shift+P (Command+Shift+P on a Mac), type "Disable JavaScript", select it, and reload. If the page shows its content, SSR or SSG works. If it is blank or broken, the page depends on CSR.
## Implement SSR and SSG in Next.js
Create a project:
```bash
npx create-next-app@latest my-app
cd my-app
npm run dev
```
The examples below use the App Router, the default in current Next.js. The older Pages Router uses `getServerSideProps` for SSR and `getStaticProps` with `getStaticPaths` for SSG, with the same results.
**SSR page.** Next.js renders this page on the server for each request:
```javascript
// app/blog/[slug]/page.js
export const dynamic = 'force-dynamic'; // render on each request (SSR)
async function getPost(slug) {
const res = await fetch(`https://api.example.com/posts/${slug}`, { cache: 'no-store' });
return res.json();
}
export async function generateMetadata({ params }) {
const { slug } = await params;
const post = await getPost(slug);
return { title: `${post.title} | My Blog`, description: post.excerpt };
}
export default async function BlogPost({ params }) {
const { slug } = await params;
const post = await getPost(slug);
return (