What you will take away
- Model content as reusable structures, not as pages with a blob of HTML.
- Preview and publishing workflow are the features editors judge you on.
- If one website is the only channel, a traditional CMS may still win.
The case for decoupling
A traditional CMS owns both the content and the pages that render it, which is efficient until you need the same content on a mobile app, a kiosk, an email or a partner feed. Then the content is trapped inside markup written for one layout.
A headless CMS stores structured content and serves it over an API. Any number of front ends consume it, and the website becomes one consumer rather than the system of record.
Model content, not pages
This is where most implementations go wrong. If a content type is "page" with a rich-text field containing markup, you have rebuilt the coupling you were trying to remove and added an API call. The content is still shaped for one layout.
- Define types by what the thing is - product, article, event, author, location.
- Break out the fields a consumer might need separately, so a mobile app can take a short version.
- Use references between types instead of duplicating information across entries.
- Keep presentation choices out of the content, and hold them in the front end where they belong.
If your headless CMS has a field called "page HTML", it is a traditional CMS with an extra network hop.
The editor experience decides adoption
Editors lose the "what you see is what you get" page they had before, so preview has to be built deliberately - a real rendering of the draft in the actual front end, reachable in one click from the editing screen.
They also need scheduled publishing, a sensible draft and review workflow, and permissions that match how the team works. These are not extras; they are what determines whether the platform is used as intended or worked around.
Delivery, caching and invalidation
Do not call the content API on every page view. Statically generate what is stable, cache at the edge, and use webhooks from the CMS to rebuild or purge exactly what changed when an entry is published.
Invalidation is the hard part: one changed author name may affect hundreds of pages. Map those dependencies during the build rather than resorting to a full rebuild for every edit, which becomes untenable as the site grows.
When not to go headless
If there is one website, a small team, no second channel on the horizon and heavy reliance on plugins for forms, search or commerce, a traditional CMS may deliver more for less. Headless adds a front end you now own and maintain.
The switch pays off when there is genuinely more than one consumer of the content, when the front end needs freedom the CMS templates cannot give it, or when performance and security push you towards a statically generated site with no CMS on the public path at all.
OrbixEdge Engineering
The engineers who build and run the systems we write about - platform, cloud and product teams shipping for clients in retail, health, logistics and fintech.
