WordPress to Next.js migration without losing rankings

Every WordPress to Next.js migration that loses rankings loses them for one of five reasons: URLs changed without 301 redirects, schema dropped during the rebuild, internal linking broke, page metadata regressed, or Core Web Vitals worsened on the new stack.

All five are preventable. We have run dozens of these migrations and the ones that came out clean did the same boring work in the same order. The ones that lost rankings skipped a step.

The work is mostly not code. The code is the easy part. The hard part is the inventory, the redirect map, the schema audit, the metadata diff, and the post-launch monitoring discipline.

We pull the WordPress sitemap.xml and any sitemap index that nests under it. We pull GSC's pages report for the last sixteen months because that is the longest window GSC retains and it captures pages that have intermittent traffic. We pull Bing Webmaster Tools because Bing's index sometimes contains pages Google has dropped and vice versa.

We dedupe across the three sources, then for each URL we tag: HTTP status code today, indexation status (indexed, crawled-not-indexed, discovered-not-indexed, excluded), last-twelve-month organic clicks, last-twelve-month organic impressions, and last-twelve-month conversions where the analytics layer supports attribution.

Now we have the source of truth. Every URL on this list either gets the same URL on the new site, gets a 301 redirect to a clearly equivalent URL, or gets explicitly retired with documentation of why. Nothing falls through the cracks.

The cleanest migration is the one where the URL structure does not change. /about stays at /about. /services/web-design stays at /services/web-design. Every blog post keeps its existing slug. The Next.js app router maps to the same path structure as the WordPress permalinks did.

When URL changes are unavoidable, every changed URL gets a 301 redirect from the old path to the new path. We implement these in the Next.js middleware or in vercel.json with the redirects array. We test every redirect with curl before launch, then again after launch from a clean cache.

Common WordPress patterns that need attention: /?p=123 query string permalinks (preserve as 301 to the canonical slug), /category/ archive pages (preserve or 301 to a relevant landing page), /tag/ archive pages (usually safe to 410, they rarely have organic value), /author/ archive pages (preserve or 301 to a team page), date-based archives (usually safe to 410).

WordPress sites accumulate schema in unexpected places. Yoast injects Organization, Person, BreadcrumbList, and WebPage schema. Rank Math does similar. Theme files add Article schema. Plugins inject Product, Recipe, Event, FAQPage. Custom code adds whatever was added.

Before launch we run the existing site through Schema.org validator and the Google Rich Results test for every URL with measurable traffic. We document every schema type, every property, and every value the WordPress site emits. The Next.js rebuild emits the same schema or better, on the same pages. Schema-dts gives us typed JSON-LD generation in the new codebase so the schema is verifiable at build time.

Metadata gets the same treatment. We diff title tags, meta descriptions, canonical URLs, robots directives, OG tags, Twitter cards, and hreflang declarations between the old and new versions of every page. Anything that changed gets justified or reverted.

Two days before cutover, we lower the WordPress DNS TTL to 300 seconds so the swap propagates fast. We deploy the Next.js build to Vercel and run full QA against the preview URL: every page renders, every form submits, every redirect resolves, every schema validates, Lighthouse passes on the LCP-critical pages.

On cutover morning we do the DNS swap. Within the first hour we verify with curl from multiple regions, submit the new sitemap to Google Search Console and Bing Webmaster Tools, and use the URL Inspection tool to manually request indexing on the highest-traffic pages. We ping IndexNow for Bing and Yandex coverage.

The WordPress instance stays running on a subdomain for at least thirty days. If something breaks badly enough to need rollback, we can swap DNS back in minutes. We have only ever needed it once across many migrations, but the option is cheap insurance.

The first ninety days after a replatform are the danger window. Google needs to recrawl every URL, reverify every canonical, reindex the new structure, and recompute the rankings. Some volatility is expected and normal. The job is to spot the volatility that is not normal.

We monitor four data sources daily for the first thirty days, then weekly for the next sixty: Google Search Console (crawl stats, indexation, performance by page, manual actions), Bing Webmaster Tools (same), the web-vitals RUM stream (LCP, INP, CLS at p75 by page), and a small panel of high-value query rankings tracked through DataForSEO.

Expected pattern: indexation drops slightly in the first two weeks as Google recrawls the new URLs, then recovers and exceeds the baseline by week four. Rankings dip slightly in week one, then recover by week three. Traffic dips in week one, recovers by week three, and exceeds the WordPress baseline by week eight on a clean migration.

If any of these patterns deviate, we investigate immediately. The most common late-emerging issue is a redirect loop or chain that crawled fine on day one but degrades when traffic patterns shift. The second most common is a schema regression that passes the validator but reduces a rich result eligibility.

We migrate to Next.js (currently 16, on the App Router) because it gives us the best possible Core Web Vitals out of the box, Server Components remove entire categories of client-side bloat, the Vercel deployment platform handles caching and edge distribution without configuration, image optimization is built in, and TypeScript gives us a real type system for schema generation via schema-dts.

The honest tradeoff: Next.js has a steeper learning curve than WordPress for non-developers. The CMS layer is whatever you decide it is, headless WordPress, Sanity, Contentful, MDX in the repo, or a custom admin. We size that decision to the client's content velocity and team makeup.

For high-volume editorial sites the headless-WordPress-plus-Next.js pattern often wins because the editorial team keeps their familiar UI and the front end gets the performance and developer-experience benefits.