You can move a site from WordPress to Next.js without losing SEO if Google finds the same URLs, the same content and the same signals on launch day, only served faster. Rankings drop when URLs break, titles change or pages disappear, not because the stack changed. The work is a URL inventory, a redirect map and a launch checklist, all done before the new site goes live.
The same rules held when I rebuilt the Aura Clips agency site from Framer to WordPress on Bricks Builder, and they sit at the centre of my technical SEO and Core Web Vitals work on Next.js and WordPress sites. Treat what follows as the general process: the platform you are leaving changes the details, not the steps. If you are still weighing the budget, start with what a WordPress to Next.js migration costs.
Why do rankings drop after a migration?
Almost always for one of these reasons:
- Old URLs return 404. Every link and ranking pointing at them is lost.
- Titles and meta descriptions change because nobody copied them from the SEO plugin.
- Content is cut in the redesign, so pages that ranked for a topic no longer cover it.
- Structured data disappears because a plugin used to generate it.
- Content renders in the browser only, so crawlers get a thin HTML shell.
- Staging gets indexed, or the live site ships with a leftover noindex tag.
Each one is preventable. None of them is caused by Next.js itself. If your traffic has already fallen after a launch, my guide to recovering from a traffic drop after a redesign covers the diagnosis.
How do you build a complete list of old URLs?
Collect URLs from every source, because each one misses something:
- The XML sitemap from Yoast or Rank Math.
- Google Search Console, the Pages and Performance reports. Any URL with impressions matters.
- A full crawl of the live site, to catch pages missing from the sitemap.
- Analytics landing pages, for URLs that get traffic from campaigns or email.
- Backlink reports, for old URLs other sites still link to.
Merge them into one spreadsheet with a column for the new URL. Search Console deserves the most weight: any URL that shows impressions is one Google already associates with a query, and each of those needs a 301 to the right new page.
How should you map and redirect old URLs?
Keep URLs identical wherever you can. Where you cannot, redirect each old URL to its closest equivalent with a permanent 301. Google's guide to site moves with URL changes describes the same approach.
| Old WordPress URL | New Next.js URL | What to do |
|---|---|---|
/about-us/ | /about | 301 to the new page |
/2023/05/post-name/ | /blog/post-name | 301, or keep the old pattern |
/category/news/ | /blog | 301 to the closest listing |
| A page you are dropping | The most relevant remaining page | 301, never a blanket redirect to the homepage |
/wp-content/uploads/... images | New image URLs | 301 the ones with backlinks or image traffic |
Two details catch people out:
- Trailing slashes. WordPress adds them by default and Next.js does not. Pick one form with the
trailingSlashsetting and redirect the other, or you split signals between two versions of every page. - Redirect chains. If an old URL already redirected once on WordPress, point it straight at the final new URL.
In Next.js, a fixed list goes in the redirects() function in the config file, and pattern-based rules can live there too or in middleware. The free Redirect Map Builder turns a list of old URLs into a redirects() array for next.config.js and flags chains, loops and trailing-slash mismatches.
Related guide: Framer to Next.js migration: cost, SEO and what moves
What about feeds, tags and dated archive URLs?
WordPress creates far more URLs than the pages you edit. Archives, feeds and pagination are generated automatically, and some of them pick up links and impressions over the years. Listing each one by hand is slow, so handle them with pattern rules.
| WordPress URL type | Example | Sensible target |
|---|---|---|
| Dated permalinks | /2023/05/post-name/ | /blog/post-name, matched on year, month and slug |
| Tag archives | /tag/seo/ | A matching topic page if you build one, otherwise /blog |
| Category archives | /category/news/page/2/ | The blog index or the matching category |
| Author archives | /author/admin/ | /about |
| RSS feeds | /feed/, /post-name/feed/ | The new feed URL, or the post itself |
| Plain permalinks | /?p=123 | The post with that ID, matched on the query string |
Pattern rules complement the per-URL map; they do not replace it. Write the specific redirects for pages that rank or have backlinks first, then let patterns catch the long tail. Watch the order: a broad rule placed above a specific one will swallow it. The Redirect Map Builder suggests pattern rules for WordPress archives, feeds and dated permalinks, and flags query strings that a plain path rule will not match.
Related guide: Wix to Next.js migration: cost, SEO and what moves
What has to carry over besides the URLs?
| Signal | Where it lived on WordPress | Where it lives in Next.js |
|---|---|---|
| Title tag and meta description | Yoast or Rank Math fields | Page metadata, generated per route |
| One H1 per page | Theme or builder heading | The page component |
| Body content and internal links | Post editor | Content source or components |
| Image alt text | Media library | Image components |
| Canonical URL | SEO plugin | Page metadata |
| Structured data | SEO plugin | JSON-LD you output yourself |
| XML sitemap | SEO plugin | A generated sitemap route |
| Open Graph tags | SEO plugin | Page metadata |
Generate the structured data and the sitemap from the same content the pages render, so they cannot drift out of sync with what visitors see. Output JSON-LD per page type rather than one generic block, and validate it before launch. It is also worth adding an llms.txt file for answer engines: mohitgoyal.in, which I built on TanStack Start and React, publishes one.
If your content team wants to keep writing in WordPress, you do not have to move the content at all. WordPress can run headless as the content source for the Next.js frontend. I cover the trade-offs in when headless WordPress with Next.js is worth it, and build it as a headless WordPress service.
For the full list of what a Next.js site needs, see my technical SEO checklist for Next.js.
Related guide: Squarespace to Next.js migration: cost, SEO and what moves
How do you make sure Google can read the new pages?
Server-render them, so the HTML arrives complete instead of waiting on a JavaScript bundle. Check it yourself:
- Open View Source on a few key pages. The headline and body copy should be in the HTML.
- Run the URL Inspection tool in Search Console on the staging URL, if it is reachable, or right after launch.
- Run Google's Rich Results Test to confirm the structured data parses.
How do you launch without a gap?
A rebuild succeeds or fails on the handover period. While the new site takes shape, keep the existing WordPress site stable and keep shipping fixes on it, so the main channel is never unavailable for a day.
- 1
Freeze content
Agree a date after which nothing new is published on the old site, or copy late changes across by hand.
- 2
Final crawl
Crawl the old site one last time and update the redirect map with anything new.
- 3
Deploy and switch
Put the Next.js site live and point the domain at it. Remove any staging noindex rules.
- 4
Test every redirect
Request each old URL from the map and check it returns a single 301 to the right page.
- 5
Submit the sitemap
Submit the new sitemap in Search Console and request indexing for the most important pages.
What should you watch after launch?
- Search Console Pages report, for new 404s and pages dropped from the index. Add a redirect for every real 404.
- Performance report, comparing clicks and impressions for your top pages before and after.
- Core Web Vitals, which should improve. If they do not, look at images and third-party scripts first.
If you are planning a move, send me your list of old URLs and book a 20-minute call. I'll go through the redirect map with you before anything goes live, as part of my Next.js and React websites and technical SEO work.
