TIL: When Headless WordPress Makes More Sense Than Classic WordPress

For a long time, our WordPress projects followed the classic path. Install a theme, add plugins, create custom fields, build a few custom templates, then patch the gaps with custom PHP when the project needed something more specific.

It worked. Most of the time.

But after a while, a pattern started to appear. Every new custom website needed a mix of backend logic, custom post types, APIs, content rules, layout fixes, plugin checks, theme changes, and small pieces of glue code that only a few people could safely touch. The content side was fine. Editors could still work with pages, blocks, and familiar WordPress tools. The hard part was everything behind that.

One person usually had to own the custom backend work. Another person could take care of maintenance, updates, content changes, and page building with the visual tools. That split made sense, but it also created a bottleneck. Not a dramatic one. Just the kind that slowly appears when the same person is needed for every custom feature, every integration, and every “can WordPress do this?” question.

So I started looking at the problem from a different angle. Maybe WordPress was not the issue. Maybe the issue was asking WordPress to do too much.

The research led to a simpler idea: keep WordPress where it’s strong, and move the UI somewhere else.

In this setup, WordPress remains the CMS. It handles content, users, editorial workflows, media, custom post types, and any backend logic that actually belongs there. The frontend is built separately with React or Next.js, using WordPress as a content source through REST API or GraphQL.

That small shift changes a lot.

The WordPress part becomes smaller and easier to maintain. Fewer theme hacks. Less pressure to bend page builders into custom application screens. Fewer frontend decisions trapped inside PHP templates. The CMS can stay closer to its main job, which is managing content.

The UI becomes a normal frontend project. That means the rest of the team can work on it without needing deep WordPress knowledge. React and Next.js are already familiar to more developers, so the work can be shared more easily. Components can be reused. Testing is clearer. The build process is more predictable. And when the design needs something custom, we don’t have to fight the theme layer first.

There are tradeoffs, of course. Headless WordPress is not a magic fix. You need to think about previews, routing, caching, SEO, deployment, redirects, and how editors will feel when the frontend is no longer the active WordPress theme. Some plugins also lose part of their value when they expect to control the rendered page.

But for projects with heavy custom UI needs, the tradeoff seems worth it.

The biggest benefit is not that the stack sounds more modern. That would be a weak reason to change anything. The real benefit is that the work is split in a cleaner way. WordPress handles content and backend needs. React or Next.js handles the interface. Each part does less, but does it better.

This also makes planning easier. A custom feature no longer has to be framed as a WordPress feature first. It can be treated as a product feature. The backend exposes the data. The frontend decides how to show it. That sounds small, but in day-to-day work it removes a lot of friction.

My main takeaway is this: classic WordPress still makes sense for many websites. Simple marketing sites, blogs, and content-heavy pages can work perfectly fine with a normal theme and a good editor setup. I wouldn’t move everything to headless just because we can.

But when a WordPress project starts to look more like a web app, or when most of the work happens around custom UI and custom logic, headless starts to make more sense. It protects WordPress from becoming a messy all-in-one tool, and it opens the frontend work to more people on the team.

That’s the part that changed my mind. Headless WordPress is not about replacing WordPress. It’s about using it with more discipline.