Next.js or WordPress: The Comparison Nobody Runs Honestly

We build in Next.js. We've also told people to stay on WordPress, more than once, and meant it.

That's the part missing from every comparison you'll find on an agency blog, because the agency writing it sells one of the two. The honest answer depends on things a feature table can't hold: how often your content changes, who changes it, and what you're going to want the site to do in three years.

Here's what actually differs, with the marketing removed.

First, the myth that needs to go

There's a claim going around that WordPress sites can't be read by AI crawlers. It isn't true, and believing it will send you into a rebuild you didn't need.

WordPress renders on the server. PHP runs, queries the database, assembles a page, and sends finished HTML. A crawler that never executes JavaScript gets the whole thing. That's the same outcome a server-rendered Next.js page produces, by a different route.

The real crawler risk isn't the CMS. It's page builders and React themes that ship an empty shell and paint the content in the browser, and you can do that on either platform. We found that exact problem on our own site, which is built in Next.js. Framework choice doesn't protect you from it.

Where they genuinely differ: the request path

A WordPress page is assembled per visit. The request hits PHP, PHP queries the database, every active plugin gets to run, and the HTML comes out the other end. Caching plugins put a saved copy in front of that so most visitors skip the work, which is why a well-configured WordPress site can be genuinely fast.

A Next.js marketing site is assembled at deploy. The pages become files, the files sit on a CDN, and a visitor gets one back without anything running on a server at all.

The useful way to read that difference isn't "one is fast and one is slow." It's:

• Where the ceiling is. Static files from a CDN are close to the physical limit. WordPress gets near it with the right caching, hosting and theme, and drifts away from it every time something is added.
• What holds it there. On the static side, nothing. It stays fast because there's nothing to degrade. On the WordPress side, staying fast is a maintenance job somebody has to keep doing.

The plugin surface is the whole trade

WordPress's ecosystem is the best reason to choose it and the main reason it goes wrong, and both come from the same fact: a plugin is code you didn't write, running on your server, with access to your database.

Thirty of them is a normal number for a business site. Every one is a thing that can conflict with another, slow the page down, break on a core update, or stop being maintained by whoever wrote it. None of that is hypothetical or unusual. It's the ordinary weather of running a WordPress site, and it's why "WordPress is free" stops being true about a month in.

What you get for that is enormous. WooCommerce, memberships, bookings, courses, events, and multilingual setups all exist, work, and cost a fraction of building them. If you need one of those, that ecosystem is a real asset and rebuilding it in a framework would be a bad use of money.

The question that actually decides it

Who edits the site on an ordinary Tuesday, and how often?

If the answer is "our office manager, most weeks," WordPress's admin is worth a great deal. It's familiar, it's forgiving, and nobody has to be walked through a deploy.

If the answer is "almost nobody, and when it happens we'd ask you," that admin is a large amount of machinery to maintain for something that runs six times a year. A Next.js site keeps its content in the repository, changes ship as a deploy, and there's nothing sitting there needing security updates in between.

The middle case is where people get caught out. If content changes weekly and you want the framework, you need a headless CMS, and then you're back to a monthly subscription and an editing interface to learn. That's a perfectly good setup. It just isn't the cheaper one, and it's usually sold as though it is.

When WordPress is the right answer

• Content changes often, and by someone non-technical
• You need something the ecosystem already solves well: a store with complex tax and shipping rules, memberships, course delivery, event ticketing
• The build budget is the binding constraint and the site is fairly conventional
• Nobody on your side is ever going to touch a repository, and you'd rather not depend on an agency for a copy change

When it isn't

• The site has real logic in it: a quoting tool, a portal, a dashboard, an integration with something you run internally
• You're going to want an app or a customer login later, and you'd rather not run two systems
• Performance is competitive in your market, and you'd rather it be structural than maintained
• You want to be handed the whole thing at the end and have it keep working untouched

That last one matters more than it sounds. A static site with no admin, no database and no plugins has almost no surface to rot. It's the closest thing to a website you can leave alone.

The cost shape, honestly

WordPress usually costs less to build and more to keep. Hosting, plugin licences, and somebody doing updates is a real annual number, and it doesn't stop.

Next.js usually costs more to build and less to keep. Hosting a marketing site is close to free, there's nothing to update on a schedule, and the recurring cost moves to wherever your content edits go: a developer, or a CMS subscription.

Neither is cheap. They're expensive in different places, and the place that hurts depends on whether your constraint is cash now or attention later. We publish our actual floors rather than making you get on a call to find out which one you can afford.

The part that outranks both

A badly built Next.js site is worse than a well-maintained WordPress site. It's not close.

Ship a React app that renders everything in the browser, load four font families, and skip the image work, and you've built something slower and less legible to search than a tidy WordPress install on a decent theme. The framework doesn't make a site fast, findable or good. It sets a ceiling. Everything under the ceiling is decisions.

So if you're choosing between two proposals, the framework line is the least informative thing on either of them. Ask what the page weighs, whether the content is in the HTML, what happens when you want to change something, and who owns the code at the end.

We build in Next.js because most of what we're asked for has software in it, and because web design and development that has to survive being handed over is easier to do with nothing running on a server. If what you need is a store on a platform that already solves stores, we'll say so, and e-commerce development covers both routes. The recommendation comes after the questions above, not before them.