We’ve been seeing lots of buzz lately about headless content management systems (CMSs)—which separate creation and management of content (the back-end, foundational tasks) from its delivery to a web page, or an app, or an internet-connected device (the front-end “head”). In other words, they allow you to edit, store, and manage content but leave the design and delivery of that content to a separate application. So your content, rather than being presented to the end user on a web page, is made available to a developer via an API (application programming interface). The developer creates an application with the content delivered to it from the “headless” CMS.

There are several things driving the buzz about “headless.” The Internet of Things, for one, in which lots of connected devices just request pieces of content from a CMS. Also the fact that brands want and need mobile applications that leverage their web content and reach an exponentially growing mobile consumer base.

The third, and main, driver are the front-end developers themselves—who don’t need or want to know anything about the content infrastructure in order to create applications. Using front-end frameworks like open source, JavaScript-based Angular and React, they can build rich applications quickly that leverage content without having to integrate all CMS features and capabilities. Put simply, writing apps that interact with a headless CMS gives the developer more freedom, flexibility, and a bigger playground. That benefits developers, but whether it benefits your business is another issue altogether, which I’ll address later in this post.

Sitecore as the original headless CMS

When I first started hearing the buzz about headless CMSs, I didn’t think anything of it. After all, Sitecore originated as a headless CMS. The first two versions of Sitecore were designed with a content management layer separate from the abstract layer, where the abstract layer requested content via an API. Later versions introduced a layout engine as a middle layer that tied content management to the API with layout definitions (e.g., templates that define how the layout is assembled). But that layout engine, which is where site visitors interact, has always been completely abstract of the content. And as we’ve evolved our web services API to use the latest technologies (like OData), our platform has and always will separate content from the design of that content. This is what we mean when we say the Sitecore Experience Manager™ “decouples content from its presentation” and lets you write once and distribute anywhere.

Sitecore has never marketed itself as “headless,” because, as we have always separated content from presentation, we never thought of “headless” as a commodity. No big deal. It wasn’t until recently, when some in the industry incorrectly concluded that our content, layout, and presentation layers were coupled, that we felt the need to clarify our headless approach—which has been in existence since well before “headless” was even a term. I’m beginning to realize how unique we are in that aspect. I recently spent some time exploring our competitor's approach to content management, and can see that, while it’s easy to equate our architectural approach to our competitors, they are most certainly not headless.

Let me explain. Sitecore stores content as small objects, and our layout engine places those objects, or modules, in a web presentation format. Similarly, a mobile app developer can use our API to call those content objects and reuse them in a mobile app. So when a marketer changes your brand’s web content in Sitecore, those changes automatically propagate across any channel on which you’ve called or reused those content objects. With our Experience Editor, you can edit and preview content components (or modules) on a page. You can do the same in AEM and other products. Many CMSs make it appear as though you’re editing content components on the page, but the similarity ends there.

Are you clear on why most organizations today opt for a digital experience platform (DXP) over a traditional CMS? Learn more about the relationship between the two, including why a robust DXP offers needed functionality to the CMS foundation.

Look under the hood

Many competing CMSs are architected to store their content with the page, e.g., one page might include many different components, but they are stored according to the page upon which they appear. For instance, AEM copies components (using something called Multi-Site Manager) from web pages to mobile pages sharing the same blueprint, and synchronizes them to maintain consistency. The system is not natively reusing the components, because it can’t—they are stored in the page. These are very unforgiving systems under the hood. To the user who’s editing the components, Sitecore and its competitors may behave in very similar ways, but they are architected to store content very differently. Sitecore is and always has been headless.

Which is better—headless or coupled?

So, what do you, as a business or digital marketing leader, need to consider when wading through the buzz about headless? Think about these three points:

  • What are CMSs? The role that “web content management” systems play in your enterprise has been changing. They used to just power web content; but today they are the foundation to your entire customer experience management system (and I believe our Sitecore® Experience Platform™ has led this evolution). They empower you to deliver, manage, test, and optimize a highly personalized, contextual customer experience with your brand. Because, after all, if your digital systems aren’t enabling a closer, more productive relationship with your customer, they’re failing your brand and, most important, your customer. Headless CMSs actually fly in the face of this evolution. They’re running in the opposite direction. Read on...
  • What about the customer experience? If you care about managing your customer experience, headless CMSs won’t help you. They’ll make it quick and easy for developers to create rich applications, but those apps are not a customer experience. “Customer experience” is the collection of the design, the device, the content, and the user context. Apps you create from a headless CMS are abstract. They blindfold you to the customer experience, because you can’t track the interaction experience. You can’t test, optimize, personalize, or market in context with a headless CMS and the apps they enable. With Sitecore, however, you can have it both ways—you can use Sitecore to power apps or power a digital experience. But you can only market in context of customer interactions with your brand by using it to power a complete cross-channel digital experience. For now.
  • When to use headless? As a business person, you may see an opportunity to quickly build a rich mobile app on a headless CMS. An app that will differentiate you and help you compete. Sitecore XP can support those with this need, and I would recommend this for digitally mature companies that already adeptly manage customer experiences in context of how users interact with their brand. Those whose digital properties are personalized, who regularly test and optimize those experiences, and whose organizations are set up to be customer-centric. Such digitally mature companies will be able to strike the right balance between contextualized digital experiences and standout app user interfaces.

Headless is not new; it’s just a “new” buzzword. We have always believed in decoupling presentation from content, but a strictly headless CMS introduces significant risk in that it increases the complexity of your solution for both your developers and your marketers. Sure, headless CMSs certainly free developers to choose whatever front-end user interface technology they’d prefer, and that might give you an app with a great user interface. But the downside is that your app’s customer experience will also be decoupled. You won’t be able to personalize that experience, or respond in real time with relevant content, or test and optimize and manage forms and market in context of user interactions. Is a standout user interface worth it if it’s that isolated?

There is no good or bad here—there needs to be a balance. Not every site needs to be built within the constraints of a CMS. But not every site needs to be built headless. That’s why we believe in the hybrid solution and support both approaches—a contextual site generated with the Sitecore layout engine or a headless CMS and app based on the Sitecore REST API (JSON).

Further reading