How to Migrate WordPress to Headless Next.js Without Losing SEO

• Use `next-sitemap` or a custom sitemap route
• Include every indexable URL
• Set correct `lastmod` dates from your content's `dateModified`
• Reference the sitemap in your robots.txt

Ensure robots.txt allows crawling of your frontend and doesn't accidentally block Next.js static assets (`/_next/`). Also confirm AI crawlers (GPTBot, ClaudeBot, PerplexityBot) aren't blocked if you want AI search visibility.

Step 5: Handle Media and Images

Keep media URLs stable where possible. If images move from `/wp-content/uploads/` to a CDN, implement redirects for the old paths.

Preserve alt text. Alt attributes are stored as WordPress attachment metadata — ensure they transfer through your GraphQL queries into your Next.js Image components.

Use Next.js Image optimization for automatic WebP conversion and responsive sizing — this is a performance win, but configure the loader correctly for your WordPress-hosted media.

Step 6: Test in Staging Thoroughly

Before any DNS change:

• Crawl the staging site with Screaming Frog and compare the URL inventory against your baseline export
• Verify every page returns 200 (or the intended 301)
• Check that titles and meta descriptions match the pre-migration inventory
• Validate schema on every template type
• Test Core Web Vitals — the migration should improve them, not regress
• Verify forms, search, and any interactive functionality
• Test on mobile devices, not just desktop emulation

Step 7: Launch and Monitor

Launch during low-traffic hours for your primary audience.

Immediately after launch:

• Submit the new sitemap in Google Search Console
• Use URL Inspection on 10–15 key pages and request indexing
• Verify redirects are firing correctly with a redirect checker
• Monitor server logs for 404s

First 48 hours: Watch GSC Coverage report for crawl errors. Watch GA4 for traffic anomalies by landing page.

First 30 days: Expect some ranking volatility — this is normal during re-crawling. Compare weekly against your baseline. Investigate any page that drops more than 5 positions.

60–90 days: Rankings should stabilize at or above pre-migration levels. Performance improvements from static generation should start showing in Core Web Vitals field data.

Common Migration Mistakes

Forgetting trailing slashes. WordPress typically uses trailing slashes; Next.js doesn't by default. This creates duplicate URLs and redirect chains.

Losing the canonical tags. Without canonicals, you risk duplicate content issues between www/non-www, http/https, and parameter variations.

Client-rendering the content. The single most damaging mistake — your content becomes invisible to AI engines and unreliably crawled by search engines.

Skipping the staging crawl. A full crawl comparison catches missing pages, broken redirects, and metadata gaps before they cost you traffic.

No rollback plan. Keep your WordPress frontend accessible (even if just at a temporary URL) for 30 days in case you need to revert.

Getting Help

Migration is one of the highest-risk operations you can perform on a site with established rankings. Our React and Next.js development services include headless migrations with full SEO preservation, and our SEO services cover pre-migration auditing and post-migration monitoring.

Talk to us about your migration for a technical assessment and risk review.

Frequently Asked Questions

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

For a standard content site, 4–8 weeks including development, testing, and launch. Complex sites with e-commerce, membership, or heavy custom functionality take 8–16 weeks.

Will I definitely lose rankings during migration?

Some short-term volatility is normal as Google re-crawls. Done correctly — with URL preservation, complete metadata transfer, and server-side rendering — most sites return to baseline within 30 days and often exceed it due to performance gains.

Can I migrate incrementally?

Yes. A common approach is migrating your blog first (lowest risk, highest performance benefit), then marketing pages, then transactional pages. This limits blast radius and lets you validate the approach.

What if my site relies heavily on plugins?

Audit your plugins first. Backend plugins (SEO, custom fields) transfer fine. Frontend-rendering plugins need rebuilding in React. If your site depends on many frontend plugins, headless may not be cost-effective — a traditional WordPress optimization might serve you better.