Headless WordPress: when it makes sense and when it's just complication

Headless WordPress is one of those expressions that lands on a business owner's desk from a technical article or an agency's quote, often without an honest explanation of what it involves. The idea is to separate the CMS from the site visitors see: WordPress stays behind the scenes managing content, while the frontend is a separate application, usually built with frameworks like Next.js, that reads the content through an API. It's an architectural choice with concrete benefits and equally concrete costs: let's look at both.

How a headless WordPress works

In a classic WordPress, the same system does everything: it manages the content and generates the HTML pages with the theme. In a headless WordPress the theme disappears: editors keep working in the panel they know, but the content is exposed through an API (the REST API included in WordPress, or GraphQL via a dedicated plugin) and a separate application turns it into pages. The two systems can live on different servers: the CMS reachable only by the editorial team, the public site served as static pages or from optimized infrastructure.

The real benefits

When the headless architecture is justified, the benefits show:

• performance: the frontend can be pre-generated and distributed on a CDN, with load times hard to achieve with a WordPress theme loaded with plugins;
• security: the WordPress panel isn't exposed to the public at the same address as the site, and the attack surface shrinks;
• freedom on the frontend: the design isn't constrained by what a theme allows, and developers work with modern tools;
• content reuse: the same APIs can feed the website, a mobile app and other channels without duplicating anything.

For anyone who publishes a lot and cares about speed, these are serious arguments, not fashion.

The hidden costs nobody puts in the quote

The flip side is that with headless you double the systems to build and maintain. The pain points we see most often:

• content previews stop working out of the box: they must be reimplemented, and editors notice immediately;
• many plugins become useless or partial, because they act on the theme that no longer exists: SEO, forms, caching and page builders must be rethought;
• you need double skill sets: someone who can work on WordPress often doesn't know the JavaScript frontend, and vice versa;
• every structural change touches two projects, so maintenance time and costs go up;
• hosting splits in two: one environment for the CMS, one for the frontend.

On a brochure site or a company blog of normal size, these costs almost always outweigh the benefits.

When it makes sense and when it doesn't

In the projects we manage, headless is justified in specific scenarios: high-traffic editorial portals where speed is a competitive factor; content to distribute across multiple channels, for example website and mobile app together; strict requirements on security or on separating the editorial side from the public; frontends with complex interactions a theme couldn't support. If instead your site is a brochure site with a blog, a medium-sized eCommerce store or an institutional site, a well-maintained traditional WordPress, with a lightweight theme, a serious caching strategy and a few well-chosen plugins, achieves more than good performance at a fraction of the cost. The sensible order is this: first optimize what you have, then evaluate the architecture, not the other way around.

The questions to ask before signing

If a vendor proposes a headless site, three questions clarify the situation right away. How will previews and the editors' daily work function? Who will maintain the two systems and at what annual cost? Which specific problem of the current site does headless solve, and why can't it be solved more simply? If the answers are vague, the proposal comes from the desire to use a technology, not from your needs.

Choose the architecture with someone who uses both

We work both on traditional WordPress and on modern frontends with Next.js, so we have no technology to defend: we recommend headless when the numbers justify it and advise against it when it's just complication. If you're considering a new site or a rebuild, in our websites and eCommerce service we start from your goals and choose the architecture accordingly. Book a free call and let's see together what your project needs.