Most comparisons of these two answer the wrong question. They line up speed, SEO and developer experience, declare a winner, and skip the thing that actually decides it.
Speed is not the deciding factor any more. A well built WordPress site on decent hosting with a proper cache is fast. A badly built Next.js site that ships 900kb of JavaScript to render a pricing table is not. Both stacks let you do the right thing and both let you do the wrong thing.
SEO is not the deciding factor either. Both render HTML a crawler can read. Both let you control titles, structured data and canonicals. The difference between a site that ranks and one that does not is almost never the framework.
Here is what actually decides it.
Question 1: who edits the site on a Tuesday afternoon
This settles it more often than the other two combined.
Someone in marketing wants to change the headline on the pricing page, swap a testimonial and publish a case study. What happens next?
On WordPress, they log in, change it, and press update. No developer, no deploy, no ticket.
On Next.js with content in the repo, they open a pull request, or they ask an engineer to. Even with the best intentions, that is a ticket in a queue behind product work. In practice the copy does not get changed. I have watched a headline nobody was happy with survive for eight months because changing it required a developer who had more urgent things to do.
On Next.js with a headless CMS, they log in and press publish, same as WordPress. Which is the right answer, and it is also a second system to choose, pay for, configure and maintain.
If the answer is "marketing edits constantly and there is no dedicated front end developer", that is a very strong signal, and it points at WordPress or at headless.
Question 2: how often does the page structure change
There is a difference between changing copy and changing shape.
Changing copy is a headline, a paragraph, a testimonial, a price. Both stacks handle it, given the right CMS setup.
Changing shape is "we need a comparison page type", "the pricing page needs a third tier with a different layout", "we are adding a resource library with filtering". That is development work in either stack, but the cost is different.
In WordPress, a new page type means a custom post type, fields, a template, and making sure the builder or block editor exposes it sensibly to the person who will use it. Often quick. Occasionally a fight with the theme.
In Next.js, a new page type is a route and a component. It is usually cleaner, and if your team already writes React it is work they can do without learning a second set of conventions.
If your marketing site changes shape every few weeks, and you have React developers, Next.js starts paying for itself.
Question 3: what else lives on the domain
Look at what the site has to carry over the next two years.
A marketing site with ten pages and a blog is comfortable in either stack.
Add documentation, a changelog, gated content, a customer login, a status page, and programmatic landing pages generated from a data set, and the picture changes. Ask where each of those wants to live, and whether your chosen stack fights you on any of them.
WordPress strains when the site starts behaving like an application: complex gating, real user accounts, anything with heavy read and write traffic. Next.js strains when non technical people need to change things constantly and nobody set up a CMS.
What WordPress actually costs you
Being fair to it, because I build a lot of WordPress and I am not about to pretend it is free.
- Maintenance is continuous. Core, theme and plugin updates, and occasionally one of them breaks something. A staging environment stops being optional.
- Plugins are supply chain risk. Every one is code you did not write, running with full access to your site. The popular ones are usually fine. The abandoned one somebody installed in 2021 is not.
- Performance is opt in. You can build a fast WordPress site, but nothing stops you building a slow one, and the defaults do not help.
- There is a ceiling. When the marketing site starts wanting to be an application, you will feel it.
What Next.js actually costs you
Being equally fair.
- A developer in the loop, unless you add a CMS. This is the big one and it is easy to underestimate during a rebuild, when engineers are enthusiastic and nobody has yet had to wait four days for a typo fix.
- Build times and deploy steps between an edit and it being live. Usually minutes, occasionally not.
- Ownership risk. When the person who built it moves on, WordPress has a large pool of people who can pick it up. A bespoke Next.js codebase has a smaller one.
- It is easy to overbuild. A marketing site does not need a client side state library, and yet.
The hybrid nobody mentions
You do not have to pick one for everything.
A common and sensible arrangement is the marketing site on WordPress, and the app and docs on whatever the product team uses. Marketing owns and edits their side. Engineering owns theirs. Nobody blocks anybody.
The other hybrid is Next.js with a headless CMS: WordPress, Sanity, Strapi or similar providing the content, Next.js providing the front end. You get the editing experience and the front end control. You also get two systems to run, two sets of credentials, two things to upgrade, and a more complicated answer to "why is the site down".
The second system is worth it when the front end genuinely needs to be custom. It is not worth it for a brochure site, and that is the most common way this decision goes wrong.
How I would pick
A seed stage SaaS, two engineers, no dedicated designer, marketing is the founder. WordPress with a block theme. The founder can change things at midnight without opening a terminal. Revisit in a year.
Series A, a marketing team of three, an engineer who can be borrowed occasionally. WordPress, or headless if you have a real design that a theme would fight. The deciding factor is whether marketing can ship without a ticket.
Product led, the marketing site is close to the app, engineers write the landing pages. Next.js, with content in the repo if engineers write it, or a headless CMS if they do not.
You already have a Next.js site that marketing cannot edit and everyone is frustrated. You do not need a rebuild. You need a CMS behind what you already have.
That last case is the most common one I get asked about, and it is the one where the answer is cheapest.
Work with me
Want me to check your site? Get a free 5-minute teardown.
I build and fix websites for SaaS and AI companies. Reply within 24 hours.
Get my free teardown