Digital content has grown well beyond the bounds of traditional websites. Organizations can reach out and connect with their audiences on many different channels and devices, including websites, web and mobile apps, smartphones, chat, wearables, social networks, digital signage, telematics, and more. These channels will continue to change and grow and it's driving the way you plan, create, and distribute content in the future.
Most Web CMS software is not designed to support this need to manage content for multiple channels and experiences. A traditional CMS assumes that all the pages or screens are built and managed in the CMS. That is no longer the case. Front-end development frameworks like Angular JS, Ember, and React empower organizations to create new interfaces and experiences that a CMS can’t duplicate.
What’s needed is a strategic approach that separates the management of content from where and how it is displayed.
This new approach is called headless CMS.
A headless CMS enables the creation and basic management of content and the delivery of that content to external publishing channels typically via a RESTful API. It provides the backend content management capabilities only; any formatting of the presentation of that content takes place on the front-end delivery tier and is not tied to the CMS in any way.
You may have also heard headless CMS referred to as “Content as a Service” or CaaS.
Typically, there are two main components to a web content management solution:
In a headless CMS, there is no front-end delivery tier, only the back-end content management capabilities.
A headless CMS provides a read-only RESTful content API. The application requests the content through the Content API which in turn pulls the right content from the CMS where it is managed and stored.
If you are any company doing business on the web, chances are it’s complex and cannot be delivered using a CMS platform alone. When you think about it, there are unlimited use cases where the delivery of content as a service works very well. Let’s examine some of these.
Native mobile apps are a prime example of headless CMS in use. Native, or hybrid, mobile applications are typically a combination of functionality and content. It could be an interactive application, a game, a store shopping app or something else.
The content in these mobile applications often needs to change frequently (new deals, new information, related content or product). Leveraging a headless CMS enables developers to update mobile app content continually without having to rebuild or recompile their applications and go through the process of resubmitting them to the App Store and forcing updates on mobile devices.
Most large enterprises or global organizations manage more than one website or a single website with multiple languages. A headless CMS is a good approach to provide translations to multilingual websites or to deliver the same content (in different filters or views) to different websites.
Automated or AI-based chatbots are increasingly used in web experiences. These chatbots are not managed by an actual person, but instead offer questions and responses to a customer guided by what the customer is doing on the website or asking the bot. Managing these questions and responses in a headless CMS enables marketers to easily update the content as new content is added to the website and new resources become available that match the requests the customers are making.
Whether it’s a voice-enabled device like Amazon Echo or Google Home, digital signage or some other IoT device, you will need to create and manage content that you share via those devices.
For example, if you wanted to offer a digital signage solution or kiosk, you don't need to install the CMS on each kiosk. You simply pull content from the CMS using the API and store it within the front-end tier. Even if a persistent internet connection is not available, you can still deliver content to your kiosk application.
Web applications also benefit from headless CMS in a few different ways. Web applications are designed to provide business services – banking and financial applications are two great examples. The focus of these applications is the functionality they provide. But they also offer content that needs to be regularly updated.
For example, you have a rich web application for a financial loan application, and you want to offer a series of guides or posts that discuss the application processes, or loans within the application. To ensure you have a way to update this content easily without needing to rebuild the web application, you manage the content in the CMS and deliver it to the loan application using the CMS content API.
Some other examples:
For example, with an Angular JS app, directives (parts of the web page) are mapped directly to components managed within the CMS back-end. The CMS provides a visual representation of the app’s content for non-coders so the content on the web app can be updated easily and quickly, like messages, labels, or help text.
As these types of websites and applications are built with custom code, they require build and deploy processes, and need to be managed in existing source code control and development operations systems.
Headless has many advantages including fast to set up and integrate, more control for the front-end design and development, true dev ops support, and often better information security practices.
Let’s examine some of these in more detail.
A headless CMS separates content development from content delivery. This separation enables you to set up a firewall between the two environments. The firewall protects your network and ensures that content will not be accessed by third parties until it is published.
A headless architecture also reduces the risk of denial of service attacks (DDOS) because the software that delivers the content does not need to access the CMS database, thus eliminating the risk of SQL injection.
With a headless model, you do not have the overhead of the CMS application on every web server. This improves the speed of the delivery tier. Separating the front-end delivery tier also allows you to scale your website using commodity hardware.
Performance is an important focus for content management. The speed at which your website or web application loads has the potential to affect sales and other campaign conversions. For example, Firefox reduced average load time by 2.2 seconds and increased downloads by 15.4%. In another example, Walmart did some performance testing on its site and found that for every 1 second of performance improvement there was a 2% increase in conversions.
With a headless CMS, when you upgrade the software you are only upgrading the CMS application, not your live website. This allows your live website to continue running; there is no risk of breaking the site, or customizations to the CMS from the site implementation.
In a headless architecture, if the back-end CMS software were to go down or need maintenance, your live website would continue to operate.
Most enterprises also implement load-balancing software for the front-end web servers, so there's no reason for the website to have any downtime, even for scheduled server maintenance.
The publishing model for headless architecture provides much more flexibility. You can publish multiple websites using different servers and technology for different sites. Your CMS should include a replication system that keeps content in-sync and provides much more flexibility.
The headless CMS approach also has many limitations. For starters, it is simply a content database. The database does not know–or care–what content will look like, where it will be used, or how the site or app will be managed. This can make it difficult to design the content structure appropriately if you aren’t well-versed in defining structured content.
Content authors may also find working with a headless CMS challenging as the content authoring interfaces are often more technical and structured. In addition, many headless solutions don’t provide things such as personalization, content targeting, analytics and other capabilities critical to delivering good customer experiences.
Although the headless CMS market is growing, many platforms are comparatively immature and lack key features that many organizations require including Remote Preview and DevOps integration. A lot of CMS vendors are quickly realizing they need to provide more than one way for organizations to deliver content. So, they are adding a RESTful API to allow developers to pull content from the CMS repository. But it’s not as simple as slapping on an API and calling yourself a headless CMS (or headless optional).
To truly enable content re-use across different channels, you need to manage your content in an intelligent, structured manner and many (formerly) traditional CMS vendors do not support a structured content model. While you may be able to pull content out for delivery to a separate application or website, it may limit you in how that content is retrieved and how you can then display it.
It’s critical to assess the full capabilities of these headless-optional solutions to ensure they do provide the capabilities you need.
Adopting a headless CMS approach requires more than the separation of the front-end delivery tier from the back-end content management services. Here are a few other key considerations for headless content management.
A headless CMS requires a structured content model for storing and managing content. A structured content model, also known as an intelligent content model, is a way to create and manage content separate from how it is presented in any application or website. Structured content is stored as XML, JSON and other formats that provide a rich content definition.
You store structured content in a format that both defines it using content types and relationships and describes it using metadata. This semantic definition enables the CMS to adapt the content for multiple outputs and formats.
This approach requires a completely new way for many organizations to develop content. Typically, they think about content based on the channel. So, for example, when you design a new website, there is a content identification and development phase; the same approach is followed for a web application. In both instances, the content is only defined for its use within a single channel.
It's important to bring content modeling up a step, bringing it outside of its delivery to any channel. Instead, understand all the content your organization creates and manages. Define your organization's taxonomy including content types, its relationships, and associated metadata. Defining and managing content in this manner ensures that it can be reused across all your channels, both offline and digital. It also supports federated and faceted search.
One drawback of the headless CMS approach is not being able to preview what your content looks like in the delivery tier. Because the content is created separately in a CMS, there's often no way to see how it will look when it is applied to a presentation.
Remote or external preview empowers marketing users to make in-context edits and view layouts on pages that are not managed by the CMS. A headless CMS should provide a web services-based preview system that can emulate applications and content in the design-time CMS environment.
Content security is another key consideration for headless content management. In a pull-based content API model, the delivery tier sends a request to the CMS and includes the proper credentials to show they can access content. The requesting applications will have to ensure the credentials are secure from outside access.
Just as important is ensuring content permissions are applied based on the requesting system. A CMS might manage content for a number of applications and websites. Properly applied permissions ensure that the requesting server can only pull the content they have permission to view. The headless management tier must request the credentials of the calling application and apply permissions appropriately.
Also, by providing a read-only content API, no one can send requests to the CMS to modify the content.
As you develop your headless CMS model, you may slowly update how the content API works, and like any other development process, you want to include DevOps processes and builds.
GitHub and Mercurial are two approaches to version control that can help you manage the development and continued updates of your headless content API. Both offer versioning that enables you to point your delivery tiers to different versions of your API. In this way, you can point applications in development at a development version of the content API, and the production versions of your apps at the production version of the content API.
Using version control tools, you can build a branch for each stage of your content API – development, staging, master – in the same way you create versions of a website or web application.
It is often the case that both a loosely coupled and headless approach are needed within an organization. In these instances, an agile CMS (also known as a hybrid CMS, or headless hybrid) is the better approach.
An agile CMS is a content management system that provides full back-end content management capabilities, a structured content model, and both a decoupled and a headless content delivery tier. With an agile architecture, your organization can create and manage all your content in one place and deliver it to different channels - the website, a native mobile application, a business application, or somewhere else using the delivery model that makes the most sense. It gives you flexibility in how you deliver content while keeping the management of that content under one roof.
Another benefit of an agile CMS is content aggregation. Most organizations create and manage content in many locations and repositories. Much of that content is helpful in providing good customer experiences. A good hybrid CMS understands that not only should it help you manage content, but it should provide a mechanism to import or aggregate content from other repositories, regardless of format and apply some structure to it, so you can then make it available to your customer channels.
When should you consider an agile CMS over a headless CMS? Here are three reasons:
A hybrid CMS offers headless deployment as well as dynamic content delivery. In addition to a "headless" content API, a hybrid CMS provides a content delivery server that is "loosely coupled" with the CMS. Using a content delivery server, you can publish your public website, Intranet or a portal - all on separate delivery tiers yet connected to the same backend for content.
With a content delivery server, you can use the CMS to create templates for your website, so you don't have to have your developers code every page on your website. You can also create dynamic and personalized experiences.
Along with a content delivery server and a content API, a hybrid CMS may also support the ability to push content to other channels by rendering content as static XML or JSON files. This push deployment model is often preferable for applications with offline requirements, kiosks, and sites with information security requirements where a content API connection is not acceptable.
The headless CMS market is relatively new. The feature gap between a modern web experience platform and headless CMS is significant. With an agile CMS, you get the best of both worlds: a full-featured CMS platform with flexible or agile content deployment options.
Because they stem from mature web experience platforms, agile CMS' are fully developed and have a strong foundational architecture that separate content management from content delivery, focus on creating intelligent content so you can use it across many channels, while still providing full content management capabilities regardless of how or where content is delivered.
Many hybrid CMS' also provide several hosting and deployment options, including SaaS, on-premise, and platform-as-a-service for public and private cloud, opposed to the multi-tenant SaaS-only model traditionally used by headless-only CMS vendors.
Speaking of full content management capabilities, a headless CMS only provides a subset. Distributed content authoring, customizable workflow, search, personalization, analytics, governance capabilities such as accessibility, spelling, and grammar, linking, and SEO aren't features you see in many headless CMS'.
Many organizations require features beyond what you find in a first-generation headless CMS. And it's not only the list of features, but it's also the depth of their capabilities. For example, you can upload images and media in a headless CMS, but you may not get all the digital asset management features you need. Many of the features you expect from a web experience platform are not fully realized in a headless CMS and may be critical to creating great content and delivering the best experiences for your audiences.
There are many situations when a headless CMS solves your content management needs. However, there are situations when it makes little sense to adopt the headless model.
Go Loosely Coupled: If you only deal with one or two websites, then the overhead required to use a headless CMS may not make sense. If you implement a responsive design approach for your mobile solutions, then headless also isn’t required. These situations are more often true of small businesses than of mid-to-large organizations that deal with multiple websites, applications, and other customer channels.
Go Headless: Consider a headless CMS if you are building highly customized websites that are built and managed by expert developers.
Go Agile: Consider an agile CMS over a headless CMS if you need multiple deployment options and you don’t want to manage multiple CMS solutions, if you require robust content management capabilities, including digital asset management, and if you want to aggregate content from multiple locations to provide a single place to find and deliver content to your customer experiences.