If You’re Already Using Next.js, Why Are You Still Using WordPress?
The uncomfortable question agencies building headless WordPress sites should probably be asking.
Let me start with something important.
WordPress is not useless.
It didn't become the world's dominant CMS by accident. It has an enormous ecosystem, decades of development behind it, widespread editorial familiarity and thousands of developers who know how to work with it.
For traditional websites, those advantages made WordPress extraordinarily difficult to compete with.
But this isn't an article about traditional WordPress.
This is about headless WordPress paired with Next.js.
And once Next.js enters the architecture, I think we need to ask an uncomfortable question:
Why is WordPress still there?
WordPress's greatest strengths came from being WordPress
For years, the argument was simple.
Need SEO? Install a plugin.
Need forms? Install a plugin.
Need redirects? Install a plugin.
Need custom fields? Install something like ACF.
Need e-commerce? WooCommerce.
Need a page builder? Elementor, Divi, Gutenberg or another ecosystem.
Need security? Another plugin.
That convenience was one of WordPress's greatest competitive advantages.
Its frontend, CMS, themes, plugins and administration environment belonged to the same ecosystem.
Then the industry wanted something more.
We wanted React.
We wanted application-like interfaces.
We wanted sophisticated transitions, persistent layouts, component-driven design, Three.js, WebGL, GSAP, Motion, React Three Fiber and the enormous modern JavaScript ecosystem.
So what did we do?
We decoupled WordPress.
And that is where the argument becomes interesting.
Headless WordPress solves a problem by creating another one
A typical headless WordPress architecture starts looking something like this:
WordPress itself documents its REST API specifically as an interface through which completely separate applications can consume WordPress content.
There is nothing inherently wrong with that architecture.
It works.
The question is whether it is still the architecture you would deliberately choose if you were starting from zero today.
Because now you're maintaining two technological worlds.
You have a PHP application responsible for content and potentially plugins.
Then you have a TypeScript application responsible for the actual digital experience.
And between them is an API boundary that your development team must maintain.
The more sophisticated the frontend becomes, the stranger the relationship can become.
The plugin argument becomes weaker when WordPress loses the frontend
This is frequently overlooked.
A WordPress plugin operating inside a traditional WordPress website can control enormous portions of the experience.
But when WordPress becomes headless, your React application doesn't magically inherit everything a plugin would traditionally render.
An SEO plugin might manage metadata in WordPress.
Your Next.js application still needs to retrieve and render that information correctly.
A form plugin might define a form.
Your React frontend may still require components, validation, submission states, error handling, file handling and styling.
A redirect system may store redirects.
Something still needs to determine where those redirects execute in the new architecture.
The plugin can remain useful.
But “install plugin and feature appears on website” is no longer universally the proposition.
You deliberately removed WordPress from the frontend.
That's the point of going headless.
Then look at Payload CMS
Payload takes almost the opposite architectural position.
Payload 3 is Next.js native. Its Admin Panel and HTTP layer are built on Next.js, and Payload can be installed directly into an existing Next.js application.
Instead of:
Next.js application → network/API boundary → separate WordPress application
you can have:
The distinction becomes even more significant through Payload's Local API.
Server-side code, including React Server Components, can interact with Payload directly without requiring an HTTP request to a separate CMS. Payload describes this as direct database interaction without HTTP/network overhead.
That's not merely convenient.
It's architectural coherence.
The CMS becomes part of the application
This is where Payload becomes particularly interesting to designers and developers working together.
Suppose a designer creates:
Hero → Interactive Showcase → Product Grid → 3D Experience → Testimonials → CTA
Those ideas can become Payload blocks.
Those blocks can correspond directly to React components.
The schemas can generate TypeScript types.
The React application understands those types.
The frontend renders those components.
The CMS gives editors control over the appropriate content.
You're not trying to make the application conform to the historical assumptions of the CMS.
The CMS is serving the application.
That distinction matters enormously when you're designing something that isn't supposed to feel like a conventional website.
“But WordPress is cheaper.”
Initially?
It absolutely can be.
That's one of the strongest legitimate arguments for WordPress.
WordPress has benefited from decades of commoditisation. There are plugins, developers, hosting companies, themes, integrations and documentation for practically everything imaginable.
But cheap to start and cheap to operate as a sophisticated headless platform aren't necessarily the same thing.
Consider the complete system.
Plugin subscriptions.
Premium integrations.
Security products.
Headless-specific development.
API integration.
Frontend implementation.
Plugin compatibility.
Hosting for separate architectural layers.
Maintenance.
Developer intervention when something breaks.
Upgrades.
Technical debt.
The total cost is considerably more complicated than:
“WordPress is free.”
Now give Payload the same advantage WordPress has enjoyed
This is where the comparison changes completely.
Don't compare a mature WordPress ecosystem against an empty Payload repository.
Build the Payload ecosystem once.
Imagine an agency maintaining its own production platform containing:
Now add dozens or hundreds of reusable content and experience blocks.
Add templates.
Add established collections.
Add tested access-control patterns.
Add deployment automation.
Add a design system.
Now your next project doesn't begin from zero.
It becomes:
Configure. Compose. Brand. Extend. Deploy.
That is exactly the economic advantage WordPress has historically enjoyed.
Except now the agency owns the abstraction.
Every project can make the next project better
This is where the business model becomes more interesting than the CMS argument.
Traditional agency development frequently works like this:
Client requirement → custom implementation → deliver → repeat
A reusable Payload platform can instead work like:
Client requirement → reusable capability → platform improves → next project inherits capability
Build an excellent gallery once.
Improve it across projects.
Build your authentication architecture once.
Reuse it.
Build an e-commerce foundation.
Extend it.
Create animation primitives.
Reuse them.
Create sophisticated Three.js experiences.
Turn appropriate parts into reusable components.
The agency gradually accumulates intellectual property rather than merely accumulating completed websites.
After 20 projects, project 21 begins with the accumulated engineering knowledge of the previous 20.
That is an entirely different proposition.
And then there's design
This is where my objection to headless WordPress becomes much stronger.
Modern digital experiences increasingly behave less like documents and more like applications.
Think:
persistent interfaces
shared application state
animated route transitions
WebGL
Three.js
React Three Fiber
GSAP timelines
Motion
interactive canvases
real-time experiences
AI interfaces
complex configurators
customer portals
application dashboards
A sufficiently talented team can integrate these things with headless WordPress.
Of course they can.
That's not the argument.
The question is:
Why should they have to architect around WordPress in the first place?
If React and Next.js are already responsible for the experience, then the CMS should enable that application architecture rather than introduce another technological boundary that developers continually bridge.
“It looks like WordPress”
There's a reason this isn't usually a compliment in a design critique.
It doesn't literally mean somebody inspected the source code and discovered /wp-content/.
It usually means:
predictable.
template-driven.
section after section.
familiar interactions.
limited art direction.
another website.
That's not inherently WordPress's fault.
You can build an extraordinary WordPress website.
You can also build an extraordinarily boring Payload website.
Technology doesn't create creativity.
But technology absolutely affects how expensive it becomes to express creativity.
That's what I mean by a technological ceiling.
The question isn't whether something *can* be built.
Given enough engineering effort, almost anything can.
The question is:
How naturally does the architecture allow you to build it?
Payload doesn't make your Three.js animation
This distinction matters.
Payload isn't making your animations smoother.
It isn't replacing GSAP.
It isn't rendering your WebGL scene.
It isn't responsible for React's component lifecycle.
And it isn't the reason your Next.js application has sophisticated transitions.
That's the frontend architecture.
Payload's advantage is simpler:
it doesn't require that architecture to revolve around the CMS.
Your designer can conceive the experience.
Your React engineer can determine how that experience should work.
Your Payload architecture can provide the structured content, data, authentication and application logic required to support it.
The CMS becomes infrastructure rather than the creative boundary.
So why would I still choose headless WordPress?
There are legitimate reasons.
You might have an enormous existing WordPress content estate.
Your organisation may already have years of WordPress infrastructure.
Your editorial team may require it.
You may depend on a WordPress-specific integration.
Migration might cost considerably more than the benefits justify.
The client may explicitly require WordPress.
Those are real constraints and shouldn't be dismissed.
If WordPress is already deeply embedded in an organisation, headless WordPress can also be a sensible way of modernising the frontend without simultaneously replacing the entire editorial infrastructure.
That's a perfectly rational architectural decision.
But notice what most of those arguments have in common.
They're reasons to retain WordPress.
They're not necessarily reasons to introduce WordPress into a new Next.js application.
That's a very different question.
Greenfield changes the argument
Imagine there is no legacy system.
No migration.
No existing WordPress content.
No organisational requirement.
No WordPress-dependent business process.
You're starting a new digital product today.
You've already selected Next.js.
Your developers work in TypeScript.
Your frontend is React.
You want reusable components.
You want sophisticated interaction design.
You want the application to evolve.
You already maintain a library of Payload blocks and schemas.
You already have templates.
You already have authentication, SEO, forms, commerce and other common capabilities in your boilerplate.
Now ask:
What exactly is WordPress contributing that justifies introducing PHP, a separate CMS application and an API boundary into this architecture?
That's the question.
Not:
“Can WordPress do it?”
It can.
The better question is:
“Why are we making it do it?”
Headless WordPress is sometimes a bridge. Don't mistake the bridge for the destination.
Headless WordPress made enormous sense as the web transitioned toward React-based frontends.
Companies could preserve their existing WordPress infrastructure while adopting a modern frontend.
That's valuable.
But a migration architecture shouldn't automatically become the architecture we choose for completely new systems.
Payload represents something different.
It asks what a CMS should look like when the application itself is already built around TypeScript, React and Next.js.
Payload's documentation describes its Admin Panel as React/TypeScript using the Next.js App Router, while its Local API can operate directly from server contexts without an HTTP layer.
That's why comparing Payload with WordPress purely by counting CMS features misses the larger point.
They come from different architectural generations.
The real product isn't Payload
And this is perhaps the most important part for agencies.
Don't sell clients Payload CMS.
Most clients shouldn't care.
Build your own platform on top of it.
Your blocks.
Your components.
Your design system.
Your integrations.
Your commerce architecture.
Your animation system.
Your deployment pipeline.
Your accessibility standards.
Your security practices.
Your application patterns.
Your accumulated engineering knowledge.
That is the product.
Payload is part of the foundation.
And every project can make that foundation stronger.
The uncomfortable conclusion
WordPress won an enormous portion of the web because it made building websites accessible, repeatable and commercially viable.
That deserves recognition.
But we're now building things that increasingly aren't merely websites.
They're applications.
They're stores.
They're customer portals.
They're interactive experiences.
They're software products.
They're 3D environments.
They're interfaces connecting businesses, customers, data and automation.
And if you've already decided that Next.js should power that experience, then blindly carrying WordPress into the backend because “that's what agencies use” deserves scrutiny.
Especially when your alternative is a CMS/backend that can live directly within the technological environment you've already chosen.
For an existing WordPress organisation, headless WordPress may be an excellent bridge into the modern web.
For a greenfield Next.js project with a mature Payload ecosystem?
I would reverse the burden of proof.
Don't ask why you should replace WordPress with Payload.
Ask: