The WordPress-to-Next.js Migration Path That Doesn't Kill Your SEO

title: "The WordPress-to-Next.js Migration Path That Doesn't Kill Your SEO" slug: wordpress-to-nextjs-migration-path description: "A safe two-week WordPress to Next.js migration that preserves URL structure, schema, redirects, and rankings. Step-by-step from a real Burris & Sons rebuild." pillar: technical-depth author: rj-murray publishedAt: "2026-04-25T00:00:00Z" tags: ["wordpress", "nextjs", "migration", "seo", "technical-depth"] coverImage: /posts/wordpress-to-nextjs-migration-path/cover.png coverAlt: "WordPress to Next.js migration flow" featured: false faq:

• q: "How long does a WordPress to Next.js migration actually take?" a: "For a 12 to 50 page mid-market marketing site, two weeks from kickoff to launch is the realistic window. The Burris and Sons rebuild went 12 pages to 30 pages in 21 days. The Therapy Connections rebuild went 18 days. Anything under two weeks usually means you skipped the URL inventory or the redirect map, and you will pay for it in the first 30 days post-launch."
• q: "Will rankings drop during a WordPress to Next.js migration?" a: "If the URL structure, canonicals, schema, and 301 map are correct, rankings hold or improve inside 30 days. The classic failure mode is changing slugs without 301s, dropping JSON-LD that Google had already indexed, or shipping a site that fails Core Web Vitals on launch. We have run this migration on 20-plus sites with a positive ranking delta on every one we control end to end."
• q: "Can we keep WordPress as a headless CMS instead of fully migrating?" a: "Yes, and it is the right call when the editorial team is committed to Gutenberg and refuses to relearn. Headless WordPress with a Next.js front end gets you Lighthouse 95-plus and Core Web Vitals compliance while keeping the editorial flow intact. We do this for clients with 5-plus contributors writing weekly. Most mid-market marketing sites do not need it. Payload v3 plus MongoDB Atlas is a cleaner ship."
• q: "What is the single biggest mistake teams make in this migration?" a: "Not capturing the URL inventory before they touch the codebase. Every indexed URL on the old site needs a row in a spreadsheet with status code, current canonical, schema type, target URL on the new site, and redirect type. If that spreadsheet does not exist on day one, the migration will leak rankings. It is the cheapest insurance policy in the project."
• q: "When is migrating off WordPress the wrong call?" a: "When the editorial volume is more than one post a day from a non-technical team, when the site is mostly an e-commerce surface that Woo handles cleanly enough, or when the existing WordPress build is already passing Lighthouse 95 with Core Web Vitals green. A site that already performs does not need to be rebuilt. Read the post on when WordPress is still the right answer before you sign anything."

WordPress runs about 43 percent of the web. A meaningful share of that 43 percent is mid-market B2B marketing sites that have outgrown the platform. The CMS is not the problem. The 14 plugins, the page builder, the 6-second LCP, and the Core Web Vitals score under 50 are the problem. The migration is the fix, and the migration is also the most common way to vaporize a year of SEO work.

This is the path we run. It is the same playbook we used on the Burris and Sons rebuild and the Therapy Connections rebuild. It assumes a mid-market marketing site, 10 to 50 pages, with real organic traffic to protect.

tl;dr

A WordPress to Next.js migration is safe when the URL inventory, 301 map, canonical strategy, and JSON-LD schema all ship before the cutover. Two weeks is the realistic window for a 30-page site. Rebuild on Next.js 16, Tailwind v4, Payload v3, and MongoDB Atlas. Hold rankings by mirroring slugs, preserving schema, and watching Search Console daily for 30 days post-launch.

The migration risk every CMO worries about

The fear is real and the fear is rational. Botched WordPress migrations have wiped six-figure organic pipelines inside a quarter. The pattern is always the same. The agency rewrites the site, ships it, and a week later half the pages are returning 404, the schema is gone, and the rankings start sliding.

It happens because most agencies treat the migration as a design project. It is not a design project. It is a redirect-and-schema project that happens to have a new front end attached.

We treat the front end as the smaller half of the work. The Next.js codebase is straightforward. The URL inventory, the canonical mirror, the 301 map, the schema parity check, and the post-launch monitoring plan are the work. If those four things are correct, the migration holds. If any of them are missing, the rankings move.

A marketing site that does not pass Lighthouse 95 on every route is a rebuild, not a redesign. That position is on record across every engagement we run, and it sets the bar that justifies the migration in the first place. See the real Lighthouse delta we measure across six rebuilds for the data behind the claim.

The two-week migration window, day by day

Two weeks is the realistic window for a 10 to 50 page mid-market marketing site with real traffic. Anything shorter usually means a skipped step. Anything longer usually means scope crept into a CRM or a booking system that did not need to ship in the same window.

Days 1 to 2. Inventory and audit. Run a full crawl of the existing WordPress site with Screaming Frog, a Sitebulb crawl, or wp-cli plus a sitemap export. Pull every URL with a 200 response. Pull the XML sitemap. Pull Search Console performance data for the last 16 months and the indexed-pages report. Build the URL inventory spreadsheet. Note canonical, indexed status, current schema, traffic, and ranking keywords per URL.

Days 3 to 4. Architecture and redirect map. Map every old URL to a new URL on the new site. Decide which slugs stay (90 percent should), which slugs change, and which pages get consolidated or retired. Every change writes a row in the 301 map. Build the Next.js 16 scaffold. Set up Payload v3 collections for the long-form pages.

Days 5 to 8. Build. Implement pages, components, and content. Port copy with edits where the old copy was thin. Implement JSON-LD on every template. Configure next.config.js redirects. Stand up a preview deployment on Vercel.

Days 9 to 10. Schema and parity audit. Crawl the preview build. Diff schema, headings, and metadata against the inventory. Fix the diffs. Run Lighthouse on every route. Hit 95-plus on every route or do not ship.

Days 11 to 12. Pre-launch dress rehearsal. Run the full 301 map against staging. Verify every old URL returns a 301 to the right new URL. Validate canonicals. Validate the sitemap. Set up PostHog. Set up the llms.txt file.

Days 13 to 14. Cutover and watch. DNS flip during a low-traffic window. Submit the new sitemap in Search Console. Run a fresh crawl from Google with the URL Inspection tool on the highest-traffic pages. Set up the daily 30-day monitoring dashboard.

That schedule shipped Burris and Sons in 21 days, with a slower tempo because the staff bios needed three review rounds with the family. Therapy Connections shipped in 18 days because the lead clinician was responsive on every page.

URL inventory and the redirect map

The URL inventory is the single document that makes or breaks the migration. Every URL on the old site that has ever been indexed gets a row. Every row carries:

1. Old URL (full path).
2. Old status code (200, 301, 404, 410).
3. Old canonical target.
4. Old schema types present (Article, Service, Person, FAQPage, etc).
5. Last 16 months of clicks and impressions from Search Console.
6. New URL on the rebuild.
7. Redirect type (200 mirror, 301, 410).
8. Notes (consolidations, retirements, slug changes).

Slug preservation is the default. Change slugs only when the old slug is genuinely worse for users (typos, dates that no longer make sense, category prefixes that the new architecture removes). Every slug change writes a 301. The 301 map ships in next.config.js as a redirect array, server-rendered, not a client-side rewrite.

Canonical strategy is just as important. On the new site, every page sets a rel=canonical tag pointing to its own absolute URL. If the page has variants (sort order, filters, UTM noise), the canonical points to the clean version. WordPress sites with Yoast or Rank Math typically have canonicals set already. Mirror them on the new site. Do not silently change them. A canonical change without a 301 is the second most common ranking-loss trigger after slug changes without redirects.

For the slugs that change, the 301 map needs to round-trip in QA before launch. We use a small Node script that hits every old URL on staging behind an x-rebuild-test header, records the chain, and asserts the final URL is the planned new URL with status 200. If any old URL returns 404 or chains through more than one 301, it gets fixed before cutover. Google has been clear in the Search Central documentation on site moves that 301 chains erode link equity. Single hop is the rule.

The XML sitemap on the new site should list only the new URLs. Submit it in Search Console immediately after cutover. Google will discover most redirects from the crawl, but the sitemap submission accelerates indexing and surfaces problems early.

Schema preservation and improvement

WordPress sites with Yoast, Rank Math, or Schema Pro often ship surprisingly complete JSON-LD. The migration is a chance to keep what is there and fix what is wrong, not a chance to start clean and lose the work.

Audit before you migrate. Run every templated page type through the schema.org validator and the Rich Results test in Search Console. Capture every type emitted by the old site. The minimum schema set on the new build is:

• Organization on every page (header or footer level).
• WebSite with SearchAction if the site has a search.
• BreadcrumbList on every page deeper than the homepage.
• Article or BlogPosting on blog detail pages, with author, datePublished, dateModified, image.
• FAQPage on any page with a structured Q and A block.
• Person for staff bios.
• LocalBusiness, Service, or vertical-specific subclasses for trades, medical, professional services.

We hit each of these on the rebuilds we run. Burris and Sons gets HVACBusiness plus Service plus Person for each technician. Therapy Connections gets MedicalBusiness plus MedicalProcedure plus FAQPage plus Person for each clinician. The schema lives in a typed builder per template, validated in tests, rendered as a single application/ld+json script tag.

Do not lose schema. The classic failure mode is rebuilding the site, forgetting that the old Article schema set author.url to a real Person page, and shipping a new build with author as a plain string. Google had been linking author entities. The new schema breaks that linkage. Citations and rich results drop.

Schema is also the biggest single lever for ranking on ChatGPT, Perplexity, Claude, and Gemini. Answer engines lean on structured data more aggressively than classic Google. Migrating off WordPress is the right moment to upgrade schema, not abandon it.

Content parity vs. content rewrite

The default is parity. Every old URL maps to a new URL with content of equal or greater depth. Word counts hold or grow. Headings hold or improve. Internal links survive.

Rewriting is correct in three cases:

1. The old copy is genuinely thin (under 300 words on a money page).
2. The old copy positions the business incorrectly (post-pivot, post-acquisition, post-renaming).
3. The old copy uses AI register that fails the voice profile (the standing AtlasForge ban list applies).

Rewriting is wrong when the old copy ranks. A page that has held position 4 on a high-intent commercial keyword for 18 months does not need to be rewritten. Ship it. Polish the visual layer. Improve the internal links. Leave the copy that earned the rank.

The Burris and Sons site had heritage copy from 1917 that the family had refined over four generations. We did not touch it. Therapy Connections had clinician-reviewed copy that had survived insurer scrutiny. We did not touch it either. We changed the front end and the schema. The words that worked, kept working.

For the pages that do get rewritten, the depth bar is 500 words minimum on commercial pages, real data behind every claim, internal links to the pSEO engine in 2026 and the case study evidence. Thin pages were a Pre-2024 game. They are a deindex risk now.

How Burris and Sons preserved 1917-era heritage copy through migration

Burris and Sons has run HVAC in Chicago since 1917. The pre-rebuild site had 12 pages of static HTML on a custom WordPress theme that was built around 2012, sitting on a host that gave it a 6.4-second LCP and a Core Web Vitals score of 38. Rankings were holding on neighbourhood-level commercial terms despite the speed.

The risk in the migration was the heritage. The family had refined the founder story over generations. Phrases like "the Burris pilot light has been lit since 1917" appear on three pages and in a framed photo on the office wall. The migration could not flatten that voice. It also could not lose any of the eight neighbourhood pages that were quietly ranking on geo-modified commercial intent.

The plan was parity-plus. We mirrored every slug. We rebuilt 12 pages and added 18 new ones, including expanded service trees and four new neighbourhood pages on the same template. We preserved the heritage copy verbatim on the about, story, and family pages. We re-photographed nothing. The family photography from the 1990s and 2000s was an asset, not a liability. We compressed it, served it from next/image, and shipped.

Schema improved on every page. The old site had LocalBusiness. The new site has HVACBusiness plus Service per service line plus Person per technician with tenure and trade-school detail. Rankings held inside the first week on the four highest-traffic neighbourhood terms and improved on the long tail inside 30 days. Lighthouse went from 38 to 98 on every route. Read the full Burris and Sons case study for the before-and-after metrics.

The pattern generalizes. Heritage copy is rarely the problem. The platform is.

How Therapy Connections kept clinical content compliant through migration

Therapy Connections runs acquired brain injury rehabilitation in Kitchener-Waterloo, Ontario. The pre-rebuild site was a single-clinician page that had not kept up with the team's growth to three clinicians. The clinical content had been written and reviewed by the lead clinician, signed off for insurer scrutiny, and was the only thing on the site that was actually working.

The migration brief was strict. Clinical copy could not be paraphrased. Every claim had to keep its existing reference structure. The new site had to add team bios, expanded condition pages, and a real intake flow without disturbing the language that had survived insurer review.

We shipped 35 pages in 18 days. Clinical copy moved verbatim. Headings preserved their hierarchy. We added MedicalBusiness, MedicalProcedure, FAQPage, and Person schema for each of the three clinicians. We wired the intake flow into Resend with a double-opt-in confirmation and PostHog event capture so the clinical team could see funnel conversion without giving up compliance.

The lead clinician read every page before publish. Two pages got minor wording tweaks. The rest shipped as-written. Rankings held on day one, improved on long-tail condition queries inside three weeks, and the intake form converted at a higher rate than the old single-page design. The full Therapy Connections case study covers the schema and the funnel detail.

The lesson is the same as Burris. The migration kept the words that worked.

The 30-day post-launch monitoring plan

The 30 days after cutover is when migrations live or die. Most ranking losses are visible inside the first 14 days. Catch them in the first 7 and the recovery is fast. Catch them in the first 30 and the recovery takes a quarter.

Daily, for the first 14 days:

• Search Console performance report. Compare clicks, impressions, average position by URL against the 14-day baseline before launch.
• Search Console coverage report. Flag any URL that moved from indexed to not indexed.
• Crawl the live site with Screaming Frog. Compare against the day-zero crawl. Flag any URL that returned 200 yesterday and 4xx or 5xx today.
• Vercel analytics or PostHog page views. Flag any URL that lost 50 percent or more of its traffic against the pre-launch baseline.
• Core Web Vitals from the web.dev vitals article. LCP, INP, and CLS on the top 10 URLs. Anything yellow gets fixed inside 24 hours.

Weekly, for the full 30 days:

• Run the mid-market SEO reporting framework. Pillar performance, keyword cohort drift, conversion impact.
• Re-validate JSON-LD on every templated page. Schema parsers occasionally break on edge cases that did not surface in QA.
• Re-run Lighthouse on the top 20 pages. The first cache build hits 100; the second build can drop to 92 if a third-party script slipped in. Catch it.

The standing rule is that any URL down 25 percent or more on clicks against its 14-day baseline gets a same-day investigation. Most of the time the fix is a missing 301, a canonical pointing to the wrong host, or a templating bug that broke an internal link. All three are 30-minute fixes if you catch them early.

Core Web Vitals deserve their own callout. The 2025 update changed the rules, INP replaced FID, and the threshold for "good" tightened. See Core Web Vitals changed in 2025 for the technical detail. Migrating off WordPress is usually the moment a site moves from red to green on all three metrics. Hold that gain.

When migration is wrong

Not every WordPress site should migrate. We turn down two or three of these conversations a quarter. The signals that say stay:

1. Editorial volume is heavy and the team is non-technical. Five contributors writing 10 posts a week in Gutenberg is a real workflow. A custom CMS or even Payload v3 forces a relearning curve. Headless WordPress is a valid middle path.
2. The existing site already passes Lighthouse 95 on every route. A WordPress build with a serious developer behind it can absolutely hit the bar. If it does, the migration is buying nothing.
3. The site is an e-commerce surface that WooCommerce handles. A 200-product store with a working checkout, working inventory, and working email flow is not a marketing site. Migrating it to a custom Next.js plus Stripe build is months of work, not weeks.
4. The team has just rebuilt in the last 18 months. Migrating a freshly-redesigned site burns goodwill internally and does not earn back the cost in rankings.

We wrote the longer version of this argument in why mid-market companies keep getting stuck on WordPress. The short version: WordPress is not the enemy. The 14-plugin Frankenstein build with no maintenance plan is the enemy. Sometimes the right call is to fix the build, not replace it.

The wp-cli docs at wp-cli.org are the right starting point if the call is to stay and harden. Most of what kills a mid-market WordPress site is plugin sprawl and a host that cannot serve images. Both are fixable without a rebuild.

Closing

The WordPress to Next.js migration is a solved problem if you respect the four documents that hold the work together. URL inventory. 301 map. Schema parity. 30-day monitoring plan. Ship those and the rebuild is two weeks of mostly mechanical work with a Lighthouse score that justifies the bill.

The two case studies above are the version we run. Burris and Sons preserved a 1917 voice through a 21-day migration. Therapy Connections kept clinical compliance through an 18-day migration. The Atlas tier (pricing here) is built for exactly this work.

If the WordPress site is sitting under Lighthouse 95 and you are about to spend the next year on paid search to compensate for it, that is the rebuild conversation. See why CMOs should kill paid search budget and the 90-day organic growth plan. The first 48 hours of that conversation is our before-and-after demo. The next 14 days, if you want them, is the migration above.

Reach out from the homepage. The migration starts with the URL inventory, and we run that on day one. Local pages also benefit from the same approach, see our note on geo pages that don't get penalized for the trades and medical templates.

The Next.js documentation on App Router migrations is the canonical reference for the front-end half of the work. Read it before kickoff. The other half lives in the four documents above.

RJ