WordPress to Next.js Migration: The Playbook That Protects Your SEO

To migrate WordPress to Next.js without losing SEO, do five things in order: crawl your live site to capture every URL, build a one-to-one redirect map from old paths to new, copy titles, meta descriptions, and structured data so search engines see the same signals, rebuild the pages in Next.js, then cut over DNS during quiet hours. Skip the redirect map and you lose rankings. Do it well and the launch is boring — which is what you want.

Next.js fixes the speed and control problems WordPress eventually creates. But a migration is where you can quietly lose years of search authority, so the order of operations matters more than the code.

Why migrate from WordPress to Next.js at all?

You migrate when WordPress stops helping and starts taxing you: pages load slowly even after caching plugins, every plugin update is a small gamble, and any real design change needs a developer anyway. Next.js gives you a fast, static-first site, full control of the markup search engines and AI crawlers read, and a clean codebase your team (or an AI coding agent) can change with confidence.

The trade is that Next.js asks you to own more of the stack instead of leaning on a thousand plugins. For a B2B or SaaS marketing site that's usually worth it — most of those plugins are weight you don't need. The full case for moving lives in our WordPress to Next.js migration guide; this article is the hands-on sequence.

What is the safest order to run a WordPress to Next.js migration?

The safe path is parity first, redesign later. Move your existing content and URLs onto Next.js with the same SEO signals before you touch a single headline or color. Then if traffic moves after launch, you know it was the migration — not new copy or a new design — and you can cleanly undo it. The order that keeps launches quiet:

1. Inventory — crawl the live site, export every URL, title, and meta description.
2. Redirect map — match every old URL to its new home (more on this below).
3. Metadata parity — copy titles, descriptions, canonicals, and schema across.
4. Build — rebuild pages in Next.js on a staging URL.
5. QA — check redirects, mobile, forms, and analytics on staging.
6. Cutover — point DNS at the new site during low-traffic hours.
7. Stabilize — watch logs, crawl errors, and rankings for two to four weeks.

Run any redesign as a separate project after step 7, once the new baseline holds.

How do I build the redirect map for WordPress to Next.js?

The redirect map is the single most important artifact in the migration: every URL on your WordPress site today and where it goes on the new one. Each old URL needs a permanent 301 redirect so its ranking signals pass to the new page. A 302 (temporary) doesn't pass authority the same way, so use 301 for anything moving for good.

Crawl the site with a tool like Screaming Frog, then add anything it misses from your XML sitemap and Google Search Console's "Pages" report. WordPress is famous for URLs you forgot existed — /?p=123 links, /category/, /tag/, author archives, paginated pages, and old wp-content media paths. Each needs a decision: redirect to the closest new page, or let it 404 on purpose if it has no value and no traffic.

Three rules save you pain. Never chain redirects — point each old URL straight to its final destination, since chains waste crawl budget. Pick one trailing-slash style and redirect the other so you don't create duplicate URLs. And put a self-referencing canonical URL on every new page so search engines aren't guessing which version is real.

How do I keep my SEO and rankings during the migration?

Rankings survive when the new page sends the same signals as the old, plus a clean redirect: matching titles, meta descriptions, and headings, the same structured data, and content at least as good as before. A migration is the wrong time to "trim" copy — thin a page out and you can drop the rankings it held.

Work through this parity checklist before you go live:

• Titles and meta descriptions copied for every page, not just the homepage.
• Canonical tags self-referencing and pointing to the right URL.
• Structured data (Article, FAQ, Organization, Breadcrumb) rebuilt in JSON-LD.
• XML sitemap regenerated and submitted in Search Console.
• robots.txt allowing crawlers — not accidentally blocking the whole site, the classic launch-day disaster.
• Internal links pointing at new paths, not redirected old ones.

After cutover, expect a short wobble while Google recrawls. Per Google's documented guidance on site moves, a move with proper 301 redirects does recover, though recrawling a large site can take weeks. The fix for nerves is data: watch the "Pages" and "Crawl stats" reports in Search Console daily for two weeks, and clean up any index bloat as old URLs drop out.

How do I keep visibility in ChatGPT, Perplexity, and AI Overviews?

AI search reads your pages the same way regular crawlers do, so most of the work above protects it too — with a few extra moves. AI answer engines pull from clean, well-structured pages and increasingly check for an llms.txt file. During a migration, make sure robots.txt doesn't block AI crawlers like GPTBot or PerplexityBot, keep your answer-first content and FAQ schema intact, and ship an llms.txt to your key pages.

This is answer engine optimization. Pages that win citations answer a question in the first sentence, in structure a model can quote. If AI visibility matters, pair this with how to rank in ChatGPT and Perplexity and the AEO playbook for B2B websites. The honest take on whether the file alone helps is in does llms.txt help ChatGPT.

How do I go live safely without downtime?

Build and test the new site on a staging URL, then change DNS during your lowest-traffic window — and keep the old site running until the new one is confirmed serving correctly. A safe DNS cutover is reversible: if something's wrong, point DNS back to the old site while you fix it. Never delete WordPress on launch day.

A simple go-live runbook:

1. Lower DNS TTL to 300 seconds a day before, so changes propagate fast.
2. Final staging check — redirects, forms, analytics, mobile, schema.
3. Cut over DNS during quiet hours with at least two people watching.
4. Test live — hit your top 10 old URLs and confirm each 301s to the right place.
5. Submit the new sitemap in Search Console and request indexing on key pages.
6. Watch for 48 hours — logs, 404s, redirect hits, conversion paths.

For B2B sites where a bad launch hour is expensive, cutover should be a watched, reversible event, never a Friday-night gamble. At Greeto we run it as a supervised research → plan → build → review → ship loop: AI agents do the heavy lifting of crawling, mapping, and building, and a senior engineer reviews every gate. That human-in-the-loop review is what keeps an AI-built migration from shipping a broken redirect map nobody noticed.

FAQ

Will I lose SEO when I migrate from WordPress to Next.js?

Not if you redirect properly. Every old URL needs a 301 permanent redirect to its new home, and the new pages need the same titles, descriptions, and structured data. Expect a short dip while Google recrawls and follows the redirects, then recovery. Skipping the redirect map is the main reason migrations lose rankings.

How long does a WordPress to Next.js migration take?

A scoped, parity-first migration for a typical B2B marketing site usually takes a few weeks, depending on URL count and integrations. A few dozen pages is faster; thousands of posts with complex redirects takes longer. Adding a redesign extends it, which is why we keep the two projects separate.

What happens to my WordPress media and images?

Copy them into the new site instead of hotlinking the old wp-content paths. If you keep pointing at old WordPress URLs, your new site still depends on the old infrastructure and can break silently when WordPress is shut off. Move assets into your public folder and redirect the old media URLs.

Do I need a redirect for every single old URL?

For every URL with traffic, backlinks, or rankings, yes — 301 it. For genuinely dead URLs with no value (spam tags, empty archives), let them 404 or return a 410 on purpose. The point of the redirect map is to make that call deliberately per URL, not to redirect everything to the homepage, which Google treats as a soft 404.

Can AI agents handle a WordPress to Next.js migration?

Yes, with supervision. AI coding agents are fast and good at the repetitive, error-prone parts — crawling URLs, generating the redirect map, rebuilding pages, copying metadata. What they can't do alone is judge tradeoffs or catch a redirect pointing to the wrong page. So every Greeto migration pairs the agents with a senior engineer who reviews each step — the model in building websites with Claude Code.