WordPress or Next.js for a content-led site.

The two questions that decide it

Platform debates usually run on technical preference. The two questions that actually predict the right answer are more mundane.

Who edits this site every day?

If the answer is non-technical editors publishing regularly, that constraint dominates everything else. A publishing workflow that requires a developer, a pull request, or a build to change a paragraph will reduce output — not in theory, in practice, permanently. Teams route around friction by publishing less.

If the answer is that content changes rarely, or changes through a data pipeline rather than a person, this constraint disappears and the calculus changes completely.

Where does the content come from?

Hand-written pages and generated pages are different problems. A site of two hundred articles written by people wants a good editing experience. A site of fifty thousand pages generated from a structured dataset wants a good data layer, and the editing experience is nearly irrelevant because nobody is editing pages individually.

Most sites are one or the other. The genuinely difficult cases are the hybrids — a large generated catalogue with editorial content layered over it — and those are where the platform decision deserves real analysis rather than a default.

We run both across our portfolio: WordPress for the editorially-driven properties, Next.js where the site is a front end over a continuously updating dataset. The split has held up, and it maps almost exactly onto those two questions.

Where WordPress wins

• Non-technical publishing. The editing experience is familiar, editors can be onboarded quickly, and publishing does not involve engineering. This is the single biggest advantage and it is routinely dismissed by technical evaluators who will not be the ones using it.
• Time to useful. A capable content site can be running in days. For a site whose value is the content rather than the container, that difference is real.
• The ecosystem. Multilingual, e-commerce, structured data, redirects, and analytics are solved problems with maintained solutions. You are not building infrastructure that hundreds of thousands of sites already have.
• Hiring and continuity. Finding someone who can maintain a WordPress site is straightforward, and it stays straightforward. This matters more than it seems on a five-year view.
• Commerce. For a store where product management is done by a merchandiser rather than an engineer, WooCommerce and its ecosystem are hard to beat on total cost.

The costs are equally real: performance requires deliberate work rather than arriving by default, plugin sprawl accumulates into fragility, security demands ongoing maintenance discipline, and genuinely programmatic content is awkward to model — possible, but you will be working against the grain.

Where Next.js wins

• Data-driven pages. When pages are generated from a database or a pipeline rather than authored, having the site be an application over that data is the natural shape rather than a workaround.
• Performance headroom. Rendering strategy is a per-route decision, so the parts that can be static are static and the parts that must be dynamic are dynamic. Fast is achievable in WordPress and closer to the default here.
• Complex interactivity. Search interfaces, filtering, maps, personalisation, account areas — anything where the page is genuinely an application benefits from being built as one.
• Fine control over the rendered output. Structured data, metadata, canonical and hreflang handling, and internal-linking systems are all code you own rather than plugin behaviour you configure and hope about.
• Scale of URL count. Managing tens of thousands of routes from a data model is a normal thing to do, rather than something the CMS is being persuaded into.

And the costs: every editorial capability is something you build or integrate; a non-technical editing experience does not exist until you provide one; hosting and deployment are your responsibility; and the framework moves quickly enough that a site left untouched for two years will have a real upgrade project waiting.

The dividing line, stated plainly

For genuine hybrids, the tiebreaker we use is the maintenance model rather than the content model: who will own this in three years, and what will they be comfortable operating? A technically superior stack that the owning team cannot maintain degrades faster than a plainer one they can.

Headless: the third option, and its hidden cost

Headless — a CMS providing content over an API to a separately built front end — is often presented as taking the best of both. It can. It also carries costs that are usually discovered after the decision.

You now operate two systems rather than one, with a contract between them that has to be versioned. Preview becomes a feature you build rather than one you have. Many of the things the CMS ecosystem solved — redirects, sitemaps, multilingual routing, structured data — return as your responsibility, because the plugin that handled them was tied to the rendering layer you removed. And editor experience frequently degrades: editors lose the connection between what they are writing and what it will look like.

Headless is the right answer when you genuinely need one content source feeding multiple surfaces — a website, an app, a partner feed — or when editorial and engineering are separate organisations that need to move independently. It is the wrong answer when the motivation is that the front end should be React. That is a rendering preference, and there are cheaper ways to satisfy it.

SEO differences: real versus imagined

Platform choice is frequently justified on SEO grounds, and most of the reasoning is a decade out of date.

Largely imagined

• "Google prefers static sites." It does not. It prefers pages it can fetch quickly and render reliably, which either platform can deliver or fail to deliver.
• "JavaScript frameworks cannot rank." Server-rendered output is server-rendered output. The risk is client-only rendering of primary content, which is an implementation choice rather than a framework property.
• "WordPress is bad for SEO." An enormous share of high-performing content sites run on it. Poorly maintained WordPress is bad for SEO, which is a different claim.

Genuinely real

• Control over the emitted HTML. With Next.js you decide exactly what ships; with WordPress you are frequently negotiating with a theme and several plugins. This matters most for structured data and internal-linking systems.
• Performance as a default versus as a project. Both can be fast. One requires more deliberate ongoing effort to stay fast, particularly as plugins accumulate.
• Programmatic internal linking. Generating link relationships from a data model is straightforward in an application and awkward in a CMS. On a large site this is one of the highest-leverage things you can build.
• Indexing control at scale. Sitemap generation, governance over what earns a URL, and handling expired pages are all easier to get exactly right when they are code. We go into this in large-site SEO.
• Multilingual routing. Both can do it. Both can also break it in the same quiet ways — the failure modes are shared, and neither platform protects you from them.

If you are migrating, the platform is the smaller risk

Replatforming a site with existing search visibility carries a risk that has nothing to do with which platform you are moving to. Traffic losses in migrations are overwhelmingly caused by URL and content changes, not by the framework.

1. Preserve URLs wherever you can. The cheapest migration is the one where most addresses do not change. "While we are here, let us improve the URL structure" is the single most expensive sentence in replatforming.
2. Map every redirect before launch, from a real crawl and from search-console data — not from the CMS's list of published pages, which will not include everything that has traffic.
3. Keep the content genuinely equivalent. Pages that lose sections in translation to new templates lose rankings for the queries those sections covered.
4. Preserve structured data and metadata deliberately. These are commonly rebuilt from scratch and quietly reduced.
5. Verify after launch against search-console data, not against a crawl of the new site. A crawl tells you the new site is internally consistent; it cannot tell you what stopped working.

Then build the distribution layer

Whichever platform you choose, the site is where content lives — not how it gets seen. Search is the largest channel for content-led businesses, and it is also the slowest to compound. The distribution layer around the site is what fills the gap, and it is usually left as an afterthought staffed by whoever has time.

Running social manually works for one brand. It stops working at two or three, and it fails completely across several brands in several languages — which is the problem we had to solve internally. The answer that held up was systematic rather than editorial: content composed on a schedule, queued, and published by a worker that runs continuously, so consistency does not depend on someone remembering.

What is worth automating and what is not:

• Automate scheduling, queueing, and publishing. Mechanical, reliable, and the source of most of the time cost.
• Automate repurposing from existing content. Anything already published — an article, a product update, a data change — can generate a distribution item systematically rather than being rewritten by hand.
• Do not automate judgement about what is worth saying. This is where automated social produces output nobody engages with, and it is the part most often attempted first.
• Keep a human review step on regulated categories. Where advertising rules or platform policy constrain the message, a queue that publishes without review is a liability.

The build decision and the distribution decision are related more than they look: a site whose content is structured — real records with fields, rather than pages of prose — is dramatically easier to distribute automatically, because the distribution layer has something to read. That is an argument for taking the data model seriously on either platform.