What you need to know about headless CMS | Whitepapers Online
Debates about the respective merits of headless and non-headless CMSs have been ongoing during the past few years. You may well have been ignoring them. After all, CMS architecture isn’t exactly a go-to dinner party subject— even for the most content-obsessed marketers.
But this is an important discussion. The quality of the content appearing on audience screens is becoming fundamental to the brand value of most businesses. To maintain an edge over competitors, you need to ensure the experiences you and your developer colleagues create are as rich, smooth, and contextual as possible—and extendable to wherever your audience is, whether that’s on a mobile app or connected device.
Headless CMS architecture is a big part of this conversation. So now’s the time to get to the heart of the headless and non-headless debate. In this white paper we’ll explain what headless is (and isn’t). And we’ll look at how you go about making the right CMS decisions for your company—taking into account the needs of both developers and marketers. At Sitecore, we also think it’s time to consider the merits of a third way: one that’s arguably much better suited to the modern age of contextual marketing.
Ready? Here we go.
What is a headless CMS?
A headless CMS is a content management system that lets you store, edit, and manage content—but doesn’t actually render the content on your audience’s screen. In other words, a headless CMS separates the creation, delivery, and management of content (the back-end tasks)from its presentation on the web page, app, or device (the front-end tasks). It has no role in website design, page themes, or templates. By contrast, traditional coupled (otherwise known as non-headless) CMSs are responsible not only for content creation, management, publishing, and delivery—but also for the last- mile rendering (otherwise known as presentation) of the web page.
How headless and non-headless CMS architectures differ
So it’s clear that using a headless CMS (rather than a coupled CMS) places a lot of responsibility for the end user’s experience on developers—because how a particular page or screen is built has to be described in code and managed by the developer. But there are some very big advantages to using headless CMSs—and that’s why it’s become such a big deal lately.
Headless CMS—a really big deal
When the digital world was all about the web and not much else, a CMS could handle authoring, storage, and presentation of designed websites quite happily. Content repositories (which store content and dynamically deliver it to a page) were optimized for HTML templates. Everything was coupled together nicely and there were big performance benefits to this all-round closeness. Then came the mobile revolution and the internet of things (IoT) as well as a proliferation of different devices on the market that didn’t use HTML. Suddenly, the coupled CMS cracks began to show.
Their content repositories, which were web-page-centric, just didn’t play nicely with non-HTML formats. They were ill-equipped to use the latest front-end technologies without hacks or significant development work. They simply weren’t ready for an age of fluid and responsive web apps in which pages dynamically update as users interact with them. They couldn’t adapt to a new age of content in which content objects were delivered via an API.