As with all technological choices, deciding what powers your website centers on the right trade-offs. Headless content management systems, single-page applications, and static site generators have been around for a while now in the web development world. When is the right time to utilize these tools?
In many enterprises, technological choices are often made without considering the implications for all internal stakeholders. They are left opaque for many marketing stakeholders in what’s typically a development/IT endeavor. Here, we present a high-level look at those choices from a digital marketing consultancy perspective.
We focus on a particular use case of this technology: the company website. To frame the discussion further, let’s consider a few everyday needs digital marketing has in terms of managing a company website:
- Ability to tweak SEO aspects of the website
- Direct paid traffic to specialized landing pages
- Promptly publish and update information on the website
What is a Headless CMS?
A headless CMS is part of an architecture pattern that emerged recently as an answer to specific problems at companies with a significant digital presence. This pattern aims to decouple the responsibility of maintaining content from the responsibility of displaying it. With multiple platforms and mobile applications displaying the content, managing shared content separately across various systems is not feasible.
Web & Mobile App Development
Design, develop, and optimize mobile and web interactions
Learn More → 
Fast-Growing Medical Device Company Transforms Their Customer Engagement Platform
Convertiv engineered a solution that could power customer engagement and transform a sprawling organic platform into a lean, intuitive, and performant tool.
View customer story → Unlike traditional CMS architecture, a headless CMS only provides a user interface for the content management portion. Content editors can log in, create, edit, collaborate, and publish content. When content is published, instead of being rendered into a human-readable page, it is published as a code object that other applications can consume. Many consuming applications can read this published object and render it a human-readable page. The CMS becomes a source of truth, and the consuming applications – websites, mobile applications, email marketing – can display the content.
Centralizing content governance makes a lot of sense from both a process and a technological perspective. It prevents user errors, promotes polyglotism (the ability for different technical teams to employ diverse coding languages and tools to solve their challenges), separates concerns, and increases security.
One of the most frequent implementations of a headless CMS in the enterprise revolves around using SaaS vendors such as ContentFull, Content Stack, Prismic, etc. These vendors employ a subscription model and, in turn, provide the software and support for a defined volume of requests for the content. They provide the most basic features you would expect from an enterprise CMS.
- Fine-grained access control
- Localization support
- Scalability and high availability
- Media management with CDNs.
What a Headless CMS is Not
The headless CMS is just a piece of the puzzle that makes a specific architecture possible – a centralized and governed content repository servicing many consuming frontends that display that content. The headless CMS technology addresses some pain points that would otherwise be present in a more monolithic approach. To fully understand the business impacts of this approach, though, it’s necessary to look at the whole technical solution, including the content-consuming side – a typical website frontend. The decoupled nature of this approach opens a plethora of choices when it comes to building the website frontend, and it’s easy to make the wrong trade-offs.
Angular, React, Vue Et Al.
Google, with its Angular framework, and FaceBook, with its React library, helped popularize the client-side, reactive paradigm of building web applications. These technologies are designed for applications that display rapidly changing content and employ bidirectional, decoupled data binding. Said content is susceptible to change by direct user interaction or a backend update; think online chats, message boards, and FaceBook itself.
While the distinction between websites and web applications is often blurred, most websites are not highly interactive or sensitive to frequent data changes. The JavaScript libraries and frameworks mentioned above modernize some aspects of web development, benefiting the technical team. Still, this innovation comes at a cost to SEO performance, operational efficiency, and complexity.
SEO Value
Teams behind great websites put much effort into polishing the UX, ensuring visitors can quickly and easily navigate, find what they need, and successfully convert. While the above frameworks support that effort, they often fail to do the same for search engine crawlers.
You must understand how these web applications work to know why this problem exists. A website built purely with JavaScript only exists in the visitor’s browser. When the page is loaded, a code payload is delivered, and then the content is dynamically rendered in the browser based on internal instructions and data. Since the structure and data are loaded and rendered asynchronously, search engine crawlers often fail to render significant sections. While it’s true that search engines have gotten better at parsing such websites, it’s also true that it costs more resources for them to do so. Search indexes penalize these applications in favor of easier parse ones.
Operational Value
Creating new landing pages, releasing new products, and crafting new sections for the company website are the most common tasks within Marketing departments. The tools we use should help make these tasks as efficient as possible.
Because the building blocks of a headless CMS-powered website are more generic and non-specialized to accommodate use cases other than websites, they often lack basic features common to traditional website content management:
- page metadata
- user-editable menus
- blog sections
- post indexes
- RSS feeds
- site search
- editable URLs for pages
- protected pages
- content previews
- scheduled publishing
For example, preview functionality is standard and seamless in traditional CMS platforms during editing; WordPress dramatically improved its WYSIWYG capabilities with the Guttenberg project. With a headless architecture, achieving this level of editorial feedback is much more challenging, often requiring duplicate efforts to build out the frontend end-user view of the page and the backend editing experience.
Building things from the ground up allows for more control of the result but bears a greater risk of broken implementation. Managing a project of this scope typically requires a large and competent development team, with both QA and specialists available and significant resources focused on this project. Sometimes, even minor content updates and modifications require developer time, creating a bottleneck that slows digital marketing efforts.
Complexity and the Resource Problem
Developers are good at finding a way forward through technical challenges, and some of the above concerns have their workarounds. For example, issues impacting the ability of the crawlers to index the site are mitigated by implementing server-side rendering (SSR) and using static site generators instead of client-side JavaScript. These approaches work, but at the cost of adding complexity to the project and consuming valuable resources – requiring additional developers, more time, and more effort.
It is not that these approaches don’t have their applications. Far from it – it would not be possible to build some aspects of the modern web without these technologies. Suppose your company website is your primary business, and you have the resources to pursue advanced web architectures for all the right reasons, like performance, scale, and security. In that case, the extra complexity can be a good trade-off.
Traditional CMSs
Further complicating this question, the more traditional players have evolved to support this architectural pattern and can work headless. Well-represented open-source systems like WordPress or Drupal expose a rich set of content APIs to siphon off content to wherever it needs: powering your email marketing, multiple native or web applications, or statically generated websites.
A system like WordPress, holding a 40% market share of all websites, benefits from having a polished content management experience that most people are already familiar with. Given this flexibility, in most cases, we’d recommend starting with a regular CMS-powered website and eventually growing into leveraging specialized frontends by going headless later if you identify specific reasons.
Recap
Headless CMS architectures have powerful applications across industries, but to cope with the underlying complexities, they require resources and dedication, usually available only in large enterprises.
Pros
- Centralized content repository for all devices and platforms
- Mix and match CMS technologies with various frontends
- A fully custom-built technical solution that fits your company perfectly
- Ability to refine and push certain aspects of a website to their maximum
- A feasible technical path to achieve global scale
Cons
- Increased complexity
- Requires a lot of specialized developer resources
- Longer and more involved development time frames
- Can have SEO and marketing operations implications
Good Use Cases
- Increased site speed across the globe at scale; A static website generator backed by a headless CMS, distributed by a CDN with edge caching.
- Content management for an interactive web application; Any new or existing application on almost any platform can leverage the restful APIs of a headless CMS.
- Content feeds for multiple digital channels; Content repository powered by a headless CMS that powers email marketing, personalization engines, and numerous web properties.