WordPress or Next.js: how to actually decide

Four things settle this before the technology does

The comparison is normally run as a technology argument: rendering models, build tooling, how much JavaScript arrives in the browser. That argument has an answer. It is not the answer to your question, because the site will not be maintained by an argument. It will be maintained by whoever is at a desk when the pricing page needs changing.

Four inputs do the work, and every one of them is a fact about your business rather than about software. Establish them first. They narrow the shortlist before anybody draws a wireframe.

• Who edits the site — not who has an account, but who has actually changed something.
• What they change — words and images inside a template that already exists, or whole page layouts that did not. These are different jobs, and the platforms differ on the second in a way they do not on the first.
• What the site is connected to — the form that feeds the CRM, the booking calendar, the payment gateway, the stock connector. Each is its own decision about whether a move is affordable.
• Who maintains it after the build, including the case where the people who commissioned it have moved on.

None of the four is a technical question, and none requires you to have picked a platform in order to answer it. That is the whole reason they come first.

Editing without a developer, and who picks it up later

The distinction that matters is not whether your team can edit the site. Almost any arrangement can be made to allow changing a headline. It is whether somebody non-technical can compose a page that did not exist before — a new service page whose layout the template set does not already provide. WordPress with a well-built block editor is designed for exactly that job.

There is a way to test it before you sign. Ask to be shown it, on the template set actually being proposed, by somebody who is not a developer: build a new page in front of you, then reorder the sections on it. A demonstration of editing existing text answers a different question.

The second argument is the ecosystem. Common commercial requirements — taking a booking, selling something, putting a members' area behind a login, routing a form into a CRM — already have maintained solutions, and rebuilding one from scratch spends budget on a problem somebody else has already solved. The word carrying the weight there is maintained, and you can check that yourself rather than taking it on trust.

• When was it last updated, and which version of WordPress does it claim to be tested against? Something untouched across several core releases is a decision waiting to happen.
• Is there a company behind it with a paid tier, or one person doing it as a favour to the internet? A business model is no guarantee, but code nobody is paid to maintain has no particular reason to stay maintained.
• Does the support forum show recent threads with replies from the author, or recent threads with no reply at all?
• If it stores data — bookings, submissions, memberships — can that data be exported without the plugin? If not, removing it later means losing what it holds.
• Does anything already installed do the same job? Overlap is how a plugin surface grows without anybody deciding to grow it.

The third argument is succession, and it is commercial rather than technical. If the relationship with whoever built the site ends, somebody else has to be able to take it over. That is a question to put to every option on the table, including the bespoke one, and there is a way to ask it properly further down.

It is also worth retiring the idea that WordPress is only for brochure sites. Prize Queen runs on WordPress and WooCommerce, extended with a custom-built games engine plugin and bespoke interactive game functionality. The ceiling is higher than the framing suggests. The question is whether you want to spend your budget raising it.

Where weight lands, and interfaces that are not pages

Performance first, stated carefully. Neither platform starts at zero. A Next.js app ships a JavaScript runtime for its router and for any interactive component, along with the data needed to hydrate it, before you have added anything at all. A lean WordPress theme with no page builder can ship very little. The starting position is not where the difference lives.

The difference is where new weight lands. A WordPress plugin registers its stylesheet and script against the front-end enqueue hook, and that hook runs on every page request. Whether the plugin restricts its assets to the pages that use the feature is the author's choice; where it does not, the theme has to dequeue them template by template, and keep doing so as plugins are added and updated. In Next.js the App Router splits code by route, so a component no route imports is not in that route's bundle, and server components are never sent to the browser at all.

Neither behaviour is automatic. A disciplined WordPress site is fast and an undisciplined Next.js one is not. What differs is the direction the default pushes when nobody is paying attention, which is a reason to plan maintenance differently rather than a reason to pick a platform. Speed is a property of the build and of what gets added afterwards, and that is precisely why it makes a poor tie-breaker: whichever you choose, somebody has to keep deciding what is allowed to load.

The second case for Next.js is an interface that is not really a page — a configurator, a quoting tool, a catalogue the visitor keeps filtering, anything where the visitor accumulates state as they go. WordPress can host these. It has a REST API, and a page template can serve an application perfectly well. The question is what the arrangement looks like afterwards. Mounted into a template, the interactive part is maintained by whoever wrote it while the CMS manages only the page around it: an editor can move the block but cannot change what it does. If that surface is the point of the site rather than a feature on one page of it, build the site around the surface instead of around the pages.

The third case is where the thing has stopped being content altogether: accounts, records, a process with rules and permissions behind it. Then the shortlist is wider than these two rather than narrower. Next.js is itself an application framework and can be the answer; Laravel is another; what decides between them is the data model, the permissions and who operates the result, not the front end. Widen the question before the build rather than during it.

The corresponding limit: a marketing site that publishes occasionally and has a contact form does not need any of this, and the budget spent on it buys nothing the business will notice. Being able to change a page without a developer is worth something too, and the same money does not stretch to both.

The standing costs of each choice

Choose Next.js and editing has to be arranged deliberately. Three arrangements are worth knowing about, and each costs something different.

• A headless CMS. Editing content inside existing templates stays familiar; composing a new page layout does not, because the layout lives in the front-end code — so the thing WordPress is strongest at is the thing this arrangement gives up. It is also a second vendor, a second bill and a second permission model, and where it is self-hosted rather than a hosted service, a second thing to host and upgrade as well.
• Content kept in structured files and changed by a developer. Reasonable where the copy moves rarely — this site is built that way. It becomes a bottleneck the moment somebody in marketing needs a page live at short notice.
• A purpose-built admin over your own database. More to build, nothing to configure around, and it fits exactly — which also means it fits only you, so the maintenance is entirely yours. Worth considering when the content is really records rather than pages.

One thing to settle before launch rather than after: the delay between an editor pressing Update and the public page changing. This is not a property of going headless. It is a property of caching and of how the page is rendered. A route rendered on request reflects the change on the next visit. A statically rendered one changes when it is rebuilt or revalidated, which may run on a timer or be triggered on demand when content is saved. A WordPress site behind full-page caching has the same lag for the same reason. What matters is that somebody has decided which of those it is, and told the person pressing the button.

• What is the delay between Update and the page changing, on the pages that change most often?
• Is the rebuild triggered by the CMS when content is saved, or does it run on a timer?
• What happens when the trigger fails — who notices, and how does an editor force it through?
• Is there a preview that shows an editor the change before it is public?

The other standing cost on the Next.js side is upgrades. Dependencies release major versions, and skipped upgrades compound, because each one assumes the one before it. A codebase that has sat still through several of them is a project to bring current rather than a task. That makes it a contract question more than a technical one.

• Who applies major-version upgrades, at whose cost, and on what cadence?
• Is that inside the retainer, or billed separately each time it comes round?
• If the relationship ends part-way through a cycle, what state is the codebase handed over in?

Choose WordPress and the standing cost is the plugin surface. It grows. Every plugin is code you did not write, running on requests you did not anticipate, needing updates somebody has to apply — and nothing notifies you when an author stops maintaining one, which is why the checks above are worth running against what is already installed rather than only against what gets added. Budget for that maintenance at the start. The alternative is meeting it as an unplanned invoice after something has already broken.

Neither list disqualifies anything. They are the standing costs of each choice. Pick the one you will actually pay.

Questions to answer before anyone mentions a platform

Answer these about your own business, in this order, before you take a recommendation from anybody, us included. Each one names something you can go and look at.

• Who edits, and what do they edit? Open the CMS user list, then open the page revision history. The revision history names who changed what and when, which is a better answer than asking people to remember. Then split what you find: changes to text and images inside pages that already existed, or new pages with layouts that did not. Publishing into a template is served well by either platform. Composing a new layout without a developer is where they diverge.
• What is plugged in, and would it survive a move? List every integration, then sort each one by where its data lives and who you hold the account with. If you log in to that company directly, pay them directly, and their documentation describes an API, it is a hosted service and it travels. If it arrived as a plugin, its data sits in your own database, and the only way to reach it is the plugin's own admin screen, it does not travel and has to be rebuilt. Where you cannot tell, ask the provider one question: is there an API and a plan that is not tied to WordPress? Price those rebuilds separately from the front end, because the front end is the part everyone quotes for.
• Are you selling physical goods with stock, tax and shipping rules? Then the commerce platform largely decides the stack rather than the other way round. Reimplementing tax and shipping logic that already works is work with nothing visible to show for it at the end.
• Is anything on next year's roadmap an application rather than a page? A customer portal, an account area, a quoting tool — anything with a data model and permissions behind it. If so, settle it now, because it changes the shortlist rather than simply adding to the build.
• If the developer who builds this disappeared, who picks it up? Do not accept an assurance. Ask whoever is quoting to name two other firms who could take the codebase over, and ask what those firms would be handed — repository, documentation, environment setup. Then look at whether the skills involved appear in ordinary job adverts and contract listings for the stack being proposed. Ask it of every option, including the bespoke one. A short answer is not required; a known one is.

Performance is not on that list. Not because speed does not matter, but because it does not separate these two platforms — it is decided by the build and by what is added to it afterwards, rather than by the name of the software.

When the answer is to repair what you already own

Three complaints bring people to this comparison: the site is slow, it looks dated, or it is awkward to edit. A rebuild addresses all three. So can a repair.

The question that decides between them is not which platform is faster. It is whether the cause of the complaint is attached to the platform or to what was put on top of it. Causes attached to the platform move when you move. Causes attached to practice — a plugin installed for every new requirement, images uploaded at whatever size the camera produced, a bought theme nobody has maintained — stay with the people rather than the software. A rebuild replaces the platform. It does not replace the practice, and where the practice was the cause, the new site inherits it.

So take the three complaints separately, in this order, before agreeing to anything.

• Slow. This is a diagnosis rather than a platform choice, and it should be finished before the platform is discussed at all. The only part of it that bears on this decision is whether the cause would come with you.
• Dated. Appearance is templates, typography and structure. It can be replaced without replacing the foundation underneath, and the content model survives that kind of work, which is what makes it a smaller job than a platform move.
• Awkward to edit. Sometimes the fields and blocks are wrong rather than the platform. Ask whether the person who finds it awkward has ever been shown the site's own editing model, and whether the templates were built around the content or the content was forced into a theme somebody bought.

The case that does justify a rebuild is structural: the content is not modelled. Every page is a one-off, each service exists as layout somebody assembled by hand rather than as a record with fields, and adding another means repeating the assembly. Optimisation does not fix a structure that does not match the business. That is a rebuild — and it may well finish on the same platform you are already using, which is worth knowing before the conversation turns into a platform conversation.

It is worth saying plainly that this can end with you buying nothing. If the four inputs point at the platform you are already on, the integrations all travel, the roadmap holds no application, and the complaint turns out to be a template or a single plugin somebody installed, then there is no platform decision to make and the work left is small enough to hand to whoever already looks after the site. Finishing this and doing nothing is a legitimate outcome.

How to test the recommendation you are given

However you ask, the recommendation arrives with a reason attached. These are the tests that separate a decision from a preference.

• Ask for the case against the platform being recommended. A useful answer names a trade-off you would actually feel — the publish lag, the plugin surface, the cost of editing autonomy — and explains why it is worth accepting in your situation. A caveat that would apply to any project is not an answer.
• Ask what would have to be different about your business for the other answer to win. Somebody who has weighed it can describe that case in your terms. Somebody who has not will describe your business back to you.
• Ask which of the four inputs they established before deciding, and what they found. If the recommendation arrived before anybody looked at your revision history or your integration list, it was not derived from your business.

None of that requires you to know the technology. It requires you to know your own business better than the person quoting for it, which you already do.