Migrating WordPress to Next.js: What It Actually Involves

WordPress runs a large share of the web and does a great deal well. Next.js is faster, more maintainable for developers, and increasingly what teams choose for new work.

Moving between them is a real project. Done properly it is a substantial improvement. Done carelessly it costs you traffic you spent years accumulating — and the difference is almost entirely one step, which is not the one people focus on.

First: should you?

Do not migrate if:

• Your site works and non-technical people update it happily. WordPress's editor is genuinely good. If your team publishes without help, that is worth more than a performance score.
• Your site is slow but you have not tried fixing it. Most slow WordPress sites are slow because of a missing cache, an old PHP version and unoptimised images — see speeding up WordPress. Fixing that is a day. A migration is months. Try the day first.
• You depend on plugins with no equivalent. Complex WooCommerce setups, membership systems, LMS platforms. Rebuilding those is not a migration, it is a rewrite.
• You have no developers. Next.js needs someone who can maintain it. WordPress does not.

Migrate if:

• Developer velocity is the constraint. Your team fights the CMS more than they build.
• You need a real application, not a site with an application bolted on.
• You want the same content on a site, an app and a kiosk. That is what headless is for.
• You have hit a performance ceiling that caching does not lift.
• Security maintenance is a burden. Plugin vulnerabilities are the most common way small sites are compromised, and a static or server-rendered front end removes that entire surface.

Be honest at this step. "Our site should be faster" rarely survives contact with what a migration costs.

Two shapes of migration

Headless — keep WordPress as the editor

WordPress stays, invisible to the public. Next.js fetches content from it over the REST or GraphQL API and renders the front end.

Good because: your editors keep the interface they know, plugins that manage content still work, and the migration is front-end only.

Costs: you now run two systems. WordPress still needs hosting, updating and securing — it is not public, but it is still there.

Full migration — leave WordPress behind

Content moves into a modern CMS — Payload, Sanity, Contentful, or files in the repository — and WordPress is decommissioned.

Good because: one system, no PHP, no plugin updates, and content in a structure you designed.

Costs: more work up front, and your editors have to learn something new. That last part is a change-management problem more than a technical one, and it is the one that sinks migrations.

Which to pick: headless if the editorial team is large or resistant, full migration if the team is small and technical. Headless is also a legitimate stepping stone — move the front end first, replace the back end later, when the front end is stable.

The step that decides whether you keep your traffic

Everything else on this page is engineering. This is the part that determines whether the project is a success or a story people tell at conferences.

Every existing URL must resolve, at the same address or via a 301 redirect to its exact equivalent.

Not to the homepage. Not to a category page. To the equivalent page. A bulk redirect of everything to / is the single most effective way to destroy a site's search performance, and it is what happens when redirects are left to the end of a project and done in a hurry.

Do it like this:

1. Export every indexed URL before you start. Search Console, your sitemap, your analytics, and a crawl with Screaming Frog or similar. Combine them — each source knows about URLs the others do not.
2. Map each one to its new address. Most are mechanical if you keep your slugs.
3. Keep the URL structure if you possibly can. The best redirect is the one you did not need. Changing /2019/03/post-name to /blog/post-name is a redesign of your URL space and a migration at the same time — do them separately, if at all.
4. Do not forget feeds, attachment pages, paginated archives, category and tag pages, and old image URLs.
5. Verify after launch, with a crawler, not by clicking. Every 404 in that report is a page you have lost.

Also: keep your robots.txt and sitemap correct from day one, and check Search Console daily for the first fortnight. Some ranking movement while Google re-crawls is normal. A cliff is not, and it is usually redirects.

Moving the content

The WordPress REST API is the usual route:

curl "https://oldsite.com/wp-json/wp/v2/posts?per_page=100&page=1&_embed"

_embed includes the author, featured image and terms in the same response, which saves a great deal of follow-up fetching.

What people underestimate:

HTML in post_content. WordPress stores rendered HTML, including shortcodes, block comments and inline styles from a decade of editors. You are converting that into whatever your new CMS uses. Budget real time for it — this is usually the largest single task.

Images. Download and re-host them; do not leave them pointing at the old domain, or you can never turn it off. Re-encode to WebP while you are there, since you are touching every one of them anyway.

Everything that is not a post. Menus, widgets, custom fields, form submissions, redirects that already exist in a plugin. These live in odd corners of the database and are usually discovered late.

⚠ Read the content you are migrating. When we migrated this site's own archive, we found that the WordPress database had been compromised by a link-injection SEO spammer: twenty-five camouflaged links styled to look like plain text, spliced into fourteen articles, pointing at gambling and affiliate domains. One article carried five consecutive fabricated paragraphs recommending an unrelated company. A migration that copies post_content faithfully copies all of that into the new site. A compromised WordPress database is common, and a migration is the one moment you will ever look at every article. Do not waste it.

What you have to rebuild

Things WordPress gave you free, which are now yours:

None is hard individually. Together they are the part of the estimate that is always missing, and the reason migrations run over.

Two worth calling out:

SEO metadata. Yoast does a lot of small things correctly. You must reimplement canonicals, Open Graph, hreflang if you are multilingual, and valid structured data — and the last one is easy to get subtly wrong. The technical SEO checklist is the list to work through.

Spam protection. A public form endpoint is found by bots within days. You need a bot check and a honeypot, not just validation.

A realistic sequence

1. Audit. Every URL, every plugin, every content type, every integration. Two weeks of finding out what you actually have.
2. Decide headless or full.
3. Build the front end against the existing WordPress API. Nothing is live yet.
4. Migrate the content if you are going full. Script it, run it repeatedly, refine it — never do this by hand.
5. Build the redirect map. Every old URL to its new address.
6. Stage it, noindexed, and have the people who will use it use it.
7. Launch on a quiet day. Not a Friday, and not before a campaign.
8. Watch Search Console daily for a fortnight. Crawl for 404s.
9. Keep the old site available for a month. You will need something from it.

For a typical content site with a few hundred posts, budget six to ten weeks including content work — not the two weeks the front end alone suggests. This is the kind of project this is the kind of work we do if you would rather hand it over.

What you actually get

Being concrete, and honest.

Real gains: substantially better Core Web Vitals, particularly INP, because you are shipping far less JavaScript and no PHP is running per request; the plugin-vulnerability attack surface disappears; developers work in a normal codebase with version control and code review; and content becomes reusable across surfaces.

Real losses: the WordPress editing experience, the enormous plugin ecosystem, the ability to hire someone in an afternoon, and the ability for a non-technical person to change the layout of a page without a deploy.

That last one causes more post-migration friction than every technical issue combined. Decide in advance who is allowed to change what, and build the editing experience for the people who will actually use it — not for the developers who built it.

Frequently asked questions

Is Next.js faster than WordPress? Usually yes, substantially, because pages can be static or server-rendered with far less client JavaScript and no PHP execution per request. But a well-cached WordPress site on good hosting beats a badly built Next.js site — the framework is not the whole story.

Will migrating hurt my SEO? Only if you get redirects wrong. Map every old URL to its exact new equivalent with a 301, keep slugs where you can, and verify with a crawl after launch. Expect some fluctuation for a few weeks; a cliff means redirects.

What is headless WordPress? Keeping WordPress as the content editor and admin, but rendering the public site with something else — Next.js, in this case — which fetches content over the REST or GraphQL API. Editors keep their familiar interface; visitors never see WordPress.

How long does a WordPress to Next.js migration take? For a content site with a few hundred posts, six to ten weeks including the content conversion and redirect work. The front end alone is faster; the content HTML and the rebuilt plugin functionality are what take the time.

Can I keep using the WordPress editor? Yes, with a headless setup. That is the main reason to choose headless over a full migration, particularly with a large or non-technical editorial team.

What happens to my plugins? They stop being available. Forms, SEO metadata, caching, search, related posts and comments all need replacing with code or services. Listing what each plugin actually does, before you start, is the most useful hour of the whole audit.