WTF is A Headless CMS? [Explained]

Key Takeaways (TL;DR)

• A Headless CMS is a “Content Repository” that makes content accessible to any platform via an API.
• Unlike a traditional CMS such as Wordpress, a Headless CMS does not dictate where or how content is shown.
• A Headless CMS enables teams to deliver omni-channel experiences at scale, globally, without restrictions like templates, devices, or pre-defined technologies.
• A Headless CMS allows brands and companies to engage with users on any device and format.
• A Headless CMS fits into any preferred tech stack or framework, including popular ones like React, Angular, and Vue.
• Headless CMS provide better ROI since they are cloud based, security and backups are handled by the vendor, and they are easily scalable all while reducing time-to-market when delivering projects.
• You do require certain technical resources available to migrate to a Headless CMS.

What is a Headless CMS?

In a nutshell - a Headless CMS is a content repository that delivers content to any platform or device via API. The intended consumption of this content is by devices in a raw structured format, such as HTML or JSON, and isn't meant for human consumption until rendered on the end device.

To elaborate, a Headless CMS is, at its core, a content repository that makes content accessible via an API to any platform. The term “Headless” comes from the concept of detaching the “Head,” i.e. the front end (Website, App, etc.), from the “body,” i.e. the back end (content repository, database, etc.). Instead of delivering compiled HTML, a headless CMS only delivers the content by means of an API. An API driven approach offers many advantages over traditional CMS paradigms.

By removing the presentation layer, or the head, from the CMS, there are theoretically no restrictions to how and where content can be delivered. Marketing and editorial teams can create content within the editor interface of a Headless CMS (similar to how they would with Wordpress or Joomla) should there be one, and the engineering team can define how and where this content is delivered. A common misconception is that a Headless CMS follows the path of more traditional CMS like Wordpress, where “content” is restricted to a landing page or a blog post. The reality is more flexible with the limitations of what “content” is, which can include anything from blog posts and landing pages to banners, alerts, flight inventory, news feeds, etc. Similarly, there are no restrictions on platforms where this content is delivered, which can extend from websites and mobile apps to watches, dishwashers, fridges, etc.

While the idea of a Headless CMS has been around for a while, they have only recently become the popular approach to handling content due to the spreading diversity of platforms that need content, the improved developer experience and overall faster app load times. The headless approach to content management allows for your teams to publish content faster and iterate your digital presence with greater efficiency, making content delivery flexible via APIs rather than web page rendering.

There are many terms thrown around to describe what a Headless CMS is - commonly ranging between Content Hubs, Content Infrastructure, and Managed Content as a Service - all of which are valid, since Headless CMS essentially offers a repository for storing content that’s ready to be delivered somewhere.

To better understand the value proposition of a Headless CMS, it's important to visualise how content is delivered in this case, and what the advantages of using an API-first approach is.

Headless CMS vs. Traditional CMS

Traditionally, a CMS is a software used to manage content across websites, a popular option being Wordpress, which we’ll use as an example to illustrate the differences. They have graphical user interfaces (GUIs) that allow content creators to simply create content and publish them to styled “templates”, choosing from endless themes and plugins. The content created is stored within a database, and displayed to the end user or reader based on this pre-defined template.

Everything is packaged together, and the architecture of the CMS causes a heavy codependency between the front end and the back end. For example, when downloading Wordpress, what you’re actually getting out of the box and building upon is:

• A predefined theme (like Twenty Nineteen by Wordpress) with HTML, CSS, and Javascript.
• An optional further customisation of that theme with a page builder like Elementor or WPBakery.
• A predefined MySQL database with a predefined schema, changes to which require manually modifying the database itself.
• PHP that powers the usability of your site and links your theme to the database, constantly pulling entries (posts, media, etc.) from the database into your front end where the placement is defined by the theme.
• Further enrichments and customisation via plugins.

To visualise this content, the raw data for a blog post is pulled from the MySQL database by Wordpress’s PHP application, and pushed to the theme. The theme then converts the content into HTML and styles it based on the theme’s CSS to let the reader consume it.

Managing, creating, publishing, and designing your content is therefore completely within Wordpress itself, where content is stored in the database and pulled whenever the site needs to be rendered for a new reader.

On the flip side, a Headless CMS completely defies this logic by fragmenting the flow and decoupling the front end from the back end, keeping its focus on the content creation and storage, with little to no control on the front end rendition.

In this scenario, a typical setup might look something like this:

• You create your content based on self-defined schemas in a Headless CMS like .
• You connect your API endpoint from GraphCMS to your website through a data-fetching library like Axios, or even the native Fetch methods supported across server and browser environments.
• You query your content to your website, app, or other platform with GraphQL in the case of GraphCMS.
• You render the returned data in a way that makes sense for your application.

Therefore, when creating content in a Headless CMS, like GraphCMS, you’re simply focusing on the content itself, and not the layout or design. This is then delivered anywhere through the API, so a developer and a content creator can define how and where the content shows - regardless of the platform, design, style, or format.

What is Managed Content as a Service (MCaaS)?

Content as a Service is essentially the evolution of how content is managed, stored, and delivered. It is a service oriented model where the “Service Provider” delivers the content on demand to the “Service Consumer” via licensed cloud-based subscription services.

With the traditional CMS, the content had the option of being stored physically on a local, dedicated, or shared server, as well as in the cloud. Furthermore, security upgrades and database backups would be the responsibility of the entities maintaining their CMS. With the emergence of global distribution, Content Delivery Networks (CDN), and caching, cloud-based solutions are preferred for security, reliability, and speed.

A Headless CMS fundamentally offers content “as a service”, allowing content to be created and stored within the CMS, and then channeled to any platform via APIs. Since it isn’t dictating the content to be “for human consumption” directly, it allows a way to provide raw content to other systems that further refine the content to be rendered on the end platform. This way, your content is always hosted in a centralized “content repository” on the cloud - allowing you to create, manage, and edit your content whenever you wish, and accordingly distribute it to any systems and channels as and when required.

What is API-First Content Management?

Simply put, an API-First CMS is a Headless CMS. The concept it’s built upon is the maintenance of content within a content repository where APIs (like REST and GraphQL) distribute the content to multiple front ends based on how they request what content.

An API-First CMS allows brands and companies to reach out to consumers on any device, which is especially important with the emergence of IoT and smart products - that have drastically transformed the way in which consumers interact and engage with brands. Traditional CMS like Wordpress would make it near impossible to natively power voice assistants when used as a CMS for Alexa or Google Home, since traditional platforms are not built to deliver experiences to these kinds of devices.

A Headless CMS, however, is.

In the case of voice assistants, brands can just create content using a CMS for voice, and deliver structured data as answers to voice commands, responses to questions, or as snippets for feeds.

On a higher, and more pragmatic level, this also gives organisations the freedom to dictate their MarTech stack and define their own digital experiences. Legacy CMS would have teams fall prey to a vendor lock-in since the CMS would dictate the authoring experience, the visualisation of the content, and the interdependence of its own plugin ecosystem, whereas a Headless CMS gives brands the flexibility to freely integrate their preferred tools, software, and analytics to create their own digital experience platforms.

Why use a Headless CMS and do you need one?

Traditional CMS have the benefit of comfort - since we’re all familiar with them. A CMS like Wordpress is often a default solution when you want a simple website, don't have technical resources to create a custom experience, and are ok with working on templates that resemble generic websites.

However, for organisations that depend on delivering cross-platform experiences across multiple channels, especially on a global scale, a Headless CMS grows in importance. Since you have complete control over how and where content is delivered, a Headless CMS is usually a preferred option for forward thinking teams, especially in fast-paced industries.

Because a Headless CMS doesn’t restrict you to a specific technology (PHP and MySQL in the case of Wordpress), you and your team are free to build projects with preferred options like having a CMS for React, Angular, Vue, and so on.

If you don’t want to be restricted to a specific tech stack, don’t want to be constricted to pre-defined templates and themes, and need added functionality that lets you push content to multiple platforms, then investing in a Headless CMS would be worth looking into.

You may not need a Headless CMS if:

• Your content doesn’t need to be updated often.
• Your team doesn’t have sufficient development resources internally.
• Speed and scalability are not important factors to your projects.

However you may want to consider moving to a Headless CMS if:

• You have a diverse set of platforms and need a central content hub to pull the data from.
• You have front end development resources available.
• You want to use your preferred languages and frameworks.
• You want to deliver projects on JAMStack principles and remain agile in your processes.
• A unique design is needed to display your content.Your project is multi-device and multilingual.
• Content is regularly added or updated.

6 Benefits of using a Headless CMS

1. Front end freedom

Bring content to any platform (native apps, VR, IoT, etc). GraphCMS allows you to develop with any technology for any platform making your product scalable when your users need you to be.

2. Well structured data

Working with clearly defined data allows for your development team to know where to pick up, instantly. GraphCMS content infrastructure clearly defines the operations (queries, and mutations) supported by the API.

3. Future-proof content

A headless CMS allows for your content to be modified immediately and as-needed by your content creators. Minimize the impact of redesigns, product changes and migrations with a decoupled content solution.

4. Security and Scalability

With one point of connection, your headless CMS allows for only one access point of vulnerability. GraphCMS offers many robust features for protecting your endpoint including permanent auth tokens, DDOS mitigation strategies and more.

5. Team flexibility

You want to hire the most talented developers possible. No need to teach a prehistoric web template language just to manage your content. Work with any modern language stack your team pleases.

6. Consolidated content repository

It’s counterintuitive to copy, paste & recreate content for your app across different platforms! Consolidating all of your content within one API minimizes your overhead cost, time, and development resources.

Disclaimer: I work at and this was originally written by me for the .