Server-Side Rendering vs. Static Generation for SEO

You shipped. Your product works. But Google can't see it.

If your site is a single-page application (SPA) or heavily client-side rendered, search engines are crawling a blank page. No content. No meta tags. No rankings.

You have two paths: server-side rendering (SSR) or static site generation (SSG). Both pre-render HTML so Google sees real content. Both can rank. But they have opposite trade-offs, and picking the wrong one wastes server costs or leaves money on the table.

This guide walks you through the decision. No agency speak. Just the technical rules that determine which one actually works for your site.

Prerequisites: What You Need Before Deciding

Before you can choose between SSR and SSG, you need to understand three things about your site:

Your current rendering method. Are you shipping a Next.js app? Nuxt? A custom Node server? Webflow? The framework matters because some make SSR trivial and SSG expensive, and vice versa.

Your content freshness requirement. Does your homepage change every minute? Every hour? Every day? Or once a month? Static generation works if you can rebuild on a schedule. SSR works if you need real-time data.

Your page volume. Do you have 10 pages or 100,000? Static generation builds every page at deploy time. If you have millions of pages (e-commerce sites, user-generated content), SSG becomes impractical.

If you haven't audited your site yet, start with Setting Up PageSpeed Insights and Reading Your First Report. You'll identify performance bottlenecks that SSR or SSG can fix. Then use Lighthouse for Founders: Running Your First Audit in Chrome to measure Core Web Vitals before and after your rendering decision.

For a complete technical foundation, work through Onboarding Yourself to SEO: A Self-Paced Founder Track. You'll understand how rendering impacts crawlability, indexing, and rankings.

What Server-Side Rendering Actually Does (And Doesn't)

Server-side rendering means your server generates the full HTML page on every request. When a browser or search engine asks for /about, your server runs your React, Vue, or Svelte code, fetches data, and returns complete HTML with all content visible.

Google sees the rendered page immediately. No JavaScript parsing. No waiting for API calls. The content is there.

SSR works for SEO because search engines struggle with client-side rendering. Googlebot can execute JavaScript, but it's slow and unreliable. If your page depends on JavaScript to render content, Googlebot might not wait long enough to see it. SSR removes that risk.

The cost of SSR: Every page request hits your server. If you have 1 million visitors per month, your server renders 1 million pages. That's compute cost, memory, database queries. At scale, SSR gets expensive fast.

The upside of SSR: Your content is always fresh. If you update your homepage, it's live instantly. No rebuild. No deploy pipeline. Perfect for sites with frequently changing content.

The performance trade-off: SSR adds latency. Your server has to fetch data, render the page, and send HTML back. This takes time. If your server is slow or your data fetches are slow, your Time to First Byte (TTFB) suffers. And TTFB impacts Core Web Vitals, which impacts rankings.

To measure TTFB and other performance metrics, use Setting Up Google Analytics 4 for SEO Tracking from Day One. Configure custom events to track rendering performance and page load times.

What Static Site Generation Actually Does (And Doesn't)

Static site generation means you build every page once, at deploy time, and serve the same HTML file to every visitor.

When you deploy, your build process runs your code, fetches data, renders every page, and saves the HTML files to a CDN. When a user requests /about, they get the pre-built file from the CDN. No server computation. No database query. Just a file.

Google sees the full HTML immediately. Content is pre-rendered and cached globally. Performance is excellent because there's no server-side computation.

The cost of SSG: You have to rebuild and redeploy every time your content changes. If you publish a blog post, you trigger a build. If you update product pricing, you trigger a build. For high-frequency changes, this becomes a bottleneck.

The upside of SSG: Blazing-fast performance. No server cost. Global CDN distribution. Your site can handle millions of visitors without breaking a sweat.

The scalability trade-off: SSG breaks down when you have millions of pages. If you're an e-commerce site with 500,000 products, building all pages at deploy time takes hours. Incremental Static Regeneration (ISR) helps, but it's a partial solution.

For performance measurement, Setting Up Cloudflare for SEO: The Free Speed Boost shows you how to add a free CDN layer on top of your site. Cloudflare caches your pages and serves them from edge locations worldwide, which boosts Core Web Vitals regardless of whether you use SSR or SSG.

The SEO Decision Tree: When to Use Each

Here's the brutal truth: both SSR and SSG rank. The search engine sees HTML either way. The real decision is about content freshness, scale, and cost.

Use Static Site Generation (SSG) if:

Your content changes on a predictable schedule. Blog posts, landing pages, documentation, portfolios. You publish once or twice a day, not every minute.

You have fewer than 100,000 pages. If you're a SaaS company with 50 marketing pages, SSG is perfect.

You want to minimize server costs. SSG runs on a CDN. No server. No compute. Just static files.

You need global performance. A CDN serves your pages from the nearest edge location to every user. TTFB is sub-100ms worldwide.

You're building a next.js site and want to use the generateStaticParams function or getStaticProps. These are first-class citizens in Next.js. They're optimized and well-documented.

Use Server-Side Rendering (SSR) if:

Your content changes constantly. Real-time dashboards, live pricing, user-specific content. Every visitor should see different data.

You have millions of pages. User-generated content, e-commerce products, dynamic routes. Building all pages at deploy time is impractical.

Your data is personalized. User accounts, recommendations, shopping carts. You can't pre-render because the page is different for every user.

You need instant updates. A product goes out of stock. A blog post is published. You need it live immediately without a rebuild.

You're willing to pay for server infrastructure. SSR requires a Node.js server or a serverless platform like Vercel or Netlify. There's a cost trade-off for freshness.

Step 1: Audit Your Current Rendering Method

Before you migrate, understand what you're shipping today.

Check if your site is client-side rendered. Open your site in a browser. Press Ctrl+U (or Cmd+U on Mac) to view the page source. If you see a mostly empty HTML file with <div id="root"></div> and a bunch of JavaScript, you're client-side rendering. Google struggles with this.

Check if you're already using SSR or SSG. If you see full HTML with all your content in the page source, you're either using SSR or SSG. You can tell the difference by deploying twice: change your content, deploy, and check if the change is live immediately (SSR) or if you had to trigger a build (SSG).

Measure your current performance. Use Lighthouse for Founders: Running Your First Audit in Chrome to run a baseline audit. Record your Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and First Input Delay (FID). You'll compare these after your migration.

Check your crawl budget. Log into Google Search Console. Go to Settings > Crawl Statistics. How many pages is Google crawling per day? If it's much lower than your total page count, you have a crawl budget problem. SSR or SSG can fix this by making pages crawlable immediately.

Step 2: Choose Your Framework and Rendering Strategy

Your framework determines how easy SSR or SSG is. Let's cover the most common stacks.

Next.js: The Easiest Decision

Next.js supports both SSR and SSG natively. You choose per page.

For SSG in Next.js: Use getStaticProps and getStaticPaths (Pages Router) or generateStaticParams (App Router). This tells Next.js to build the page at deploy time.

export async function generateStaticParams() {
  const posts = await fetch('https://api.example.com/posts').then(res => res.json());
  return posts.map(post => ({ slug: post.slug }));
}

export default function Post({ post }) {
  return <h1>{post.title}</h1>;
}

Next.js builds every page at deploy time. The HTML is cached globally on Vercel's CDN. When a user requests the page, they get the pre-built file.

For SSR in Next.js: Use getServerSideProps (Pages Router) or dynamic routes without generateStaticParams (App Router). This tells Next.js to render the page on every request.

export async function getServerSideProps(context) {
  const data = await fetch(`https://api.example.com/data/${context.params.id}`).then(res => res.json());
  return { props: { data } };
}

export default function Page({ data }) {
  return <h1>{data.title}</h1>;
}

Next.js renders the page on every request. The HTML is sent to the user after your server fetches data and renders.

The hybrid approach: Use Incremental Static Regeneration (ISR). Build pages at deploy time, but regenerate them in the background every N seconds.

export async function getStaticProps() {
  const data = await fetch('https://api.example.com/data').then(res => res.json());
  return {
    props: { data },
    revalidate: 60 // Regenerate every 60 seconds
  };
}

ISR is the sweet spot for many sites. You get the performance of SSG with the freshness of SSR. Pages are cached globally, but they're regenerated in the background so content stays fresh.

For a complete walkthrough of Next.js rendering patterns, see Rendering: Composition Patterns | Next.js. The official documentation covers all three approaches and when to use each.

Nuxt: Vue's Answer

Nuxt also supports SSR and SSG, though the naming is slightly different.

For SSG in Nuxt: Use nuxi generate. This builds your entire site as static files.

npm run generate

Nuxt renders every page and saves the HTML to a dist folder. Deploy that folder to a CDN. Done.

For SSR in Nuxt: Use npm run dev or deploy to a Node.js server. Nuxt renders pages on every request.

Nuxt's SSR is slower than Next.js because it's less optimized for serverless platforms. If you choose SSR with Nuxt, you'll likely need a dedicated server, which increases cost.

Other Frameworks

Remix: Supports SSR natively. Every route is rendered on the server by default. You can add caching headers to make pages static-like, but true SSG requires a separate build step.

SvelteKit: Supports both SSR and SSG. Use export const prerender = true for SSG or leave it off for SSR.

Astro: Defaults to SSG. Every page is built at deploy time. You can enable SSR per route with export const prerender = false.

Gatsby: Built for SSG. Generates static pages at build time. You can add SSR with server functions, but it's not the default.

Pick the framework that matches your rendering strategy. If you need SSG, Astro or Gatsby are optimized for it. If you need SSR, Next.js or Remix are better choices.

Step 3: Implement Server-Side Rendering

If you chose SSR, here's how to implement it.

Step 3.1: Set up a Node.js server or serverless platform.

SSR requires a server that can execute code on every request. You have three options:

1. Vercel or Netlify. Deploy your Next.js or Nuxt app to Vercel or Netlify. They handle SSR automatically. You pay per request or per compute time.
2. A dedicated server. Rent a server from AWS, DigitalOcean, or Linode. Install Node.js and run your app. You pay a fixed monthly cost regardless of traffic.
3. Docker + a container platform. Build a Docker image of your app and deploy to AWS ECS, Google Cloud Run, or Heroku. You pay for compute time.

For most founders, Vercel is the easiest. It's optimized for Next.js, handles SSL, CDN, and serverless functions out of the box.

Step 3.2: Configure your rendering strategy.

In Next.js, use getServerSideProps:

export async function getServerSideProps(context) {
  const { id } = context.params;
  const res = await fetch(`https://api.example.com/posts/${id}`);
  const post = await res.json();

  if (!post) {
    return { notFound: true };
  }

  return {
    props: { post },
    revalidate: 60 // Cache for 60 seconds
  };
}

Every request to this page will fetch fresh data from your API and render the page on the server.

Step 3.3: Add caching headers.

SSR doesn't mean no caching. Add HTTP caching headers to reduce server load:

export async function getServerSideProps(context) {
  context.res.setHeader(
    'Cache-Control',
    'public, s-maxage=60, stale-while-revalidate=120'
  );
  // ... fetch data and return props
}

This tells the CDN to cache the page for 60 seconds and serve a stale version for up to 2 minutes while revalidating in the background. It reduces server hits while keeping content relatively fresh.

Step 3.4: Test rendering.

Deploy your changes and check the page source. You should see full HTML with all your content. No empty divs. No "loading" states.

Step 4: Implement Static Site Generation

If you chose SSG, here's how to implement it.

Step 4.1: Set up your build process.

In Next.js, use generateStaticParams:

export async function generateStaticParams() {
  const posts = await fetch('https://api.example.com/posts').then(res => res.json());
  return posts.map(post => ({ slug: post.slug }));
}

export default function Post({ params }) {
  return <h1>{params.slug}</h1>;
}

When you run npm run build, Next.js fetches all posts and pre-renders a page for each one. The HTML files are saved to .next/static.

Step 4.2: Deploy to a CDN.

SSG sites are just static files. Deploy to:

1. Vercel. Upload your out folder or let Vercel handle the build.
2. Netlify. Connect your GitHub repo and Netlify builds and deploys automatically.
3. AWS S3 + CloudFront. Upload your static files to S3 and serve through CloudFront for global caching.
4. Cloudflare Pages. Push to GitHub and Cloudflare builds and deploys automatically.

For most founders, Vercel or Netlify are easiest. They handle builds, deploys, and CDN distribution automatically.

Step 4.3: Set up automatic rebuilds.

When your content changes, you need to rebuild the site. You have two options:

1. Webhook-triggered rebuilds. When you publish a blog post, your CMS sends a webhook to Vercel or Netlify, triggering a rebuild.
2. Scheduled rebuilds. Rebuild every hour or every day on a schedule.

For a blog, a daily rebuild is usually enough. For a SaaS dashboard, SSG doesn't work (use SSR instead).

Step 4.4: Use Incremental Static Regeneration (ISR) for hybrid performance.

If some pages change frequently and others don't, use ISR:

export async function generateStaticParams() {
  const posts = await fetch('https://api.example.com/posts').then(res => res.json());
  return posts.map(post => ({ slug: post.slug }));
}

export async function getStaticProps({ params }) {
  const post = await fetch(`https://api.example.com/posts/${params.slug}`).then(res => res.json());
  return {
    props: { post },
    revalidate: 3600 // Regenerate every hour
  };
}

Pages are pre-built at deploy time, but they're regenerated in the background every hour. Users see fresh content, and your build stays fast.

Step 4.5: Test the build.

Run npm run build locally. Check that all pages are generated. Look for build errors. If a page fails to build, the entire deploy might fail.

Step 5: Optimize for SEO After Migration

Once you've migrated to SSR or SSG, you're not done. You need to optimize the rendering for search engines.

Step 5.1: Verify Google can crawl your content.

Submit your sitemap to Google Search Console. In Next.js, generate a sitemap with:

// app/sitemap.ts
export default function sitemap() {
  return [
    {
      url: 'https://example.com',
      lastModified: new Date(),
      changeFrequency: 'yearly',
      priority: 1,
    },
    {
      url: 'https://example.com/about',
      lastModified: new Date(),
      changeFrequency: 'monthly',
      priority: 0.8,
    },
  ];
}

For a complete walkthrough, see How to Generate a Sitemap.xml for Your Site (Every Stack Covered). It covers Next.js, Webflow, Shopify, and other stacks.

Step 5.2: Add robots.txt and crawl directives.

Create a public/robots.txt file:

User-agent: *
Allow: /
Disallow: /admin
Disallow: /api

Sitemap: https://example.com/sitemap.xml

For detailed guidance, see Writing Your First robots.txt File: A Founder's Template.

Step 5.3: Use noindex and nofollow strategically.

If you have pages you don't want Google to index (admin pages, duplicate content), use noindex:

// pages/admin.js
export default function Admin() {
  return (
    <>
      <Head>
        <meta name="robots" content="noindex" />
      </Head>
      {/* Admin content */}
    </>
  );
}

For decision rules, see When to Use noindex vs. robots.txt — A Decision Tree.

Step 5.4: Ensure Core Web Vitals pass.

After migration, run Lighthouse again. Your LCP, CLS, and FID should improve. If they don't, you have a rendering problem or a performance problem.

Use Setting Up Cloudflare for SEO: The Free Speed Boost to add a free CDN layer. Cloudflare caches your pages and serves them from edge locations worldwide.

Step 5.5: Monitor indexing in Google Search Console.

After migration, check Google Search Console daily for the first week. You should see your pages being crawled and indexed. If you see crawl errors or indexing issues, fix them immediately.

Comparing Performance: SSR vs. SSG in the Real World

Let's compare the two approaches head-to-head using real metrics.

Response Time (TTFB)

SSG: 50-200ms globally. Your CDN serves pre-built HTML from the nearest edge location. No server computation. Blazing fast.

SSR: 200-1000ms globally. Your server fetches data, renders the page, and sends HTML. Slower, but still acceptable if your data fetches are fast.

If you have slow API calls (>500ms), SSR's TTFB will suffer. Optimize your API or cache responses to improve SSR performance.

Build Time

SSG: 1-10 minutes for most sites. If you have millions of pages, builds can take hours. Incremental Static Regeneration helps by only rebuilding changed pages.

SSR: 0 seconds. No build time. You deploy and it works immediately.

Cost

SSG: Free to $50/month. You're just serving static files. CDNs like Vercel, Netlify, and Cloudflare Pages are cheap or free.

SSR: $20-500+/month. You're paying for compute time. Vercel charges per request. A dedicated server costs $20-100/month. At scale, SSR gets expensive.

Freshness

SSG: Requires a rebuild to update content. If you publish a blog post, you trigger a build and wait for deployment. Typically 2-5 minutes from publish to live.

SSR: Instant. Update your database and the change is live immediately. No rebuild. No deploy.

Scalability

SSG: Scales to any traffic volume. You're serving static files. A CDN can handle millions of requests per second.

SSR: Scales with server capacity. More traffic = more server cost. You need to add more servers or serverless instances.

The Hybrid Approach: When Both Make Sense

Many successful sites use both. Static pages for marketing content (fast, cheap, SEO-friendly) and SSR for dynamic content (personalized, real-time).

Example: A SaaS company might use:

• SSG for marketing pages: Home, pricing, docs, blog. These pages change infrequently. Build them once, cache globally, serve from CDN.
• SSR for the app: Dashboard, user settings, real-time data. These pages are personalized and change constantly. Render on demand.

This hybrid approach gives you the best of both worlds: fast, cacheable marketing pages and dynamic, personalized app pages.

To implement this in Next.js, use generateStaticParams for marketing pages and getServerSideProps for app pages. Vercel handles both automatically.

Decision Framework: The Final Checklist

Here's a simple checklist to make your final decision:

Choose SSG if:

• Your content changes on a schedule (daily, weekly, or monthly)
• You have fewer than 100,000 pages
• You want minimal server costs
• You need global performance
• Your pages are not personalized
• You're using Next.js, Astro, or Gatsby

Choose SSR if:

• Your content changes constantly (minute-by-minute or in real-time)
• You have millions of pages or user-generated content
• You need instant updates without rebuilds
• Your pages are personalized per user
• You're using Next.js, Nuxt, or Remix
• You're willing to pay for server infrastructure

Choose Hybrid (SSG + SSR) if:

• You have both static pages (marketing) and dynamic pages (app)
• You want to optimize cost and performance
• You're using Next.js with Incremental Static Regeneration

Common Mistakes to Avoid

Mistake 1: Assuming SSR is always better for SEO.

SSR and SSG both rank. The search engine sees HTML either way. The difference is performance and cost, not SEO. Choose based on your content freshness and scale, not SEO myths.

Mistake 2: Building all pages with SSG when you have millions.

If you have 1 million pages, building all of them at deploy time takes hours. Use Incremental Static Regeneration or SSR instead.

Mistake 3: Using SSR when SSG would be faster and cheaper.

If your content is static, SSG is objectively better. Faster performance, lower cost, simpler infrastructure. Don't overcomplicate it.

Mistake 4: Forgetting to set up monitoring.

After migration, monitor your site's performance and indexing. Use Setting Up Google Analytics 4 for SEO Tracking from Day One to track rendering performance. Check Google Search Console for crawl errors.

Mistake 5: Not testing in production.

Before you migrate all your traffic, test on a staging environment. Deploy your SSR or SSG changes, verify the page source has full HTML, run Lighthouse, and check Core Web Vitals.

Measuring Success After Migration

Once you've migrated, measure the impact:

1. Core Web Vitals. Run Lighthouse before and after. Your LCP, CLS, and FID should improve.

2. Crawl efficiency. Check Google Search Console. Your crawl rate should increase and crawl errors should decrease.

3. Indexing. Count your indexed pages before and after. If you had crawl budget issues, you should see more pages indexed.

4. Rankings. Track your keyword rankings in Google Search Console. You should see improvements within 4-8 weeks as Google re-crawls and re-indexes your pages.

5. Cost. Compare your server or hosting costs before and after. SSG should be cheaper. SSR might be more expensive.

Next Steps: Building on Your Rendering Foundation

Once you've implemented SSR or SSG, you have a solid technical foundation. But rendering is just the first step.

To build a complete SEO strategy, follow SEO Bootcamp for Busy Founders: 14 Days, 14 Wins. You'll learn keyword research, content strategy, link building, and technical SEO in 14 days.

For AI-generated content at scale, see The Busy Founder's Brief Template for AI-Generated Content. You'll create SEO-optimized blog posts in minutes using AI.

If you're shipping a WordPress site, follow Setting Up SEO Plugins on WordPress for First-Time Founders to configure essential SEO plugins.

For a complete technical SEO foundation, use The Free SEO Tool Stack Every Founder Should Set Up Today. You'll set up Google Search Console, Google Analytics 4, Bing Webmaster Tools, and other free tools in hours.

The Bottom Line

Server-side rendering and static site generation both work for SEO. The choice depends on your content freshness, page volume, and budget.

Static generation is faster and cheaper. Use it for marketing sites, blogs, and documentation. Build once, cache globally, serve from CDN.

Server-side rendering is fresher and more dynamic. Use it for real-time dashboards, personalized content, and user-generated content. Render on demand, pay per request.

Hybrid approaches give you the best of both. Use SSG for static pages and SSR for dynamic pages. Optimize cost and performance simultaneously.

Pick the approach that matches your content freshness and scale. Test it. Measure the impact. Ship it.

Your site will rank better, load faster, and cost less. That's the goal.

Quick Reference: SSR vs. SSG Decision Matrix

Use this matrix to make your final decision. When in doubt, start with SSG. It's faster, cheaper, and simpler. You can always migrate to SSR later if you need it.

For comprehensive SEO guidance beyond rendering, explore The Busy Founder's AI Stack for SEO: Three Tools, Zero Bloat. You'll learn the minimal AI and SEO tools you actually need to rank.

Ship it. Measure it. Rank.