How Do You Migrate WordPress to Next.js Without Losing SEO?

To migrate WordPress to Next.js without losing SEO, keep every indexed URL pointing somewhere live: crawl the old site, build a complete redirect map, serve 301s, set self-referencing canonicals, match trailing-slash behavior, convert posts to MDX with full content parity, carry over schema and sitemaps, then do a planned DNS cutover and watch Search Console. Most SEO loss during this move is self-inflicted. The CMS change is not the risk; broken URLs, missing redirects, and dropped schema are. This guide walks through the parts that actually decide whether your rankings survive, in the order a practitioner does them. Read it once before you touch a single redirect.

Does migrating WordPress to Next.js hurt your SEO?

Migrating WordPress to Next.js does not hurt SEO by itself. Google ranks URLs and content, not the platform behind them. You lose rankings only when URLs change without 301 redirects, when content gets thinner, or when signals like canonicals and schema disappear. Keep those continuous and rankings usually hold, and often improve because Next.js is faster.

The platform is invisible to a crawler. Googlebot sees HTML, headers, and links. If the same content lives at the same address (or at a new address that cleanly forwards with a permanent redirect), the search engine has no reason to re-evaluate you from scratch. A WordPress-to-Next.js migration goes wrong in three predictable ways: someone forgets a chunk of old URLs, someone ships a redesign that cuts word count in half, or someone launches without the schema and sitemaps the old site had. All three are avoidable. None of them are caused by Next.js.

In our experience, the sites that drop are the ones where "migration" meant "redesign and republish" with no URL inventory. The sites that hold are the ones that treated the old URL map as the contract.

When should you migrate WordPress to Next.js (and when not)?

Migrate when WordPress is fighting you: slow Core Web Vitals you can't fix with another plugin, a bloated theme, security and update churn, or a content team blocked by a fragile editor. Don't migrate if the site is small, ranking fine, and nobody is in pain. A migration is a real project with real risk; do it for a reason, not for fashion.

Good reasons to move: you want full control of performance and markup, your developers live in React, you need a modern component system, or you're adding AI-search infrastructure that WordPress makes clumsy. Bad reasons: "Next.js is trendy" or "a plugin annoyed me once." If your traffic is healthy and your team isn't blocked, the safest SEO move is to leave it alone.

If you do migrate, the redirect map is where the SEO is won or lost. For the build approach itself, the WordPress to Next.js migration playbook covers execution.

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

Build the redirect map by crawling every indexed URL on the old WordPress site, then writing one row per URL: old path on the left, new Next.js route on the right. Match WordPress permalink patterns to your new route structure, redirect each old URL with a 301, and never let a row resolve to a generic 404 or the homepage.

Start from ground truth, not memory. Pull URLs from the live XML sitemap, from Search Console's indexed-pages report, from a full crawl (Screaming Frog or similar), and from server logs if you have them. Deduplicate into one master list. Then map each WordPress permalink to its Next.js home:

Two rules save you. First, decide a trailing-slash policy and apply it everywhere — pick one and enforce it in next.config.js so /blog/post and /blog/post/ never both resolve. Second, kill index bloat on the way out: WordPress generates author archives, dated archives, tag pages, attachment pages, and feeds that often shouldn't carry over. Redirect the valuable ones, return 410 on the genuinely dead ones, and don't recreate junk in Next.js. A clean map protects your crawl budget and stops Google wasting time on URLs you abandoned. The redirect map deep-dive shows the format in detail.

How do 301 redirects, canonicals, and trailing slashes work in Next.js?

In Next.js, serve permanent redirects with permanent: true (a 301) in next.config.js or middleware, set a self-referencing canonical URL on every page via the metadata API, and lock trailing-slash behavior with trailingSlash so one canonical form exists. These three together tell search engines the old address moved here, this is the real address, and there is only one.

A worked order of operations:

1. Add your redirect map to next.config.js redirects() (or middleware for large maps), each entry permanent: true.
2. Set trailingSlash to match your chosen policy, and make sure redirects target the canonical form.
3. Emit a self-referencing <link rel="canonical"> on every page so no page points at the old domain or a stale path.
4. Confirm HTTP-to-HTTPS and www/non-www both resolve to one host with a single 301 hop — chained redirects leak signal.
5. Redirect, don't soft-404: a redirect that lands on a "page not found" template is worse than a clean 410.

Middleware matters once your map grows past a few hundred entries, because giant static redirect arrays slow the build. For very large maps, load a lookup table and match in middleware. Either way the status code must be 301, not 302 — a temporary redirect tells Google to keep the old URL, which is the opposite of what you want.

How do you convert WordPress posts to MDX without losing content?

Convert posts by exporting WordPress content (WXR export or the REST API), transforming the HTML into MDX, and preserving the full body, headings, images, internal links, alt text, and publish dates. The goal is byte-for-byte content parity: same words, same structure, same media. Thinner content after migration is the quiet ranking-killer nobody blames on the CMS.

Practical path: pull each post via the WordPress REST API (/wp-json/wp/v2/posts), then run an HTML-to-MDX conversion, fixing the things that break. Watch shortcodes (they vanish unless you map them to components), image paths (download and rehost, keep alt text), embeds, and internal links (rewrite to new routes using your redirect map so you don't rely on redirect hops for your own links). Keep original datePublished values; don't reset everything to launch day, or you'll look like a brand-new site to Google.

Do a content diff before launch. Compare old word count and heading structure against the new MDX. If a post lost three paragraphs in conversion, find them now. Frontmatter should carry title, description, canonical slug, publish and updated dates, and any schema fields. This is also the moment to apply spec-driven development: define the MDX shape once, then convert against that spec so every post lands consistent.

How do you keep AEO and GEO visibility after migrating to Next.js?

Keep AI-search visibility by treating llms.txt, schema markup, and your AI sitemap as first-class migration artifacts, not afterthoughts. WordPress plugins often generate JSON-LD and feed AI answer engines automatically; Next.js gives you nothing by default. If you don't rebuild that layer, you can hold Google rankings yet vanish from ChatGPT and Perplexity. This is the gap most migration guides ignore.

Three things to carry over and improve:

• Schema continuity. Whatever JSON-LD the old site emitted — Article, FAQ, Organization, BreadcrumbList — reproduce it in Next.js with the metadata API or inline JSON-LD. Map it post by post; don't assume a plugin replacement exists.
• llms.txt and AI crawler access. Ship an llms.txt, keep robots.txt allowing AI crawlers you want citing you, and don't accidentally block them during the rebuild. The does llms.txt help ChatGPT piece covers what it actually does.
• Answer-first content and AEO structure. Answer engine optimization and generative engine optimization reward self-contained, quotable passages and clean FAQ schema. Migration is the perfect time to add them. See the AEO playbook for B2B websites and the guide on ranking in ChatGPT and Perplexity.

The win condition is continuity plus upgrade: don't just preserve what WordPress emitted, ship a cleaner, faster, more citable version.

Headless WordPress or full Next.js rebuild — which is better for SEO?

For SEO, both work; the choice is about who edits content, not about rankings. Headless WordPress keeps the WP admin as a content backend and renders the front end in Next.js — good when non-technical authors need a familiar editor. A full rebuild moves content into MDX in the repo — leaner, faster, fewer moving parts, better when engineers and AI tooling own the content.

Neither is inherently better for SEO — output HTML, redirects, and schema decide that. At Greeto we lean toward full MDX rebuilds because they remove plugin drift and let an AI-assisted workflow own the whole stack, but a content team that lives in WordPress is a legitimate reason to go headless. Pick for the humans, then nail the redirects either way.

How do you do the cutover and monitor Search Console after launch?

Do a planned DNS cutover: lower TTL beforehand, deploy the new Next.js site with redirects live, test the redirect map against the new host, then point DNS over during low traffic. Right after, submit the new sitemap in Search Console, keep the old sitemap temporarily so Google recrawls and discovers redirects, and watch coverage and performance for two to four weeks.

A safe sequence:

1. Pre-cutover: lower DNS TTL, run the full redirect map against the new origin, confirm every old URL returns a single 301 to a live page.
2. Cutover: deploy, point DNS, verify HTTPS and canonical host resolve cleanly.
3. Hour one: spot-check top-traffic URLs live, submit the new XML sitemap, request indexing on key pages.
4. Weeks one to four: in Search Console watch the Pages (coverage) report for spikes in 404s or "redirect error," watch impressions and average position, and use URL Inspection on important pages to confirm Google sees the new version.

Expect a brief wobble — Google needs time to recrawl and process redirects — but a clean map recovers fast. Keep the old sitemap submitted for a few weeks so redirects get discovered, then remove it once the new URLs are fully indexed. Don't panic at week-one noise; panic only if 404s climb, which means a chunk of your map is missing.

FAQ

Will I lose rankings when I migrate WordPress to Next.js?

Not if URLs and content stay continuous. Rankings drop when old URLs 404 instead of redirecting, when content gets thinner, or when schema and canonicals disappear. With a complete 301 redirect map and content parity, most sites hold steady and often gain from faster load times.

How long does it take to recover SEO after a migration?

Typically a few weeks. Google needs time to recrawl old URLs, follow the 301s, and reindex new ones. A clean redirect map and a freshly submitted sitemap speed this up. Expect a short dip in the first week or two, then recovery. If a decline keeps growing past a month, your redirect map probably has gaps.

Do I need a 301 for every single old URL?

For every indexed or linked URL, yes. Pages with traffic, backlinks, or rankings each need a permanent redirect to their new home. Genuinely worthless URLs — spammy tag archives, dead attachment pages — can return 410 instead. The mistake to avoid is redirecting everything to the homepage; that tells Google the content is gone.

Should I keep the same URL structure or change it?

Keep it if you can. Identical URLs mean zero redirect overhead and zero risk. Change URLs only when the old structure is genuinely bad (dated permalinks, messy categories), and when you do, map every old path to a new one with a 301. Never change URLs and content at the same time without a redirect map.

What's the difference between a 301 and a 302 in this context?

A 301 is permanent and passes ranking signals to the new URL; a 302 is temporary and tells Google to keep indexing the old URL. For a migration you always want 301s. In Next.js, that means permanent: true in your redirect config. A stray 302 across your map can stall the whole migration's signal transfer.

How do I keep my schema and AI visibility after moving off WordPress?

Rebuild it explicitly. WordPress SEO plugins generate JSON-LD and feeds automatically; Next.js does not. Reproduce your Article, FAQ, and Organization schema in code, ship an llms.txt, and keep AI crawlers allowed in robots.txt. Migration is the right moment to also add answer-first content so you stay citable in ChatGPT and Perplexity.

Is headless WordPress safer for SEO than a full rebuild?

No — both are equally safe for SEO when done right. The deciding factor is the rendered HTML, redirects, and schema, not whether content comes from WP admin or MDX files. Choose headless if non-technical editors need the WordPress interface; choose a full MDX rebuild for a leaner, AI-era stack. SEO outcomes depend on execution, not the choice.