When choosing a CMS, many parameters must be considered. One of them is undoubtedly the choice between a traditional monolithic architecture, in which backend and frontend remain an inseparable marriage, or choosing the modern headless architecture. Opting for the latter has many advantages and some drawbacks, but it seems the market has not correctly perceived those advantages or has thought that the drawbacks are too great, since at CMS MAG we do not see a strong reception for headless in Spain.
We are not going to dwell in this article on explaining again what a headless CMS is, since we already did so at the time. Perhaps it is appropriate to review its main advantages again.
The advantages of headless CMS are many and varied:
- Greater security. The backend can be better hidden from cybercriminals.
- More stability and updates: The backend can be updated without affecting the frontend.
- Scalability: From a headless CMS you could also power an app and many other channels without needing more CMSs or duplicating content. Better content reuse.
- Flexibility: On the frontend you can design versions adapted to any device with, in theory, greater and better performance. And on the other hand, flexibility also in the sense that through APIs and microservices it is relatively easy to connect any modern third party service.
- Cost savings: They generally tend to entail cost savings in the long term, but in the short term prices are usually higher than with traditional architecture.
- Increased speed: Backend and frontend can work independently without blocking each other, which results in faster time to market.
- Lower risk of vendor lock in: Through the API the client can always extract the data whenever they wish and the CMS owner does not even have to notice.
Let us also review their disadvantages:
- Greater technical complexity: By separating back and front, there must be different teams for each that must coordinate well.
- Initial cost: Headless can imply a higher price at the beginning. In projects with a lot of customization, the cost can obviously skyrocket.
- No ready to use frontend: Many headless CMS offer their part, the backend, although not the front part, the one the user sees. Only the best also offer good templates for the front from which to start working on customization.
- An integrator is used: Due to technical complexity, sometimes the CMS owners are not the ones who do the implementation, rather they delegate to third parties.
- Pace of improvements conditioned by the provider: It is common for the backend to be run by the CMS company and to be in the cloud. In many cases, moreover, all clients evolve together and there is not much power when it comes to prioritizing certain requests. Clients themselves must then proceed with customizations.
- Potentially key features not included: In several headless systems, aspects such as subscriptions, paywall, ads, newsletters or print are not integrated and require connecting to third parties, although the latter is usually not a problem at all.
- Editing experience: Although headless CMS are modern, their editing experiences are usually quite traditional and based on the classic toolbar we have always had.
Advantages that are not so much: hunting myths
We have already mentioned that we have not seen a great reception of the headless architecture in the market. On this subject we have observed that WordPress VIP, which also offers this possibility, has published an article by Shane Schick in which he debunks myths about headless, noting that some supposed advantages are not as compelling as they seem.
Shane says that referring to traditional CMS as monolithic does not help and that, moreover, according to his data, headless CMS adoption has fallen from 28 % to 16 % in a single year. According to this WP VIP article:
- A headless CMS does not always produce faster and more personalized frontends. This depends on execution. Good optimization of a traditional CMS can also yield excellent results.
- It is said that headless CMS produce cost savings, but these are long term savings that occur mainly by eliminating the need to switch CMS again and migrate. Their own technical complexity works against savings. The savings would come from faster launches and better surfing of trends, but determining the exact ROI of this is more than complicated.
- It is also said that a CMS without an interface, headless, empowers content teams. This is true in the best and most modern ones, but not in all.
- A headless CMS provides greater agility by being able to send content and generate as many personalized and optimized outputs or frontends as you wish. The reality is that this depends on your development resources, resources that are usually very limited.
- It is also said that headless CMS offer higher levels of security. Although what is exposed is reduced, the truth is that no one can guarantee security at 100 %, and on the other hand, the fact of using APIs to send and receive requests and content entails its own risks that traditional CMS do not have.
- A headless CMS facilitates omnichannel expansion: This is true to some extent, but covering different needs or audiences with different frontends increases complexity, the coordination work among many departments, and is hard to maintain. When there is only one responsive frontend, it may not be perfect in every case, but it is surely adequate in most, and certainly much less complex to maintain.
- The headless CMS improves SEO: Improvements in speed and personalization, as well as structured data, should improve SEO, which provides extremely valuable audiences. The reality is that the frontend team must be good and must generate pages via Javascript that Google can read and understand well, this does not always happen.
Our view on headless CMS
At CMS MAG we have quite a bit of information and experience regarding this type of CMS for various reasons. First, we have observed that the initial price is often a major barrier to entry for digital newspapers and companies that wish to adopt it. Long term savings are not often seen much, in general the here and now prevails.
We have also seen that it is not easy to adopt even when the CMS company also offers a frontend to get started and moreover has in its portfolio a particularly cheap product, whether it is called Go, Lite, Light or whatever. Even under these conditions a headless CMS is not usually accessible.
Price, therefore, is a major handicap, as is a certain market misunderstanding of the offering. It assumes that the CMS company takes care of the backend and the newspaper itself of the frontend, which is where the real party of code and advertising is played out. Many newspapers and companies consider that in this way the CMS company unloads itself of what is truly painful to handle.
The technical complexity of the headless system is also not at all well regarded by the market, a market that is usually precarious and that truly seeks precisely less complexity and even no code systems for its editors and product managers.
To make matters worse, Google’s latest moves, which amount to appropriating content to train its AI and depriving media of a large portion of traffic, place the sector in an even more precarious state, so that even fewer can consider modern headless solutions. Few outlets can afford the luxury of switching and calculating ROI with a horizon of 3 or 5 years, since for the rest it is truly about surviving.
Hybrid CMS: The solution?
In the automotive world there are two extremes, combustion engines and electric ones, and in between, non plug in hybrids. Let us make an analogy with traditional CMS and headless, which also have at an equidistant point hybrid CMS, which are those that can behave like a traditional CMS or headless as needed. WordPress, Drupal, Comitium… Nowadays there are few traditional CMS that have not integrated a way of behaving like headless.
In automotive, Toyota’s non plug in hybrids are world leaders. They have the best of both worlds or, depending on how you look at it, the worst. Be that as it may they are leaders with this technology. I say they can have the worst of both worlds (in a Toyota Corolla, for example) because they have the heavy weight of the batteries and on the other hand the fuel savings they produce is barely 2 liters per 100 kilometers, which is not much, although it is noticeable in emissions.
In the same way, hybrid systems can be seen from the point of view of ideal CMS because they cover all use cases, or the worst in the sense that if you want to be headless it is better to choose a good headless CMS like Glide directly. And if headless capabilities are not needed, having the API system available is a security risk.
In conclusion, each use case is unique and will probably have to choose based on its particular casuistry.
Headless yes or no? Our conclusion
The best course is what we have just mentioned, to carefully review our particular case and decide which architecture suits us best based on our needs. Choosing a hybrid CMS just because it offers every possibility is not a sufficient argument.
The choice matters a lot, but at CMS MAG we always say it is only half the journey. The other half is execution. If the CMS implementation is not good nor the migration, no matter how good the CMS is, the result will be loss of customers and or audience, and on that in Spain we can tell you about many cases.
In general, it is an architecture that is suitable above all for large companies and newspapers with a decent budget and internal resources, both engineers and advanced professionals in the newsroom. A good implementation can be very beneficial for SEO, robust and scalable, enable a good go to market and indeed generate more revenue and savings, but this does not always happen.
* Original article written in Spanish, translated with AI and reviewed in English by Jorge Mediavilla.
