25+ websites in four weeks to a platform that actually grows with you
Landstede Groep
Headless CMS
Headless, but not by default
A headless CMS separates content management from content presentation. That sounds technical, and it is. However, it primarily represents a choice with implications for your costs, your management, and the way your editorial team operates.
Below you will read what a headless CMS is, when it truly offers you benefits, and when it might be better to avoid it. And if it is indeed the right solution, why you usually do not need a separate system for it.
What is a headless CMS?
A headless CMS is a content management system that separates the content management backend (the "body") from the presentation frontend (the "head"). Traditional CMSs combine these layers, intertwining content and presentation closely. In contrast, a headless CMS makes content accessible via an API (such as RESTful or GraphQL), allowing for flexible management of the presentation. This means that developers can deliver content to various channels such as websites, mobile apps, and more, without being constrained by a specific frontend technology.
Instead of providing a single fixed presentation format, the system delivers the content as data. What happens to it is determined per channel. The same product description can thus appear on your website, in an app, and on a screen in the showroom, without anyone having to enter it three times.
Traditional or headless
In a traditional CMS, content and presentation are tightly coupled. An editor sees how the page will look while writing, publishes, and that's it. One system, one place where things can go wrong.
With headless, you let go of that connection. You gain flexibility because each channel pulls what it needs. You trade simplicity for it, as the preview no longer comes automatically and you have two components to maintain instead of one.
This trade-off is the entire consideration. If you serve multiple channels with the same content, the flexibility pays off. If you have one website, you are paying for flexibility that you are not using.
When headless is not the answer
Headless is chosen more often than necessary. In many cases, the request stems from something other than the architecture, and you won't solve the problem by decoupling the CMS.
You want a faster site.
Speed rarely comes from the link between content and presentation. Hosting, image processing, and caching usually yield more benefits and cost a fraction.Your editorial team finds the current system inconvenient.
That's a matter of setup. Using headless actually makes editors' work heavier in practice, as the preview of a page does not automatically come along.You have one website.
Then you're paying for flexibility between channels that you do not have. You end up with two systems to maintain instead of one.A developer suggested it.
Ask what specific limitation will be resolved by this. If the answer concerns a preference for a framework and not a problem you’re currently facing, it’s not an architectural choice.
Headless becomes interesting when you truly need the same content in multiple places, and those places cannot share the same content. In that case, it's the cheapest solution available. Before that, it's not.
Advantages of a headless CMS
Flexibility and scalability
A headless CMS allows you to share content across different platforms, from websites to mobile apps and even IoT devices. This provides broader reach and efficient management of your content.Faster development - Developers can use modern technologies without the constraints of a coupled frontend. This means they can innovate more quickly and implement new features without being tied to outdated systems.
Enhanced security
The editorial environment does not need to be publicly accessible, which removes one attack vector. In contrast, you maintain an API and a separate application.Future-proof
An API-first approach ensures that you can easily integrate new technologies without significant restructuring. You can replace a channel without rebuilding the content. A new website does not mean having to enter everything again.
These advantages apply when you serve multiple channels. With just one website, they remain theoretical, and you only incur the costs of the exchange.
When it is worthwhile
Your content needs to go to an app or a system outside your website.
A product catalogue that needs to be available both on the site and in a field service app, for example.You are building a frontend that has no pages.
A configurator, a calculation tool or a portal where the content depends on who is logging in.You provide content to parties outside your own organisation.
Partners or members who display your information on their own site, without anyone having to retype it.
Umbraco case studies
In the vast majority of projects, the question of headless arises, but we often decide together not to pursue it, as the issue turned out to be elsewhere. At Landstede, it involved 25 websites in one environment, and that could simply be handled on Umbraco Cloud.
Headless on the platform you already have
You do not need a separate system for headless. Umbraco delivers content via an API from the regular CMS, and that simply runs on Umbraco Cloud. This way, you maintain one environment, one management contract, and one place where editors work, and you deliver content to anything that requests it.
This also means that you do not need to make the choice beforehand. You start with a site that works well, and if an app or a second channel comes along later, the API is already in place.
A separate headless solution like Umbraco Heartcore remains sensible when you have no website at all in the middle. This is, in practice, the exception.
Frequently asked questions about headless CMS
Are you in doubt if headless suits you?
Then we'll schedule a one-hour conversation. During that, we'll determine whether the link between content and presentation is truly your issue, or if it's elsewhere.
Contact with Webwonders
