Engineering
Headless architecture
Also called
- Decoupled
- Headless CMS
In a traditional CMS the content store and the thing that renders pages are one system: WordPress holds the content and also decides what the page looks like. Headless splits them. Content lives in a system with an API, and one or more front ends read from it.
The value is not novelty. It is that the same content can drive a website, a mobile app, a kiosk and a partner feed without being re-entered, and that either half can be replaced without rebuilding the other. The cost is a second system to operate and a more involved preview story for editors.
It is the right answer when content genuinely serves more than one surface, when the front end has performance requirements the platform cannot meet, or when the editorial team and the engineering team need to move at different speeds. It is the wrong answer when there is one website, one team and no integration pressure — in that case you have bought complexity and paid for it in editor friction.
Choosing headless when you do not need it adds cost to every content change for years. Choosing coupled when you do need it means rebuilding when the second channel arrives.
Commonly misunderstood
What people get wrong
The claim
“Headless is faster.”
What is actually true
Headless makes it *possible* to be fast, because you control the rendering. A badly built headless site is slower than a well-built WordPress one. The architecture removes a ceiling; it does not raise the floor.
Related terms
Next step
Working through a headless architecture decision?
Tell us the situation. We will give you the tradeoffs as we see them, including when the answer is that you do not need what you are being sold.
No pitch deck. A 30-minute conversation about what you are trying to achieve.