Headless WordPress: when it makes sense and when it’s overengineering

A few months ago, a client asked us for “a headless website with WordPress and Next.js”. When we asked why headless, the answer was: “because it’s more modern and scales better”. We explained that their project, an informational business site with 50 pages and a blog, didn’t need headless, and that the “scalability” they’d gain was negligible. The complexity it added, on the other hand, was huge.

In the end we built it with traditional WordPress and Elementor. The project was delivered in 6 weeks, not 14. It cost half as much. The client edits their own content and doesn’t have to call us to change a comma.

Headless WordPress is a powerful tool for specific cases. But it has become a buzzword that sells unnecessarily complex projects. Knowing when it fits and when it doesn’t saves you money. And headaches.

What “headless” means

Traditional WordPress is “monolithic”: the backend (where you manage content) and the frontend (what users see) are coupled. You use PHP themes that generate HTML directly.

Headless splits them:

• WordPress is only the CMS. It manages content.
• The frontend is a separate application (React, Vue, Next.js). It requests content through an API.
• The frontend generates the HTML. WordPress never sees it.

The theoretical advantage: total flexibility on the frontend. Optimized performance. The same content for the website, a mobile app and digital signage.

The real cost: 2 systems to maintain. More complex deployments. Content editors suffer. A huge technical dependency.

When is headless worth it?

After years of seeing headless projects succeed and fail, these are the cases where it really shines:

Complex multichannel experience

You need the same content on the web, a native mobile app, a desktop application and who knows what else. WordPress acts as the single source of truth, distributed through an API to every frontend.

Example: a publisher that publishes on the web, an iOS app, an Android app, a newsletter and syndication to partners. Headless justifies the cost here. The content really is reused.

Highly interactive frontend

Applications where the user experience is closer to an app than to a traditional website: complex transitions, persistent application state, real-time interactions.

Example: a 3D product configurator with complex state, where the user spends 10 minutes interacting without any page reloads.

Extreme performance

When every millisecond counts and you need aggressive optimizations: static generation, edge caching, route preloading. A modern frontend (Next.js, Astro) can do this better than traditional PHP WordPress.

Example: a high-volume online store where load speed directly affects conversion and every tenth of a second counts.

Specialized technical team

You have frontend developers experienced in React or Vue who want to put that expertise to use. Having them learn PHP and WordPress themes would cost more than maintaining a separate frontend.

When headless is overengineering

On the other hand, these are the cases where we see headless sold inappropriately:

“I want the website to be faster”

A well-optimized WordPress site (caching, good hosting, lightweight images) loads in under 1 second. The problem is almost never PHP. It’s heavy content or poor configuration. Before going headless, audit your slow site. The architecture is probably not the culprit.

“I want to use modern technology”

React isn’t better than PHP. It’s different. For an informational site, PHP serving plain HTML works. It’s proven, simple, and any WordPress developer can maintain it.

“I want my marketing team to be able to edit”

Here’s the irony: headless usually makes content editing harder. WordPress visual page builders (Elementor, WPBakery) don’t work in a headless setup. Content is edited in structured fields, and the frontend renders it.

If your marketing team wants to “drag and drop” elements on pages, headless takes that away from them.

Small and mid-sized sites

If you have fewer than 500 pages, fewer than 10,000 visits a day and mostly static content, headless is using a sledgehammer to crack a nut.

The hidden costs of headless (that nobody tells you about)

Headless vendors emphasize the benefits and play down the costs. Let’s be honest about them:

Development cost. In our experience, headless costs 2 or 3 times more than traditional WordPress. 2 systems to integrate. More complexity. More points of failure.

Maintenance cost. Security updates: 2 systems. Frontend changes: you need a developer. Marketing can’t touch the design from WordPress.

Hosting cost. You need infrastructure for the frontend (Node.js) plus the WordPress backend. More complex. More expensive.

Technical dependency cost. Any change, however small, needs a developer who understands the whole stack. You can’t just hire any WordPress freelancer.

Time cost. Headless takes longer. To develop, to debug, to launch.

Hybrid alternatives

It’s not all black and white. There are middle-ground architectures:

WordPress with a static frontend. You use WordPress as the CMS and generate a static site (with plugins like Simply Static). You get WordPress’s ease of editing with the speed of a static site. It’s not pure headless, but it captures many of the benefits without the complexity.

Next.js with partial WordPress. You use Next.js only where you need it (for example, an interactive app). Everything else stays on traditional WordPress. The best of both worlds.

Headless with a visual page builder. Some frameworks built for headless WordPress, such as Faust.js, try to win back part of the visual experience (block rendering, previews). They work, but they add yet more complexity.

Frequently asked questions

Is headless more secure?

Partly. Separating backend and frontend reduces the attack surface. But it adds complexity and new vulnerabilities. It isn’t more secure on its own. It depends on how you implement it.

Can I easily migrate from traditional WordPress to headless?

No. You’re rebuilding the frontend from scratch. The content migrates. The theme, the page builders and the visual customization don’t.

Does headless improve SEO?

Done badly, it makes it worse. Google runs JavaScript, but a poorly built frontend can be invisible. Next.js helps with SSR, but it adds complexity.

Should I use GraphQL or the REST API?

GraphQL is more flexible, which suits complex data. REST is simpler and enough for straightforward cases. It depends on how complex your queries are.

Conclusion

Headless WordPress is a legitimate, powerful tool for specific cases. But it has been oversold as a universal solution. Most business websites work better with traditional WordPress.

The right question isn’t “should I use headless?” but “what problem am I solving, and is headless the most efficient way to solve it?”

If you’re considering headless, we can evaluate it together. Sometimes it’s the right call. Sometimes it isn’t. Sometimes a hybrid solution is better. What matters is deciding with information, not with buzzwords.