Migrating from WordPress to Next.js in 2026: How to Move Without Losing SEO

Migrating from WordPress to Next.js can make a site faster and easier to design for, but a careless migration is one of the most reliable ways to lose search traffic. Almost all of that loss has technical causes: URLs that disappear, redirects that were never set up, metadata that did not make the trip and indexing that was left half done. Every one of those can be planned for. This guide goes from content inventory to the redirect map, from canonical and hreflang to the launch-day checklist and the weeks after. If you have not yet decided whether to move at all, our Wix, WordPress and Next.js comparison is the place to start.

When does moving from WordPress to Next.js make sense?

A move makes sense when WordPress is the limit on speed, security or design freedom, not because a newer stack exists. Plugin dependency, the constant update load and performance problems are the usual reasons. Leaving WordPress entirely is not always necessary: if your content team likes the WordPress editor, a headless setup, where WordPress keeps managing content and Next.js renders the front end, is a middle path. Our piece on why Next.js suits business websites explains what you gain. A migration without a clear goal carries risk for no return.

How do you build a content inventory before migrating?

List every URL on the current site before anything else, together with its traffic, rankings and backlinks. Combine the sitemap, a crawler and Search Console data to capture pages, posts, category and tag archives, pagination, images and PDFs. Add each URL's traffic, ranking queries and backlinks next to it. That table decides what is kept, merged or dropped. Without it, pages that bring in traffic can vanish without anyone noticing until the numbers fall.

How do you prepare the URL map?

Keep the existing URL structure wherever you can; it is the safest option. Where a URL must change, record exactly which new address each old one goes to in a mapping table. Category and tag pages, pagination, date-based archives and image URLs belong in that table too. Even a small change, such as a removed date segment or a trailing slash, can cost rankings when there is no redirect behind it. On the new site, use short, consistent and meaningful URLs, because you want this to be the last migration for a long time.

How do you set up 301 and 308 redirects in Next.js?

Redirect every changed URL permanently and directly to its final address; permanent redirects are how ranking signals follow the content. In Next.js, redirects can be defined in next.config, and the Next.js documentation states that rules marked permanent return HTTP 308 (temporary ones return 307). Google's documentation on redirects lists both 301 and 308 as permanent. Avoid chains, where A goes to B and B goes to C: each old URL should point straight to its destination. The same Next.js documentation notes a limit of 1,024 redirects in next.config on Vercel; for maps larger than that, generate the redirects in Proxy from a lookup table instead of writing rules by hand. Test every rule with a crawler before launch.

How do you carry over metadata, structured data and hreflang?

Move every SEO signal that WordPress produced, not just the page text. That means page titles, meta descriptions, H1 and H2 structure, image alt text and internal links. Metadata entered through a WordPress SEO plugin has to be exported and mapped into the new system. Schema.org structured data (Article, FAQ, Product, LocalBusiness and so on) has to be rebuilt on the new site. Each page's canonical tag should point to its own canonical address, and on multilingual sites the hreflang links must be correct and reciprocal.

How do you set up SEO foundations in Next.js?

Render pages on the server so search engines and AI crawlers receive complete HTML, then generate metadata, the sitemap and robots.txt from code. Server-rendered pages (SSR, SSG or ISR) give crawlers the content without running JavaScript; our Next.js website development guide explains which rendering strategy fits which page. Generate metadata per page, build the sitemap and robots.txt from your data rather than by hand, and optimise images. Server-rendered HTML with structured data is also a large advantage for visibility in AI search, which we cover in our AI search visibility guide. If content only loads on the client, that advantage is gone.

How do you manage content without losing the WordPress editor?

Choose between three options: keep WordPress as a headless CMS, move to a dedicated headless CMS such as Sanity, Strapi or Contentful, or manage content as files (MDX). The WordPress editor is often what teams like most, and losing it is the biggest worry in a migration. The right choice depends on your content team's technical comfort and how often you publish: a marketing team that publishes daily needs an editor, a technical team that publishes monthly may be happy with files in a repository. Factor in who will keep the system updated too; our website maintenance cost guide breaks down that ongoing work. Show your team how the new editor works before launch, not after.

How do you test performance and Core Web Vitals?

Measure the new site's performance before launch on the templates that matter most: the home page, a blog post and a product or service page. Speed is often one of the reasons for migrating, so check that you actually gained it. Image sizes, third-party scripts and font loading usually decide the result. Our Core Web Vitals guide explains how to measure LCP, INP and CLS in a way that reflects real users. A fast site with missing content is worth less than a slower complete one, so aim for both.

What should the launch-day checklist include?

Prepare the checklist before launch day and go through it in order. Confirm the redirects work, robots.txt does not block the site, the sitemap is current and canonical and hreflang tags are correct. Check that the noindex tag, so often left on during development, is gone. Test that analytics and tag management fire on the new site. Pick a low-traffic window for the switch so you have room to react if something breaks.

What should you monitor after launch?

Watch Search Console closely for the first weeks: crawl errors, the indexing report and query performance. Submit the new sitemap and request indexing for critical pages with the URL inspection tool. Google's site-move guidance says to expect temporary ranking fluctuation, notes that a medium-sized site can take a few weeks or more for Google to show the new URLs, and recommends keeping redirects for as long as possible, generally at least one year. Fluctuation is normal; a decline that keeps going is a sign of a problem. Crawl for broken links and 404s regularly, and keep a copy of the old site for a while for comparison and rollback.

What are the most common migration mistakes?

The most common mistake is going live without a redirect map. The second is leaving a development noindex tag or robots block in place on the live site. Assets that look unimportant, such as images, PDFs and old blog posts, are often left behind and take their traffic with them. Not rebuilding metadata and internal links on the new site lowers rankings. And treating the migration as a one-off technical task, without the monitoring that follows, means problems are found late.