WordPress to Next.js migration without losing a single ranking.

Honestly? Mostly because Lighthouse never quite gets there.

I have spent a lot of mornings explaining to founders why their lovingly-built Elementor site keeps benching at 62 in PageSpeed Insights even after three caching plugins, a CDN, and a fresh hosting move. There is a ceiling. You can prod a classic WordPress front-end into the low 80s if you really care, but every plugin update is a regression risk and every page builder release ships another half-megabyte you did not ask for.

The teams I see migrate fall into three rough buckets, and they almost never overlap.

The performance bucket

A Series-A SaaS marketing site, currently on WP Engine, paying for Elementor Pro plus three add-on packs. Lighthouse 64 on mobile. INP at 380 ms. They have a content team that ships two posts a week and an engineering team that wants to ship onboarding flows, not WordPress patches. The Next.js rebuild gets them to 96, and the engineers stop touching wp-admin.

The engineering bucket

Three TypeScript engineers. One of them is on call for the marketing site. They open wp-admin once a fortnight and curse. The whole "is this PHP 7.4 or 8.1, what version of WooCommerce did the agency leave us on" routine is a tax on people who would happily ship in Astro for half the agitation. Migrate, give them a Next.js or Astro repo with proper CI, and the on-call rotation gets smaller.

The security bucket

Less common, more decisive. A board-level mandate that public-facing surfaces should not be running PHP. Or a security incident that shipped a patched plugin three weeks late. Headless WordPress on a non-public origin satisfies the policy without forcing the editorial team to learn a new CMS. The wp.example.com goes private; the front-end is just a static site on Vercel. Most pen tests stop being interesting.

Three. Genuinely three, not the marketing-page kind that all collapse into the same scope. Each one suits a different team.

Path 1 — keep WordPress, replace the front-end

Headless. WP stays as the editor surface. Yoast keeps doing its thing in the admin. ACF keeps doing its thing in the admin. The public site gets rebuilt in Next.js or Astro and pulls content over WPGraphQL. Editors barely notice the migration day apart from the URL bar showing the new front-end domain. This is the most common path I scope; about two thirds of recent migrations have gone this way.

When it is right: editorial team is happy in WordPress, the engineering issue is purely front-end, and you do not want to migrate twelve thousand pages of Yoast metadata.

Path 2 — leave WordPress entirely

Migrate everything to Sanity, Payload, Storyblok, or Contentful. Shut down WordPress on launch. Newer codebase, cleaner content model, no PHP anywhere. The migration cost is higher because you are moving content, not just rebuilding the front-end. Worth it when the editorial team specifically wants out of WordPress, or when the content model needs more rigour than ACF flexible content can give you.

When it is right: you actually want a different CMS, not just a different front-end.

Path 3 — hybrid

Some content stays in WordPress, some moves elsewhere. Real example pattern: blog stays in WP because the editorial team is mature and Yoast is doing real work; product pages move to Payload because the schema needs proper relations and validation. Front-end is one Next.js app reading from both backends. More architecture but sometimes it is the right answer.

When it is right: two genuinely different content shapes on the same site, and forcing them into one CMS is making someone's life worse.

This is where migrations live or die, and it is also the bit teams routinely skimp on. Without a complete map you lose rankings on day one. With a partial map you lose them slowly over six weeks while you tell yourself the dip is just seasonality.

The map gets built from three independent sources before any code ships.

1. Search Console export — every URL Google has crawled and considered indexable in the last 16 months. This is the canonical list of what Google currently expects to find at your domain.
2. Ahrefs or Semrush export — every URL with at least one referring domain pointing at it, sorted by referring-domain count. These are the URLs where 301 preservation matters most. If you 404 a page with 200 backlinks, you have just thrown away 200 backlinks.
3. WordPress sitemap — your current XML sitemap export. Catches pages that may not have backlinks or organic traffic but are still in the structure. Useful as a third pass to find anything the first two missed.

Three lists, deduped, mapped to new URLs, shipped as 301s in vercel.json or netlify.toml at the edge. Not 302s. Not JavaScript-driven redirects. Not a meta refresh. URLs that are genuinely retired get 410. URLs that have changed slug get 301. The build linter fails the deploy if any pre-migration URL is missing from the map.

I have watched a 5,000-page migration lose 60% of its organic in eight weeks because the redirect map was 87% complete and "the rest are not worth worrying about." The 13% were worth worrying about. They always are.

Plugin audit on day one. Every active plugin lands in one of four buckets, and the bucket decides the work.

Stays as is

Plugins that run server-side and never touch the public front-end. WP Migrate DB, BackWPup, server-side analytics, role-management. They keep working because nothing about their job involves rendering HTML to a visitor. About 20-25% of the plugin count usually falls here.

Replaced by code

Plugins that inject HTML or JavaScript into the front-end. Most SEO plugins (the metadata transports, the front-end output is custom). Most form plugins (replaced by Next.js endpoints or by ConvertKit / HubSpot / Mailchimp). Most schema plugins (replaced by hand-written templates that emit cleaner JSON-LD anyway). Cookie banners get rewritten in TypeScript. About 30-40% of the plugin count.

Replaced by service

Plugins that wrap a third-party. The HubSpot embed plugin becomes a HubSpot Forms API call. The Stripe payment plugin becomes Stripe Elements. Zapier and Make stay where they are because they live outside WordPress anyway. About 10-15% of the count.

Cut entirely

Plugins that exist purely because the WordPress front-end needed them. Caching plugins (Vercel handles this). Most security plugins (the public attack surface is gone). Performance optimisation plugins (build-time concern now). And the always-amusing "I have no idea why this is here, it has been deactivated for two years but we never deleted it" group. Plugin counts on the WordPress side typically drop 70-80% post-migration. That is part of the win.

Preview and drafts

Editors hit Preview in wp-admin. WordPress mints a JWT preview token. The Next.js front-end reads the token, fetches the draft via WPGraphQL bypassing the static cache, and renders. Draft URLs are signed, never indexable, never cached publicly. The one-click preview UX stays exactly as it was. Most editors never notice the migration day on the editorial side.

Comments, revisions, roles

Untouched on the back-end. Comments on posts can stay WordPress-native and render headless via WPGraphQL, or get replaced with Disqus / Giscus / a custom system if your team wanted that anyway. Revisions are unchanged — every post still has its full history accessible from the WordPress editor. User roles, permissions, multi-author setups, all preserved.

Yoast and Rank Math

Both transport. Yoast SEO for WPGraphQL exposes every field — focus keyword, meta title, meta description, canonical, OG, Twitter card, schema breadcrumb — as queryable GraphQL. Rank Math has the equivalent. The Next.js layout reads the typed response and renders meta tags identical to what Yoast or Rank Math would have output on classic WordPress. Editors keep editing in the same plugin UI; the migration is invisible from their side.

Week 1: discovery and scoping

Plugin audit. Content audit. Search Console + Ahrefs export for the redirect map source. Current performance baseline. Decision on path one versus two versus hybrid. Output: written SOW with a fixed price and a milestone payment schedule. By end of week one you know exactly what you are paying for.

Weeks 2-4: foundation

Repos in your GitHub, not ours. Hosting in your accounts. WPGraphQL (or new CMS) configured. Next.js or Astro scaffolding shipped. SEO linter and redirect-map ingestion plumbed. Design tokens migrated. By the end of week four the foundation is real and the team is shipping pages.

Weeks 5-10: build

Templates ported, page-by-page. Daily Looms from the lead engineer in your Slack. Weekly mid-build review call. Tickets in Linear or Jira or whatever you already use. Edge cases caught as they surface. This is the boring middle of the project where most of the actual code gets written.

Weeks 10-12: pre-launch QA

Manual cross-browser. Mobile audit. Accessibility audit at WCAG AA. Real-device Core Web Vitals (not lab Lighthouse). SEO linter green. Schema validator green. Redirect map verified URL-by-URL against Search Console export. The cutover plan written and rehearsed.

Week 12: launch

DNS cutover at a window you choose. Most go on a Tuesday or Wednesday morning, low-traffic. Front-end is already running on a staging domain; the cutover is a DNS flip. Engineering on standby for 24 hours. Search Console submitted with the new sitemap. Ahrefs and GA annotated.

Weeks 12-16: hyper-care

Daily Search Console monitoring for index anomalies, redirect chain warnings, schema errors. Weekly traffic comparison against baseline. Bug fixes prioritised over features. By week 16 the site is stable and we either hand off cleanly or move into an ongoing care plan.