SEO migration: replatforming to Next.js without losing traffic

Most traffic disasters aren't caused by Google updates — they're self-inflicted during replatforming. A migration done blind can cost 30–70% of organic traffic, and recovering takes months. Done by the book, the dip is small, brief, and often followed by growth (Next.js usually wins on rendering and speed).

Rule zero: change one variable at a time

The riskiest migrations change platform, URL structure, design and content simultaneously — when traffic drops, nobody can tell which change did it. Sequence it: migrate the platform with URLs and content frozen, verify stability for a few weeks, then evolve design and content on the new stack.

Before: build the inventory

You can't preserve what you haven't measured. Collect, per URL:

• Full crawl of the old site (Screaming Frog or a script over the old sitemap).
• Top pages from Search Console (12 months of clicks) and top conversion pages from analytics — these get manual attention.
• Most-linked pages (GSC → Links, or Ahrefs) — losing a redirect on a page with 200 referring domains burns years of authority.
• Current titles, descriptions, canonicals, hreflang, structured data — the parity baseline.

The redirect map is the migration

If URLs change at all, every old URL gets a one-hop 308/301 to its precise new equivalent — not to the homepage (Google treats mass homepage redirects as soft 404s):

// next.config.mjs — pattern rules first, explicit map for the exceptions
async redirects() {
  return [
    { source: "/shop/:category/:slug", destination: "/products/:slug", permanent: true },
    ...explicitMap.map(({ from, to }) => ({ source: from, destination: to, permanent: true })),
  ];
}

Chains are forbidden: if the old site already had redirects, point their sources straight at the final URLs too. Everything about status codes from the redirects topic applies doubly here.

Staging: parity checks, not vibes

• Keep staging out of the index: HTTP auth is safest (a stray noindex config has shipped to production more than once).
• Diff old vs new for your top pages with a script: title, description, canonical, hreflang, H1, JSON-LD, status code. Rendering parity too — curl the staging HTML and confirm the content is server-rendered.
• Test the redirect map against the full old URL inventory before launch, not a sample.

Launch day and the weeks after

• Submit the new sitemap in Search Console; keep serving redirects for old URLs indefinitely (years, not weeks).
• Watch server logs for 404s from Googlebot — every one is a hole in the redirect map; fix daily in week one.
• Expect a crawl spike and position wobble for 2–6 weeks — that's Google re-evaluating; don't panic-revert.
• Alert thresholds: sustained drop >20% on money pages after week three deserves investigation (monitoring setup), not hope.

Checklist:

• URL inventory with GSC top pages and most-linked pages flagged
• One-hop redirect map covering 100% of old URLs, tested pre-launch
• Staging behind auth; metadata/schema/rendering parity diffed per top page
• Platform migrated with URLs and content frozen; design changes come later
• Post-launch: daily Googlebot-404 review, redirects kept for years