---
type: Migration Guide
title: "SSR to SSG migration on Next.js"
description: "Move from server-rendered Next.js to fully static generation without losing SEO equity, with sane fallbacks for content that still needs freshness."
resource: "https://prerendering.com/migrations/ssr-to-ssg-nextjs"
tags: [migration, moderate]
timestamp: 2026-05-11T00:00:00Z
---

# SSR to SSG migration on Next.js

Move from server-rendered Next.js to fully static generation without losing SEO equity, with sane fallbacks for content that still needs freshness.

A guide for Next.js teams whose SSR is overkill for the route shape — content rarely changes, the user-facing data is largely static, and SSR is paying for freshness the site does not need. The migration removes the SSR origin from the critical rendering path while preserving canonical URLs, sitemap structure, and indexation status.

- Difficulty: Moderate
- Typical duration: 2 to 4 weeks

## Preflight

- Inventory routes by rendering model: which are truly dynamic per request, which are mostly static.
- Confirm that data fetching can move to build time (or ISR) without losing freshness SLAs.
- Audit current canonical and metadata generation — verify they work in static context.
- Snapshot Search Console "Page indexing" report as the migration baseline.
- Plan ISR for routes that are mostly static but need refresh windows shorter than rebuild cadence.

## Steps

- **Migrate top 5 templates to generateStaticParams** — Start with the highest-traffic, lowest-volatility route templates. Convert one template at a time, verify static output matches SSR output for a sample of URLs.
- **Wire ISR fallback for high-volume templates** — For category or product pages with 10k+ URLs, use ISR with an appropriate TTL (typically 60-3600 seconds) instead of forcing build-time generation.
- **Verify canonical and structured-data parity** — Run curl against 50+ representative URLs in both SSR (current) and SSG (target) modes. Diff the canonical, OG tags, and JSON-LD output. They must match.
- **Update sitemap generation to read from static manifest** — If sitemap was generated dynamically from the SSR origin, port it to read from generateStaticParams output. Verify all post-migration URLs are present.
- **Stage on a preview deployment** — Deploy SSG version to a Vercel preview or staging subdomain. Submit a small subset to Search Console URL Inspection. Confirm crawler-facing HTML matches SSR baseline.
- **Cutover with monitoring** — Deploy to production. Monitor first 24-48 hours for Search Console errors, crawl-rate changes, and 404 spikes from any URL drift.

## Rollback

- Vercel Instant Rollback to previous deployment is the fastest revert path.
- If routing logic was changed alongside, prepare a feature flag that toggles back to SSR per-template instead of full-site revert.
- Keep the SSR codebase deployable for 30 days post-migration in case a deeper issue surfaces.

## Monitoring

- Search Console Page indexing report — daily for 14 days, weekly for 60 days after.
- Crawl-rate trend in Search Console settings — flag any 30%+ drop within a week.
- Sitemap submission status — confirm new sitemap is being read.
- Server logs (or CDN edge logs) for unexpected 404 spikes on previously-SSR URLs.
- Core Web Vitals field data via CrUX — expect LCP improvement, watch for any regression.

## Metrics

- Expected downtime: < 5 min (instant rollback)
- Typical rollback time: < 2 min
- Time to first verified indexation: 7-14 days
- Typical TTFB improvement: 200-800 ms → 30-100 ms

## Related

- [Prerendering vs SSR vs SSG: 2026 Decision Guide](/blog/prerendering-vs-ssr-vs-ssg-decision-guide.md)
- [Next.js Rendering Decisions for SEO and AI Visibility](/blog/nextjs-rendering-decisions-for-seo-and-ai-visibility.md)