Next.js vs WordPress: which should you build on?

This question comes up in almost every discovery call, usually phrased as "can't we just do it in WordPress?" Sometimes the answer is yes. Increasingly it is no, and the reason has less to do with technology than with what the site is expected to do.

The honest case for WordPress

WordPress is not a bad choice. It is a bad default. It earns its place when:

• Your team publishes constantly and nobody technical is available to help.
• The site is mostly content — pages, posts, a contact form.
• You need a plugin ecosystem for things nobody wants to build twice.
• Budget is tight and speed to launch matters more than anything else.

If that describes you, a well-configured WordPress site with a lean theme will serve you fine for years.

Where it starts to hurt

The trouble arrives when the site stops being a brochure. Common breaking points:

Performance. Roughly 45% of WordPress sites pass all three Core Web Vitals on mobile. That number is not a technology limit, it is a plugin-stack limit — every page builder, slider, and analytics add-on ships its own JavaScript, and it compounds.

Custom logic. The moment you need real product logic — pricing calculators, gated portals, multi-step configurators, a customer dashboard — you are writing PHP inside a system designed for publishing.

Security surface. Every plugin is a dependency someone else maintains, on a platform that is a permanent target. Most WordPress breaches trace back to an outdated plugin, not to core.

Cost drift. Individually cheap plugin licences, hosting upgrades, and a maintenance retainer add up to a real annual number that nobody budgeted for at the start.

Where Next.js wins

Next.js renders pages on the server or at build time and ships far less JavaScript to the browser. In practice that means:

• Core Web Vitals you control directly rather than fight your theme for.
• Full ownership of meta tags, structured data, canonicals, and URL structure — everything technical SEO actually depends on.
• Product features and marketing pages living in one codebase, one deploy, one design system.
• Hosting that scales without a plugin doing the caching for you.

The trade-off is real: a developer is involved in a way they are not with WordPress.

The middle path most teams miss

You do not have to choose between "editors can publish" and "the frontend is fast". Headless architecture gives you both: WordPress, Sanity, or Contentful handles content, Next.js renders it. Your marketing team keeps the editor they know; visitors get a static-fast site.

This is the setup we recommend most often for companies that publish regularly but have outgrown a theme.

Side by side

Three-year cost of ownership

Build cost is the number people compare. It is rarely the number that decides.

They converge more than either camp admits. The decision should be made on capability and who maintains it, not on a spreadsheet that lands this close — and the broader cost picture is worth reading alongside it.

If you are migrating

Most rebuild disasters are redirect disasters. In order:

1. Export the URL map first. Every indexed URL, from Search Console and your sitemap, before anything changes.
2. Match old to new. Every changed URL gets a 301. No URL should 404 or land on the homepage — homepage redirects are treated as soft 404s.
3. Keep the URL structure where you can. The cheapest migration changes the technology and not the addresses.
4. Preserve titles, descriptions, and headings at first. Change them after the migration settles, so you can attribute any movement.
5. Move structured data across. Organization, breadcrumbs, articles.
6. Launch, then watch coverage weekly in Search Console for a month. Fix errors as they appear rather than after the quarter.

Traffic dips of a week or two are normal. Sustained drops are almost always missing redirects.

Common questions

Is Next.js better for SEO than WordPress? Neither is inherently better — Google indexes both. Next.js makes it easier to control the things that matter: page speed, metadata, structured data, and URL structure. A well-built WordPress site beats a badly built Next.js one every time.

Can my marketing team still publish? Yes, with a CMS behind it — including WordPress itself in headless mode. Budget for live preview, or your editors will quietly stop using it. The full comparison is here.

What about all our plugins? Some have direct equivalents, some become small builds, some you will discover nobody used. Audit the plugin list before quoting — it is the single biggest source of scope surprise in a migration.

We get hacked regularly. Will Next.js fix that? It removes the most common attack path, since there is no plugin layer and usually no server-side admin to compromise. It does not make you immune — it moves your risk to dependencies and your own code.

Is WordPress dying? No. It runs an enormous share of the web and will for years. It is simply no longer the default answer for every project, which is a different claim.

How we actually decide

Three questions, in order:

1. Is the site mostly content, or mostly product? Product logic points to Next.js.
2. Who edits it, and how often? Daily non-technical publishing points to a CMS — headless or otherwise.
3. What does a slow page cost you? If organic traffic drives revenue, performance stops being a preference.

If your answers are "product", "rarely", and "a lot", the decision is already made.

If you are about to put this out to tender, our guide to writing a website RFP covers what agencies need from you to quote accurately — and what a custom site actually costs sets expectations on budget.

Not sure which side you land on? Send us the site and what you want it to do next — we will tell you honestly if a rebuild is worth it or if you just need a plugin audit.