The term “headless CMS” sounds funny, right? After all, in humans, the head comprises the control center — the brains — while the body simply responds to the head’s thoughts and impulses.
So the idea of a headless content management system (CMS) seems like something unmoored…a technological chicken with its head cut off. And a headless model evokes even weirder imagery, because a well-functioning headless CMS is not lacking in the head department; it typically sports multiple heads, like a scary-looking hydra monster.
Despite all that, the headless model is what makes the most sense from an optimized content delivery standpoint these days. That’s because the beauty and main strength of a headless CMS is that it can accommodate multiple types of content presentation platforms, such as websites, mobile phones, a CRM, and smart watches.
Standard CMSes (also known as “coupled;” for example, WordPress) made their debut after the debut of the World Wide Web, following the money by letting companies make their website content significantly easier to manage.
A traditional CMS has both a back end (the “body”; a content repository) and front end (the “display layer”), which are connected. It:
In short, old technology.
Which still works, and which many companies are still using, particularly if they don’t have a need to send content to more than one presentation layer.
But the content-dissemination options have been expanding, and companies have started focusing on content modeling. Now, in addition to content being provided through a browser, it can be expressly tailored to appear on other devices and in other applications. Consumers are looking to get their content on devices ranging from smart watches to voice assistants, and, of course, their trusty smartphones.
Enter the modern headless CMS. Its back end — the interface for creating, managing, and storing information — is separate from its front-end operations, the way the information is displayed. The front end doesn’t communicate with the back end, it only renders content.
And while “headless” does sound as though something major has gone missing, more intelligent functionality is gained to make up for that loss.
One thing you can gain with a headless CMS architecture is several “baby” heads tasked with shepherding the content to specifically where it needs to go.
The hydra monster is alive and well: instead of the back end controlling the flow of all information to one place, namely a website with templates, a RESTful API (or a GraphQL API) frees the content to travel to other places, such as iOS or Android mobile phones. Its readers could be playing a virtual reality game or using their company’s customer relationship management (CRM) tool, among other digital experiences.
So in this model, the place where content appears and how its presentation is facilitated are not concerns. Instead, the focus is on letting content editors create and collaborate to provide structured content that can be made available to various destination platforms as needed.
The end result: an excellent customer experience for readers, wherever it’s taking place.
As content management consultant Deane Barker notes in CMS Wire, headless (and “decoupled”) architectures have been around for a while; what’s fueling the “latest” headless craze is that companies now need to deliver their content to platforms other than standard web browsers. And that’s a lot easier to do, and things can move faster, without the limitations of an inflexible front end.
Headless CMSes are versatile, so they’re being used in a variety of applications, such as, with:
The headless model is rolling out here, there, and everywhere because it can easily dispatch structured content to multiple destinations. It’s the preferred tool for omnichannel digital delivery, the integrated way of providing content that feels to customers like integrated, responsive, multiple-touchpoint marketing, sales, and customer service.
What do the benefits of headless entail? You can:
In a traditional CMS, writers and editors are reliant on developers to design the content interface on the website. Writers can write, but until the display structure is in place (rendering), they can’t publish.
When you lose the head of the CMS, you lose the need to render the content, which is then handled separately in the stack.
Another term for a headless CMS is content as a service (CaaS), as a genuinely headless CMS does not generate front-end code. That means no code tangled up with content, and editors not having to do any coding in order to get their content online. They can focus on their roles and workflows as creative content providers without having a shred of HTML experience, for instance. If they notice a typo in something that has gone live, they don’t have to type an email to the development team asking them to please fix it, and then wait around. They are made whole.
Editors aren’t the only ones whose jobs get much simpler upon removal of a CMS’s head. Marketing people and merchandisers benefit from the content independence of a headless CMS. They don’t have to interface with developers as an administrative step, which speeds up their processes and lets them instantly react when something (such as an item’s price) needs to be changed.
Another benefit for non-techies is having a central content hub where they can update everything from dead links to product availability. And when they make a single change, that’s it: every content presentation platform is updated, which saves a ton of time.
This role separation in a headless system also means that employees and teams alike can work at their own paces, instead of having to march in tandem with developers’ often-rigid roll-out schedules.
If editors are thrilled with headless, does that mean developers get the short end of the stick? Heck no. Whether they’re focused on creating for the Web or for mobile apps, developers benefit immensely when headless content is handled using APIs.
For starters, they gain a huge amount of flexibility. They have the autonomy to select their preferred front-end programming languages, tools, and work processes. Without messing up the CMS, they can interchange parts of the tech stack, or switch frameworks.
Front-end developers can work on functionality for various channels, regardless of what’s happening on the back end.
Developers can pay attention only to creating great user experiences, and then hand everything off to the appropriate API and move on to something else. They can work on applications and then freely and quickly deploy them. This makes for a rewarding experience, and one that can also save tons of time (and expense).
Not only do editors and developers find themselves enjoying new independence and power with a headless CMS, they find that the headless model improves the ways they collaborate with each other when they do need to connect.
A central, agile headless work environment means publishing timelines can be shorter, for instance, because when a master content item is repurposed for multiple channels, there’s no time-consuming re-creation of content. Users can handle needs as they arise. Plus, managing content in a single place for multichannel distribution means users must learn the system only once.
Because a headless CMS lets editors easily repurpose different content types through a common interface, the process is speeded up.
You can add content to channels without having to first publish the material on the website, saving time. A single request takes care of the publishing task, resulting in fewer requests. And with fewer requests, response times can improve, leading to a leaner, meaner, more efficient enterprise.
You can also more quickly add new channels because they may be pulling content from already-created sources.
Beheading a CMS seems like it could add security risks, but the opposite is true. Why?
Headless content is separate from what’s happening on the presentation layer, so there’s a smaller area that could be at risk. A security incursion on the front end can’t then access the separate back end. If there is a security breach on a web page, it doesn’t compromise the other pages or the site functionality. Also, there’s no way for prospective hackers to access a portal and enter data.
While traditional CMSes are limited in terms of scaling, a headless CMS means high scalability (with high availability). Developers can quickly add new channels, and then, when one is added, it can efficiently grab content from the central CMS. With a headless CMS managed from one master source, you can also change developer tools if needed and then send content to high-performance cloud-based hosting and build services.
One thing headless CMSs naturally lack is integrated search functionality.
If you’re thinking that it’s not easy to build search, let alone the sophisticated type of search user interface that’s typically used these days, on top of a headless CMS solution, you’re right.
Fortunately the build-from-scratch method isn’t necessary. Algolia offers an API plugin that integrates with headless CMSes to provide flexible, feature-rich search, letting you handle indexed data intelligently and at scale, and push it to any CMS, device, or endpoint.
You can efficiently integrate our API with a headless CMS by leveraging webhooks.
If you have a web server, you can add an API.
Or if you host Sanity Studio (open source) on Netlify or Vercel (for instance), you can integrate Sanity.io with Algolia. Other options are Kentico and Storyblok.
When you’ve got first-rate search, you’re ready (for your head) to roll.
We’d love to help you adopt a headless architecture to expertly power your front end, optimize your content creation and reuse, and future-proof your system. Connect with us at Algolia and let’s get started.
Catherine Dee
Search and Discovery writerPowered by Algolia AI Recommendations
Catherine Dee
Search and Discovery writerCatherine Dee
Search and Discovery writerVincent Caruana
Sr. SEO Web Digital Marketing Manager