In a traditional WordPress site, WordPress stores the content and also renders the pages. In a headless build, WordPress only stores and manages content, and exposes it through the REST API or GraphQL. A separate front end fetches that content and builds the pages, apps or feeds people actually see.
When it earns its keep
- The same content has to reach several places: a website, an app, kiosks, partner feeds or other sites
- The front end is a product in its own right, with a team that wants modern tooling and fast release cycles
- Content from WordPress has to be combined with data from other systems on the same pages
- Performance or traffic spikes demand static or edge-rendered pages beyond what caching alone gives you
- You want to be able to change the front end, or the CMS, later without replacing both
What it costs you
You now have two applications to build, host, secure and update instead of one. Much of what WordPress gives you for free has to be rebuilt in the front end: preview, menus, search, redirects, SEO metadata, forms and the way blocks turn into pages. Plugins that change what visitors see generally stop working, because WordPress no longer renders the pages.
The editor experience is where headless projects most often disappoint. If preview is slow or inaccurate, or editors cannot see how a block will look, they lose trust in the system. Getting preview right needs to be planned from the start, not left until the end.
Headless is an architecture choice, not an upgrade. It should solve a problem you can name.
The middle ground
Many organisations do not need fully headless. A traditional WordPress site built with structured content, custom blocks and a clean API can serve an app or a partner feed alongside the website. Some parts of a site, such as a search experience or a calculator, can be built as separate applications inside otherwise ordinary pages. That keeps one system for most of the work and adds complexity only where it pays.
- Which channels besides the website need this content, now and in two years?
- Who will build and maintain the front end, and do they already work in that framework?
- How will editors preview content, and how close to the live page must it be?
- Which plugins do you rely on that affect the front end, and what replaces them?
- What would a well-built traditional site fail to do for you?
We build WordPress both ways. In Discovery we look at your channels, team and content model, and recommend headless only where the evidence supports it.
