Moving a WordPress site to Next.js can make it faster and easier to evolve. Done badly, it can also wipe out years of search rankings in a week. The technology rarely causes that. Missing redirects, changed URLs, lost metadata and a forgotten sitemap do. This guide is the plan I follow to migrate WordPress to Next.js without losing SEO, written for business owners and the developers they hire.

If you are still deciding whether to move at all, read Next.js vs WordPress for a business website first. If you have decided, my React and Next.js development service covers builds like this.

Principle: keep everything Google already knows#

Search engines have learned your URLs, titles, headings, links and content. A migration is safe when, after launch, the same URLs return the same content (or a clean redirect to its new home), with the same metadata and a fast, crawlable page. Everything below serves that principle.

Step 1: Take a full inventory before touching code#

Build a spreadsheet of what exists now:

  • Every indexed URL: crawl the site and export URLs from your sitemap, analytics and Google Search Console.
  • For each URL: title, meta description, H1, canonical, status code, internal links in, organic traffic and impressions.
  • Rankings for your key pages and queries.
  • Structured data, redirects already in place, and any special files like robots.txt, ads.txt or verification files.

Save a copy of this baseline. It is how you will prove, a month later, whether the migration worked.

Step 2: Decide the URL strategy#

The safest approach is to keep URLs identical. WordPress commonly uses paths like /blog/post-name/ with a trailing slash, category archives and pagination. Next.js can reproduce these through its routing and configuration (for example, the trailingSlash option and dynamic routes).

If a URL must change, give every old URL a one-to-one 301 redirect to its new equivalent. Avoid redirecting everything to the home page, which Google treats as a soft 404. Avoid chains: old to new in a single hop.

Step 3: Choose how content is managed#

You rarely want to hand-code content into React. Options:

  • Headless WordPress: keep WordPress as the editor and fetch content through its API into Next.js. The editing experience stays familiar.
  • A headless CMS such as Strapi or Contentful, with content migrated across.
  • Markdown or MDX files in the repository, which suit developer-run blogs.

On the Nooora Beauty Concierge site, I joined a project where some sections came from Strapi and others were hard-coded, and client content changes required a developer. The work was moving major content areas into Strapi, adding dynamic service pages and building SEO and sitemap support, so the client could update content themselves on a platform that depends on search visibility. The lesson applies to any migration: decide who edits content and make the CMS support that person.

Step 4: Recreate on-page SEO exactly#

For every page, carry over:

  • Title tags and meta descriptions. In the Next.js App Router, use the Metadata API (generateMetadata) to render them server-side.
  • Canonical URLs that point to the preferred version.
  • Heading structure, especially H1.
  • Open Graph and social tags.
  • Image alt text and sensible dimensions.
  • Structured data (JSON-LD) for articles, products, organisation and breadcrumbs.
  • Internal links, with the same anchors where possible.

The Next.js docs on metadata explain the API. Plugins like Yoast or Rank Math store this data in WordPress, so export it rather than rewriting it by hand.

🛠 Engineering Service

Need specialized help with React & Next.js Development?

Build fast, responsive React and Next.js applications with modern TypeScript architecture, API integrations, reusable components, and production-ready frontend experiences.

Discuss Architecture →About this service

Step 5: Render pages so crawlers can read them#

Use server rendering or static generation for public pages, not client-only rendering. Google can process JavaScript, but delivering complete HTML in the first response is faster and more reliable. Next.js does this by default for Server Components. Check the page source after building, not just what you see in the browser.

Use incremental static regeneration or on-demand revalidation so new posts appear without a full rebuild.

Step 6: Build redirects, sitemap and robots#

  • Redirects: define them in next.config.js or middleware. For large lists, load them from a file or a database table, and test every one.
  • Sitemap: generate sitemap.xml from your content source and include only canonical, indexable URLs. Submit it in Search Console.
  • robots.txt: make sure you do not accidentally carry over a staging "disallow all" rule. This is one of the most common launch mistakes.
  • Trailing slash and case rules: pick one version and redirect the other.

Step 7: Check performance and Core Web Vitals#

Speed is one of the reasons to migrate, so confirm it. Use next/image for responsive images, load fonts efficiently and avoid shipping heavy client-side JavaScript on content pages. Measure with PageSpeed Insights before and after. A migration that is slower than the original is a failed migration.

Step 8: Test on staging, thoroughly#

Block staging from search engines with authentication, not just a noindex tag that might ship to production. Then:

  1. Crawl staging and compare URLs, titles, canonicals and status codes to your baseline.
  2. Test every redirect from the old URL list.
  3. Validate structured data.
  4. Check forms, search, comments and any plugin-powered features you must replace.

I took a similar approach in rebuilding Tattoo Panda from WordPress to plain PHP with Contentful, where every page was checked against the original. The method is the same whichever stack you move to: compare the new site to the old one page by page.

Step 9: Launch with care#

  • Choose a low-traffic window and avoid launching alongside a redesign of the copy, which makes cause and effect impossible to separate.
  • Keep the old server available briefly, in case you need to compare or roll back.
  • Update DNS, then immediately re-test redirects, robots.txt and the sitemap on the live domain.
  • Submit the sitemap and use Search Console's URL Inspection on key pages.

Step 10: Monitor for 8 to 12 weeks#

Watch:

  • Search Console: Pages report for indexing errors, Performance report for impressions and clicks versus your baseline, and crawl stats.
  • 404s from logs and Search Console, adding redirects for any you missed.
  • Rankings for priority pages.
  • Analytics: traffic, conversions and form submissions.

A small dip in the first weeks is common as Google re-crawls. A sustained drop after a clean migration usually points to a specific problem, such as missing redirects or changed content, and the baseline helps you find it.

⚠️Warning

Do not change domain, URLs, design and content in the same release. Each is a separate risk. Migrate the platform first, change other things afterwards.

When not to migrate#

If your WordPress site is fast, easy to edit and ranking well, a migration adds risk with limited benefit. Consider it when you need custom application features, outgrow what plugins can safely do or have performance problems that cannot be fixed within WordPress. For a broader look at the decision to change a system versus improve it, see rewrite vs refactor.

Frequently asked questions#

Will I lose rankings when I migrate?#

Not if URLs, content and metadata are preserved and redirects are correct. Temporary fluctuation is normal, but a planned migration should return to baseline.

Can I keep using the WordPress editor?#

Yes, with headless WordPress. You trade some plugin features for a faster front end.

How long does a migration take?#

It depends on the number of templates and features, not just the number of pages. A small brochure site can take weeks; a large site with custom features takes longer.

Do I need to keep my old URLs?#

It is the safest approach. If you change them, use one-to-one 301 redirects and monitor.

Key takeaways#

  • Inventory every URL, title and ranking before you start.
  • Keep URLs the same, or map each old URL to its new one with a single 301.
  • Reproduce metadata, canonicals, structured data and sitemaps, and render HTML on the server.
  • Test on a protected staging site, launch carefully and monitor for weeks.

If you are planning a WordPress to Next.js move and want it done without a ranking drop, book a call or contact me.

Originally published at aqibjavaid.site.