How to Migrate from WordPress to Next.js Without Losing SEO Rankings

You can migrate from WordPress to Next.js without losing your search rankings, as long as you map every old URL to its new home, preserve your analytics setup, and clearly tell search engines what changed. Most ranking drops after a migration are not caused by the new technology. They come from broken redirects, lost metadata, and pageview tracking that quietly stops working.

We know this because we recently migrated our own site, creiden.com, from WordPress to Next.js. This guide is the playbook we followed, including the parts that are easy to get wrong. It is written for founders and marketing teams who want the upside of a modern stack without gambling on the traffic they have already earned.

Why move from WordPress to Next.js in the first place?

You move to Next.js when you want faster pages, tighter security, and full control over how your site is built, and you have (or can hire) the engineering to maintain it.

WordPress is excellent for getting online quickly, but it carries weight: plugins that conflict, themes that bloat your markup, and a constant patching cycle for security. Next.js gives you a leaner, faster site with server-side rendering and static generation, both of which help Core Web Vitals, the page-speed signals Google uses for ranking.

That said, Next.js is not the right move for everyone. If you run a small brochure site with no developer on hand and no performance problem, the migration cost may outweigh the benefit. The teams that gain the most are the ones running content-heavy or commercial sites where speed, scalability, and custom functionality directly affect revenue.

What actually breaks SEO during a migration?

The framework does not break your SEO. The execution does.

When rankings fall after a migration, it is almost always one of these five issues, not the move to Next.js itself:

1. URLs change without redirects. Old links and indexed pages return 404 errors, and the ranking they earned is lost.
2. Page metadata is dropped. Title tags, meta descriptions, and canonical tags are not carried over to the new templates.
3. Structured data disappears. Schema that was added by a WordPress plugin needs to be rebuilt in Next.js.
4. Analytics stops counting correctly. Next.js handles navigation differently, and default tracking under-reports pageviews (more on this below).
5. The sitemap is never updated. Search engines keep crawling old paths and take longer to find the new ones.

Every one of these is preventable with a checklist. None of them is a reason to avoid Next.js.

How do you map old URLs to new ones?

Crawl the old site, export every live URL, decide the new structure, then create a 301 redirect from each old URL to its new equivalent.

A 301 is a permanent redirect. It tells search engines the page has moved for good and passes the old page's ranking value to the new location. This single step protects most of your existing traffic.

In our own migration, we restructured the blog at the same time. Posts moved from a flat /post-slug pattern to a language-aware /en/insights/post-slug structure, which set us up for a bilingual site with an Arabic /ar/ path to follow. Every old post URL was mapped to its new path with a 301. A few examples of how paths changed:

1. /our-process redirected to /en/our-process
2. /blog-post-title redirected to /en/insights/blog-post-title
3. /services/web redirected to /en/services/web-development

Practical tips that save you later:

1. Crawl the old site with a free tool to capture every indexed URL, not just the ones in your menu.
2. Redirect to the closest matching page, never to the homepage. Mass redirects to the homepage are read as soft 404s and lose the ranking.
3. Keep the redirect map as a spreadsheet. You will reuse it for testing after launch.

How do you keep Google Analytics and Search Console working?

Keep your existing GA4 property rather than creating a new one, so you do not lose historical data, audiences, and integrations.

It is tempting to start fresh, but a new property means rebuilding your conversion events, custom dimensions, audiences, and connections to Google Ads, Search Console, and BigQuery. You also lose the ability to compare before and after the launch. We chose to retain our existing property and update its configuration instead.

Two things need attention when you keep the property:

1. Update anything keyed to old URL paths. Key events, audiences, content groupings, and path-based filters that referenced the old structure must be pointed at the new one (for example, the new /en/insights/ path).
2. Add a content grouping or custom dimension for language. With an /en/ prefix now in place (and /ar/ planned), language segmentation lets you report on each audience cleanly.

On the Search Console side, resubmit your updated sitemap as soon as you launch, and annotate the launch date in GA4 so future-you understands any shift in the numbers.

Why do pageviews drop on Next.js, and how do you fix it?

Next.js navigates between pages on the client side, so the default analytics tag only fires once on the first load and under-counts every page after that. You fix it by tracking each route change explicitly.

On a traditional WordPress site, every click loads a fresh page and fires your analytics tag. Next.js (especially with the App Router) does not reload the page when a visitor moves around. The browser updates the view without a full page load, so the standard tag never fires again, and your pageviews look like they collapsed overnight.

There are two ways to handle it:

1. Enhanced Measurement in GA4 has a setting for page changes based on browser history events. This works for some setups but can be inconsistent with the App Router.
2. A manual page_view event on route change is the reliable option for the App Router. You listen for navigation and send a pageview each time the route changes. This is the approach we recommend.

The tricky part is that this issue is silent. Nothing errors out. Your site works perfectly, but your analytics quietly under-reports, and if you do not catch it early you may wrongly conclude the migration hurt your traffic when the visits were there all along.

What about sitemaps, canonicals, and hreflang?

Generate a fresh sitemap on the new URLs, add a self-referencing canonical to every page, and use hreflang tags if you run more than one language.

1. Sitemap: generate it from the new Next.js routes and submit it in Search Console. Remove the old sitemap so crawlers stop chasing dead paths.
2. Canonical tags: each page should point to itself as the canonical version, using the new URL. This prevents duplicate-content confusion during the transition.
3. Hreflang: if you serve English and Arabic, hreflang tells Google which version to show in which region. Get the language and region codes right, and make sure each language version references the others.

If you ran a crawl on a staging subdomain before launch, double-check that no staging URLs got hardcoded into your canonicals, sitemap, or hreflang tags. It is a common migration slip and it points search engines at a site they cannot reach.

How do you confirm the migration worked?

Run a post-launch checklist the same day you go live, then monitor rankings for several weeks.

Walk through this list on launch day:

1. Test a sample of old URLs from your redirect map and confirm each resolves to the right new page with a 301.
2. Crawl the live site and check for 404 errors and broken internal links.
3. Confirm GA4 is receiving pageviews, including on navigation between pages, not just first load.
4. Check that the new sitemap is submitted and being processed in Search Console.
5. Spot-check title tags, meta descriptions, canonicals, and schema on your most important pages.
6. Use Search Console's URL Inspection to request indexing of your top pages.

Then watch. Rankings and impressions in Search Console are your early-warning system over the following weeks.

How long until traffic recovers?

With clean redirects and preserved metadata, most sites see little to no lasting drop, just a short period of fluctuation while Google reprocesses the new URLs.

Expect some movement in the first two to four weeks as search engines recrawl, follow your redirects, and update their index. That is normal and temporary. A well-executed migration often holds rankings steady or even improves them, because the faster, cleaner site performs better on Core Web Vitals.

A drop that is severe and does not recover is a signal that something in the checklist was missed, usually broken redirects or lost metadata, not a problem with Next.js itself. If you see that pattern, go back to the redirect map first.

Planning a migration you cannot afford to get wrong?

We migrate content and commercial sites to Next.js while protecting the rankings and traffic you have already built. If you want a second set of eyes on your plan, or a team to run the whole move, get in touch here