Skip to content

Next.js to WordPress

Give your marketing team the edit button back.

Next.js is a great tool for developers. For a marketing site, it often means every headline change becomes a pull request, and every new landing page waits for a sprint.

We build sites on both. When the people who edit the site are not developers, we move it to WordPress, with blocks your team can use on their own and the speed you had before.

Stuck in the dev queue?

Replies within one business day.

Why teams make this move

Every edit needs a developer.

Copy, images and new pages sit in a ticket queue.

The developer who built it has moved on.

Nobody left knows the codebase well enough to change it safely.

Marketing tools do not plug in.

Forms, CRM integrations and landing page tests all need custom code.

What moves, what gets rebuilt, what stays behind

Moves across

Comes across as it is

  • Page and post content (Markdown, MDX or CMS entries)
  • Images and media
  • Titles, descriptions, canonicals
  • URL structure, as far as possible
Gets rebuilt

Built again on the new platform

  • React components as editable blocks and patterns
  • Forms, with a WordPress form plugin
  • Navigation and footer
  • Sitemap, schema and redirects
Stays behind

Left on the old platform

  • The Next.js build and deploy pipeline
  • Custom API routes you no longer need
  • Build-time integrations

How we run it

  1. 01Inventory every URLfrom the sitemap, Search Console, analytics and a crawl.
  2. 02List every componenton the current site and decide which become blocks, which become patterns, and which are dropped.
  3. 03Match the URL format.Next.js sites usually have no trailing slash. WordPress adds one by default. We either keep the old format or redirect in one hop.
  4. 04Build on a block themewith a small set of custom blocks. Editors get choices, not a blank canvas.
  5. 05Keep performance in the brief.Core Web Vitals on the new site are measured against the old one, template by template.
  6. 06Launch, test every old URL on production, and watch Search Console.
  7. 07Train your teamon the editor, with short recorded walkthroughs.

Where this usually goes wrong

The WordPress site ends up slower than the Next.js one.

Usually from a heavy page builder or too many plugins. We build with native blocks and a short plugin list.

Too much freedom in the editor.

A blank canvas leads to off-brand pages. Locked patterns keep the design intact.

Trailing slash and redirect code changes

go unnoticed and create chains.

From our logs

We are finishing a WordPress to Next.js move right now, so we know both sides of this trade.

What we won’t promise

WordPress will not be faster than a well-built Next.js site out of the box. It can be close, with care. What you gain is control.

Frequently asked questions

Isn’t this a step backwards?+

Not if the people editing the site are marketers. The best stack is the one your team can change on a Tuesday afternoon without a deploy.

Could we go headless instead and keep Next.js?+

Yes. Headless WordPress keeps your Next.js front end and gives editors the WordPress admin. It still needs a developer for new layouts. See WordPress to Next.js for that route.

Will the design change?+

Only if you want it to. We can rebuild the current design as blocks.

Who hosts it?+

A managed WordPress host of your choice. We can recommend one sized to your traffic.

Waiting on developers for every change?

Send your current URL. We will tell you what the move involves before you commit.

Replies within one business day.