WordPress to Next.js Migration: How to Move Without Losing Your Search Rankings

It is worth it when WordPress has become the problem, not when it is simply old. The usual triggers are a stack of plugins nobody fully understands, updates that wait for months, and login or access needs that WordPress core was not built for. If the site is patched, runs a few well-maintained plugins and staff edit pages every day, hardening WordPress usually costs less and risks less than moving.

• Many plugins are stacked to cover login, forms, membership or payments, each with its own update schedule.
• No one owns updates, so core, theme and plugin patches wait for weeks or months.
• You need MFA, SSO or role-based access designed into the product rather than added with plugins.
• Content changes rarely, or a developer team already manages it.
• The site has grown into a portal or an app that WordPress is being bent to run.

Stay and harden instead when the opposite is true: remove unused plugins, use a reputable managed host, patch within days, keep backups and put a web application firewall in front. A security flaw on its own is rarely a reason to migrate. When a core flaw such as CVE-2026-87902 appears, the first job is to update; migration is a separate decision you can make calmly afterwards. Our guides on WordPress versus custom website security and on CVE-2026-87902 cover both.

There are two main routes. In the first, WordPress stays as a headless CMS: editors keep the WordPress admin, and a Next.js front end fetches the content and builds the public pages. WordPress’s own developer documentation describes its REST API as a way to bring WordPress content into completely separate applications, usable from any language that can make HTTP requests and read JSON. In the second route, WordPress is retired and the content moves to a different headless CMS or to a custom admin built for your team.

Headless is often the smaller first step, but it keeps a WordPress admin to patch and protect. A full rebuild removes WordPress entirely and costs more up front. Choose based on who edits content, how often, and how much of the old system you are willing to keep running.

This is the process we follow on WordPress migrations. Each step produces something written down, so nothing depends on memory on launch day.

1. 1

   Audit the site

   List every page, post type, form, user role and plugin, and note what each plugin actually does for the business. Collect the current URLs from the sitemap, a crawl and Search Console so pages with traffic or inbound links are not missed.

2. 2

   Map old URLs to new ones

   Give every old address a destination in one spreadsheet: posts, pages, category and tag archives, author pages, feeds and media files under /wp-content/uploads/. Each line becomes a permanent redirect.

3. 3

   Rebuild and decide how content is edited

   Rebuild the templates in Next.js and choose between headless WordPress, another headless CMS or a custom admin, based on who edits and how often.

4. 4

   Move content, users and data

   Import posts, pages, media and accounts, compare a sample by hand with the old site, and rebuild login with the access model you need, such as role-based access, MFA or SSO.

5. 5

   Launch and monitor

   Switch over, test the redirects, submit the new sitemap and watch Search Console for errors and missing pages. After launch, dependency updates and monitoring continue as part of the work.

Google treats a platform change that alters URLs as a site move. Its Search Central guide to site moves with URL changes (updated 20 August 2026) recommends server-side permanent redirects such as 301 or 308, a complete map of old URLs to new ones, and keeping the redirects for as long as possible, at least a year. It also says that for a medium-sized site it can take a few weeks or more before Google shows the new URLs in place of the old ones, so some movement after launch is normal.

• Redirect each old URL straight to its closest new page. Avoid chains, and do not send many old URLs to the home page.
• In Next.js, list the redirects in next.config with permanent: true, which returns a 308. The Next.js docs note that hosting platforms can cap this list (Vercel allows 1,024) and suggest a redirect map read by Proxy for 1,000 or more.
• Give every new page a self-referencing canonical tag. In Next.js this is set with alternates.canonical in the Metadata API.
• Generate a sitemap of the new URLs with app/sitemap.ts and submit it in Search Console; keep the old sitemap until the new one has been submitted.
• Use server-side redirects, not JavaScript ones. Google’s redirects documentation says to use JavaScript redirects only when server-side or meta refresh redirects are not possible.
• Keep the site verified in Search Console, check the indexing and Sitemaps reports every week after launch, and update internal links so the site does not rely on its own redirects.

Keep the same domain if you can. Changing platform and domain at the same time makes problems harder to trace. If the domain has to change, Google’s guide adds the Change of Address tool in Search Console to the steps.

WordPress multisite runs several sites from one installation. WordPress’s documentation describes networks as path-based (subdirectories) or domain-based (domains or subdomains), with each site keeping its own content tables and only the users table shared. That shapes the plan.

• Treat each site as its own migration, with its own URL map, sitemap and Search Console checks.
• Decide early whether shared users stay in one account system or are split per site, and how network-level administrators will manage every site afterwards.
• List which plugins and themes are active across the network, because one plugin may support features on every site.
• One Next.js app can serve several domains, and its redirects can match on the host name, so one codebase can hold the redirect maps for every site.
• Move one site first, watch its search traffic for a few weeks, then move the rest.

Whether you hire a local team or a remote one, for example a UK business working with an agency in another country, get these answers in writing before you sign.

• Is the full redirect map part of the written scope, and who checks it after launch?
• How will our team edit and publish content after launch, and will you train them?
• Which plugins will be rebuilt, which replaced by a service and which dropped?
• How are user accounts and logins moved, and what will users see the first time they sign in?
• Will the domain and URLs stay the same, and how long will you monitor search after launch?
• Who owns the code, hosting, CMS and domain accounts?
• Which of our working hours overlap with yours, and how quickly do you reply?
• Who updates dependencies after launch, and is that in the contract?
• Can we see migrations or content platforms you have built?

Time and cost depend more on content and URLs than on code. The main drivers are:

• The number of distinct page templates and custom post types.
• How many URLs need redirects, including archives and media files.
• Forms, payments, memberships and CRM or ERP integrations that plugins used to handle.
• Whether WordPress stays as a headless CMS or is replaced.
• User accounts and the login model, especially MFA or SSO.
• Multisite networks and extra languages, each with their own URLs.

Published figures vary widely and mostly come from agencies. As one example, Kolonell, a remote web studio, published an estimate on 8 October 2026 for UK small businesses: £13,000 to £30,000 excluding VAT for a move to headless Next.js, over 10–14 weeks (about 2 weeks of audit and scoping, 6–8 weeks of development and migration, and 2–4 weeks of testing and phased go-live). Treat that as one agency’s pricing, not a market rate. Some agencies sell a fixed migration sprint; ask what it includes, especially redirects and editor training.

We do not publish fixed prices. Our free consultation starts with the problems you have today, not with a rebuild: a 30-minute call with an engineer, a review of your WordPress site with a recommendation to patch, harden or migrate, and a written recommendation with a rough cost estimate. If staying on WordPress is the better answer, that is what the recommendation will say.

• WordPress to Next.js migration service
• WordPress vs a custom website: is moving safer?
• WordPress CVE-2026-87902: what to do
• What is a headless CMS?
• Book a free consultation and WordPress review

• Google Search Central: Site moves with URL changes (updated 20 August 2026)
• Google Search Central: Redirects and Google Search (updated 14 April 2026)
• Next.js docs: redirects in next.config.js (updated 30 June 2026)
• Next.js docs: How to handle redirects in Next.js (updated 19 August 2026)
• Next.js docs: sitemap.xml file convention (updated 18 August 2026)
• Next.js docs: generateMetadata, alternates and canonical (updated 19 August 2026)
• WordPress Developer Resources: REST API Handbook (accessed 1 November 2026)
• WordPress Developer Resources: Multisite (accessed 1 November 2026)
• Kolonell: WordPress to Next.js migration cost for UK SMBs, agency estimate (8 October 2026)