As with all technological choices, deciding on 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? 

man editing webpage on headless CMS

In many enterprises, choices are made without considering all the technical implications of the final implementation and 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 perspective of a digital marketing agency. 

We focus on a particular use case of this technology: the company website. To frame the discussion further, let’s consider a few common 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 large 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, it is not feasible to manage common content across multiple systems.

Mobile & Web Applications

Create human-centric digital experiences that delight users and produce business insights.

Learn More →
Fortune 500 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 and collaborate and then publish content.  When content is published, instead of being rendered into a human-readable page, it is published as a code object that can be consumed by other applications.  Many consuming applications can read this published object, and render it as 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 different 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 certain volume of requests to 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 certain architecture possible, a centralized and governed content repository servicing many consuming frontends that display that content. Looking at the headless CMS technology in isolation makes a lot of sense and it certainly addresses some pain points with traditional approaches. To fully understand the business impacts of this approach though, it’s necessary to look at the whole technical solution which includes the content consuming side – a 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.

The reactive paradigm of building web applications was popularized first by Google and their angular library, and then by FaceBook and their React library. These tools are designed for applications that display rapidly changing content by enabling bidirectional, decoupled data binding. Said content is susceptible to change by either direct user interaction or some sort of backend update; think online chats, message boards, and erm, FaceBook.

While the distinction between websites and web applications is often blurred these days, it still remains that most websites are not highly interactive or sensitive to very frequent data changes. The JavaScript libraries and frameworks mentioned above modernize some aspects of web development benefiting the development team, but this innovation comes at a cost to SEO performance, operational efficiency, and complexity.

SEO Value

Good websites put a lot of effort into polishing the UX, making sure that visitors can quickly and easily navigate and find what they need and successfully convert. While the above frameworks support that effort, they often fail to do the same for the search engine crawlers.

To understand why this is a problem, you need to understand how these web applications work.  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 ones that are easier to parse.

Operational Value

Creating new landing pages, releasing new products, and crafting new sections for the company website – these tasks are the bread and butter of the Marketing departments. The tools we use should be tailored to make these tasks efficient.

Because the building blocks of a headless CMS powered website are more generic and non-specialized, they often lack basic features common to traditional content management:  

  • metadata
  • user-editable menus
  • blog sections
  • post indexes
  • RSS feeds
  • site search
  • editable URLs for pages
  • protected pages
  • content previews
  • scheduled publishing 

In traditional CMS platforms, this functionality exists in both the editing and frontend experience.  With headless tools, not only do these tools need to exist in the CMS, but they have to be explicitly scoped and built in the frontend. 

Building things from the ground up allows for more control of end result, but it also bears a greater risk of broken implementation. To manage 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. In many cases, even smaller content updates and modifications require developer time, creating a bottleneck that slows down digital marketing efforts.

Complexity and the Resource Problem

Developers are good at finding a way forward through technical challenges, and some of the concerns outlined above 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. They simply add complexity to the project and consumes valuable resources – requiring more developers, more time, and more effort.

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 if it weren’t for these technologies. If 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, the extra complexity can be a good tradeoff.

Traditional CMSs

Further complicating this question, the more traditional players have evolved to support this architecture pattern and are able to work headless. Well-represented open source systems like WordPress or Drupal expose a rich set of content APIs that can be used 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 30% market share of all websites out there, benefits from having a polished content management experience that most people are already familiar with. Given this flexibility, it’s also possible to start with a regular CMS-powered website and grow into leveraging specialized frontends by going headless later if you identify specific reasons to do so.


Headless CMS architectures has powerful applications across industries but to cope with the underlying complexities they require resources and dedication usually available only in large enterprises.


  • 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


  • 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, numerous web properties.


Understand and accelerate growth with us.
Get in touch