The question "Next.js or WordPress?" usually starts in the wrong place.
I'd ask something else first:
what does the website need to do, and who's going to work with it afterwards?
You can build fast, slow, easy-to-maintain or impossible-to-touch websites with either WordPress or Next.js.
The technology doesn't decide that on its own.
And they're not quite the same kind of tool, either.
WordPress is a content management system. It comes with a database, an admin panel, a visual editor, themes and a huge plugin ecosystem.
Next.js is a React framework for building web applications. It gives you control over the interface, rendering, data and logic, but it doesn't include a CMS out of the box where the client can log in and edit their website.
That difference explains a good part of the choice.
When I'd choose WordPress
WordPress makes a lot of sense when editing content is a big part of the project.
For example:
- the team publishes articles or pages frequently;
- several people need to edit without relying on a developer;
- the website is mainly editorial;
- you need standard features that are already well solved;
- the team is already comfortable with WordPress.
Its block editor lets you change content and build pages from the admin panel itself.
That doesn't mean a WordPress website has to use a generic template.
You can also build a completely custom theme.
The advantage is that content management is already part of the system.
When I'd choose Next.js
Next.js starts to make more sense when the interface or the way the website works needs a fair amount of control.
For example:
- a very specific visual direction;
- interactions that are an important part of the experience;
- data coming from several sources;
- integrations with external tools;
- private areas;
- custom logic;
- a website that's starting to behave more like an application.
It also lets you decide quite precisely how each page is generated and delivered.
But that doesn't mean Next.js is automatically fast, better for SEO or easier to maintain.
You can build badly with any technology.
What if the client needs to edit content?
Using Next.js doesn't mean giving up an admin panel.
You can connect it to a CMS.
The content can live in Sanity, Strapi, WordPress, Shopify or another system, while Next.js takes care of displaying it.
That way the team can edit products, articles, projects, services or any other content we've set up for them to manage.
What will usually still need a developer are changes to:
- components;
- templates;
- logic;
- integrations;
- how the application behaves.
Autonomy doesn't depend only on the framework.
It depends on how the system has been designed.
Headless: WordPress and Next.js can work together
Choosing one doesn't always mean ruling out the other.
WordPress can be used purely to manage content and deliver that data through its API.
Next.js can then use that data to build the frontend.
This is what's usually called a headless architecture.
It can make sense when a team wants to keep an editing experience they already know but needs a highly customised frontend.
It also adds complexity.
Now you have two systems to connect, deploy and maintain.
That's why I wouldn't go headless just because it's technically interesting.
It has to solve a real problem.
Both need maintenance
This is a difference that's sometimes explained quite badly.
With WordPress you have to maintain:
- WordPress itself;
- plugins;
- the theme;
- the server;
- compatibility between all those pieces.
With Next.js there's maintenance too:
- the framework;
- React;
- dependencies;
- integrations;
- the runtime;
- the platform it's deployed on.
A static Next.js website, or one with very little server logic, may have fewer moving parts in production than a complex WordPress install.
But that doesn't mean it stays frozen forever.
The question isn't:
"which one doesn't need maintenance?"
They both do.
The question is which pieces we're agreeing to maintain, and who's going to look after them.
Performance and SEO don't decide it on their own
You can get very good performance out of WordPress.
You can also build an unnecessarily heavy Next.js website.
The same goes for SEO.
WordPress can properly generate:
- metadata;
- sitemaps;
- canonicals;
- structured data;
- indexable pages.
So can Next.js.
Neither of them comes with an SEO strategy just because you've installed it.
The architecture, the content and the implementation still need to be well thought out.
Quick comparison
| WordPress | Next.js | |
|---|---|---|
| Content management | Built in | Needs adding if required |
| Custom design | Yes | Yes |
| Standard features | Large plugin ecosystem | Integrations or development |
| Custom logic | Possible through development | Very flexible for custom applications |
| Maintenance | Core, plugins, theme, server | Framework, dependencies, integrations, runtime |
| Performance | Depends on implementation and hosting | Depends on implementation and architecture |
| Technical SEO | Can be done very well | Can be done very well |
The table has no winner.
That's the point.
The questions that would decide it for me
Before choosing, I'd ask:
- Who's going to edit the website afterwards?
- How often?
- Are the features we need fairly standard?
- Does the visual experience need a lot of custom development?
- Is there external data or tools to integrate?
- Are we building a website, or is it starting to look like an application?
- Who's going to maintain it two years from now?
Once you've answered those, the technology is usually much easier to decide.
What we use
At Roke we mainly work with Next.js because it tends to fit the projects we do: custom design, bespoke architecture, integrations and a good deal of control over the implementation.
That doesn't mean Next.js is the right answer for every website.
If a business mainly needs to publish a lot of content on its own and WordPress solves that well, using Next.js just because we prefer it would be making the decision backwards.
The technology should come from the requirements.
If what you mainly need is a website that represents your business well, you can see how we approach a Brand Website.
And if what you're building involves logic, internal processes or features of its own, we're probably talking about Custom Software.
We write about decisions that come up in real projects: how to structure a website, how to capture demand and when technology can simplify a business.