The term “headless” comes from the concept of chopping the “head” (the front-end, i.e. the website/design layer) off the “body” (the back end, i.e. the content repository).
This technology allows cutting-edge UX, gives developers greater flexibility to innovate, and helps site owners future proof their investments by allowing them to refresh the design without having to re-implement the whole website solution, i.e. to do a full re-design. In theory, you would only have to re-implement the front-end layer for the channels needing a re-design.
So, what is the difference for you?
A “traditional” CMS stores your content, giving you the possibility to create, read, update and delete (CRUD) it. It also uses this content to present it to the visitors in a pre-formatted manner and application using for example HTML. A headless CMS stores your content, giving you the same possibilities for CRUD, but instead it can feed the content to any consuming system that wants to display it (for example a front-end application/website).
Are there any disadvantages with headless?
Well, it depends a bit on the actual platform that you decide to build your solution in, but the challenges in general are: With greater freedom comes greater responsibility. A headless CMS may present formatting challenges since you can’t always preview how the content will look like on the page or in a specific channel. Therefore, you need to take extra measures to anticipate how things will turn out on the front-end.
Going headless may also sacrifice the full possibility of personalization. Because of the separation between content and delivery, a headless CMS may not be able to gather sufficient information about the visitors to return personalized content. This issue can be solved but may require more custom development.
