Technical SEO Launch Criteria for a Next.js Migration

Hero image for Technical SEO Launch Criteria for a Next.js Migration. Image by ian dooley.
Hero image for 'Technical SEO Launch Criteria for a Next.js Migration.' Image by ian dooley.

In Brief

A Next.js migration should not be treated as launchready just because it deploys. Routes, redirects, canonicals, metadata, rendered HTML, schema, sitemaps, robots rules, internal links, and performance all need to be checked before search risk is low.

A Next.js migration is not ready to launch because the app builds.

It is not ready because the homepage looks right. It is not ready because the old CMS content appears somewhere on the new site. It is ready when the new platform can be released without throwing away search equity, route intent, rendered meaning, and discovery signals.

Technical SEO launch criteria turn that judgement into a checklist. They do not remove risk, but they stop the team discovering obvious migration damage after the release.


URL Estate Accounted for

Every important old URL needs a decision.

Classify URLs as:

  • retained
  • redirected to direct equivalent
  • redirected to closest useful replacement
  • intentionally removed
  • blocked or noindexed
  • out of scope with a named owner

Use more than the old sitemap. Include Search Console landing pages, analytics landing pages, crawl exports, campaign URLs, backlinks where available, and known legacy routes.

Google's site move guidance is a useful baseline here, but it still needs turning into a routebyroute launch checklist for the actual platform.

The launch should not contain mystery URLs. If a highvalue old URL returns 404 after release, that should be because someone made a deliberate decision, not because nobody knew it existed.


Redirects Tested as User Journeys

Redirect maps are often tested like spreadsheets. Users and crawlers experience them as journeys.

Check:

  • old URL returns expected status
  • permanent redirects use permanent status
  • no avoidable chains
  • no redirect loops
  • destination matches intent
  • query handling is deliberate
  • trailing slash behaviour is consistent
  • HTTP to HTTPS works
  • old sitemap URLs are handled

Do not redirect everything to the homepage. That may reduce 404 counts, but it destroys intent.


Rendered HTML Compared by Template

For each important template, compare old and new rendered output.

Check:

  • title
  • meta description
  • canonical
  • robots directives
  • h1 and heading hierarchy
  • primary body copy
  • internal links
  • images and alt text
  • structured data
  • breadcrumbs
  • pagination

The detailed method is covered in how to compare rendered HTML before and after a migration. The launch criterion is simpler: important templates should not lose meaning, structure, or crawl paths.


Metadata and Canonicals Production‑Safe

Before launch, verify:

  • canonical host is production
  • preview and staging hosts are not present
  • meta titles are routespecific
  • descriptions are not duplicated across templates
  • no production noindex is present by accident
  • Open Graph URLs and images are valid
  • pagination and alternate language tags are correct where used

This is especially important when moving from React SPA, Gatsby, WordPress, or another CMSled platform. Metadata often changes ownership during migration, and ownership gaps create regressions.


Sitemaps and Robots Aligned with the Route Set

The sitemap should include canonical, indexable public URLs.

Check:

  • all priority routes included
  • old retired URLs excluded
  • private routes excluded
  • no preview URLs
  • no redirecting URLs
  • no noindexed URLs
  • sitemap host is production
  • robots.txt links to the correct sitemap
  • robots rules do not block important routes or assets

For a deeper runbook, see Next.js sitemap, robots and crawlability debugging.


Structured Data Matches Visible Content

Do not copy old schema blindly.

Validate:

  • JSONLD parses
  • schema types fit the page
  • breadcrumbs match page hierarchy
  • article dates are correct
  • service schema matches visible service copy
  • product schema matches visible products
  • FAQ schema appears only where FAQs are visible
  • URLs are canonical

Structured data is a launch criterion because it often exposes content model drift. If schema still describes the old site, the migration is not finished.


Check crawl paths from:

  • homepage
  • navigation
  • category pages
  • article bodies
  • related articles
  • service pages
  • case studies
  • footer
  • breadcrumbs
  • pagination

Migration projects often recreate pages but weaken the links between them. That can reduce discovery, topical clustering, and user journeys.

If service pages are part of the strategy, articles should link to relevant services and service pages should link to supporting articles. That is not sales filler. It is how the site explains its own expertise.


Performance and Accessibility Smoke Checks Passed

Technical SEO does not stop at metadata.

Check:

  • Core Web Vitals risk by template
  • no severe layout shift
  • images have dimensions
  • important content is not hidden behind broken hydration
  • page landmarks are coherent
  • links have meaningful text
  • forms and CTAs are usable
  • JavaScript errors are not blocking content

You do not need perfect scores to launch. You do need to know whether the migration has introduced obvious technical regressions.


Recovery Evidence Prepared

Before launch, prepare:

  • old route export
  • new route export
  • redirect map
  • crawl report
  • metadata spot checks
  • sitemap output
  • Search Console baseline
  • analytics baseline
  • release timestamp
  • rollback plan

If traffic drops, this evidence saves days. Without it, the team has to reconstruct the launch from memory while everyone is already tense.


Wrapping Up

Technical SEO launch criteria are not bureaucracy. They are migration risk control.

A Next.js migration should improve the platform without losing the route, content, metadata, and discovery signals that made the old site valuable. The checklist makes that explicit before release, when fixes are cheaper and calmer.

If the app builds but the URLs, redirects, canonicals, rendered HTML, schema, sitemaps, and internal links are not ready, the migration is not ready.

Key Takeaways

  • Account for the old URL estate before launch.
  • Test redirects as user and crawler journeys.
  • Compare rendered HTML by template.
  • Verify productionsafe metadata, canonicals, sitemap, and robots output.
  • Validate structured data against visible content.
  • Prepare recovery evidence before release, not after traffic drops.

Need a senior engineer involved?

I can work directly in the codebase, review the architecture, or support the team through delivery when the work needs more than extra hands.