Skip to main content

The Definitive Guide: What is a Headless CMS?

What is a headless CMS?
The definitive overview of what a headless CMS is, its benefits and downsides, its main use cases, a checklist for how to choose the right one, and the best CMSes today.

What is a headless CMS?

A headless CMS is a content management system (like a database for your content). It sits in the backend of your website, mobile app, or other digital property decoupled from the presentation layer or “head”.

This decoupling means your content can be served into whatever head or heads you want. This provides huge productivity benefits for technical and business users alike.

Important Definitions

As more companies adopt headless CMSes, here’s your cheat sheet to understand what’s going on.

A CMS is a content management system. It helps companies manage and publish content digitally. Used to create, edit, and organize content.

A traditional CMS is a platform that connects the frontend and the backend of a website into one product. Handles the end-to-end website creation process without much flexibility. Examples: WordPress, Acquia, Sitecore, and AEM.

A headless CMS is backend platform that manages digital content. It is detached from the frontend of a website. This gives companies have powerful control over where and how content gets delivered to their users.

When talking about CMSes, the body is used to describe where your content is stored and authored. The head, or presentation layer, is used to describe where your content ends up — the visual presentation of digital properties like websites or mobile apps.

Reusable content is when content stored in one location can be published to many different formats or platforms.

A content field is an atomic field that stores content in a headless CMS. The content in each field can be a string, image, array, object, and more.

A content type is a grouping of content fields in a headless CMS. Content Types are reusable and usually structured by a common purpose.

A content model is a representation of all the different content types and their interrelationships within a headless CMS.

A reference field is a content field that links to another content field or content type.

Structured content is content organized in a predictable way outside of the presentation layer so that it’s ready to be consumed by any interface.

Digital properties are all of the digital "locations" your users interact with your company in. Common examples are websites and mobiles apps.

Do you need a Headless CMS?

Here’s the truth. A headless CMS isn’t the right fit for every business. So before you go any farther, here’s what you should consider before you decide to go headless.

Is a developer or agency involved?

A headless CMS requires a developer to implement and maintain it. Once implemented, it accelerates your team. But if you don’t have developer or agency help, a headless CMS is likely not the right fit.

Need to manage multiple digital platforms?

A headless CMS lets you update content in one place and publish to multiple platforms. If you need this omnichannel support, whether today or in the future, a headless CMS is the right fit.

What 3rd party solutions do you need?

Traditional CMSes have a limited number of working integrations. With a Headless CMS, you can integrate any 3rd party solution you want. Make sure you won’t be trapped (unable to do what you need) because of a vendor limited ecosystem.

How critical is technical freedom?

Traditional CMSes will force developers to use specific technical tooling. Can your team do their best work with them? Are they well versed in them? A headless CMS lets developers use their desired technical architecture. This ensures devs can do their best work and that time-to-value is expedited. Check with your developers.

Staying on brand important?

A Headless CMS gives you fine-grained control of your brand’s identity. If ensuring your digital properties stick to brand is important, a headless CMS is likely the right choice.

Traditional CMS vs Headless CMS

Here's a comparison of the main differences between a traditional CMS and a headless CMS:

Traditional CMSHeadless CMS
Choice of technologiesRestrictedLimitless
Backend architectureMonolithic, all-in-oneMicroservice, best-in-class
Omnichannel supportRestrictedLimitless
Content modelBuilt for a single pageBuilt for many formats and products
SpeedLonger load timesFaster load times
Developer experienceLegacyModern
Use of plug-insYesCustom solutions
Technical debtInherent to providerManaged
LocalizationYesYes
Hosting & deliveryProvider specificYour choice
WorkflowWaterfallAgile
Integration and deploymentPunctuatedContinuous
UpdatesScheduledContinuous
Vendor lock-inLocked to the providerFreedom of choice

Then what is a decoupled CMS?

A decoupled CMS is where a traditional CMS adds API options to deliver content to multiple digital platforms.

In other words, with a decoupled CMS the head can optionally be detached from the body. The problem? The content model is still restricted by the presentation layer. This restricts how, where, and in what context you can use your content.

A headless CMS serves content creation and storage without any attachment to the head. This true separation from the presentation layer gives you technical flexibility that can’t be provided by a decoupled CMS.

Git-based vs API-Driven CMS

With a Headless CMS you can store your content one of two places — either a Git repository or an API-based CMS platform. Here is what they are and the pros and cons of each.

Git-based CMS

With a Git-based CMS, your content is stored in files in your repository. The setup is simple. If all you need is a website(s), it's limitlessly flexible and less expensive — there are no bandwidth limits, data caps, or vendor lock-in as you fully own everything.

A Git-based CMS is great for companies that need to serve content to just websites and don't have need complex permissioning systems. It's not great for companies trying to reuse content across websites, mobile apps, etc.

Platforms that provide this service include Stackbit, Netlify CMS, Jekyll Admin.

API-Driven CMS

With an API-based CMS, your content is stored by a CMS provider. The setup is more complex. But if you have multiple digital properties (ex. website, mobile app, etc.), you can serve your content to them by connecting to the CMS provider's API.

An API-based CMS is great for companies that need to serve content to multiple digital properties or need field-level, complex permission system. An API-based CMS is not great for companies looking to server one or multiple websites as it can cause unnecessary cost and limitations.

Platforms that provide this service include Stackbit, Contentful, Sanity.

Why Modern Businesses Are Choosing Headless CMSes

Technical Benefits

  • Adapt to any speed and performance needs

  • Fit your exact tech stack and architecture needs

  • Reduce tech debt by decoupling presentation from code

  • Work faster in your preferred frameworks and code languages

  • Unblock hiring bottlenecks caused by small, decreasing talent pools of legacy CMS experts

Business Benefits

  • Easily expand to into new markets with new digital products

  • Create and edit content once, publish in all channels

  • Work independently of development cycles

  • Improve site performance, SEO, and marketing capabilities

  • Eliminate publishing bottlenecks and inconsistencies

Easier Scaling

Headless lets you manage your content across multiple platforms from a single source of truth, change developer tools at any time, and benefit from sending your content to high-performance cloud-based hosting.

Low learning curve

With a headless CMS, developers don't need to learn all the tech built around the CMS as they would with a traditional CMS. This makes your organization's time-to-value much faster.

Developer Freedom

Since headless CMSes are tech-agnostic, developers can choose their frontend tooling. They can interchange parts of your stack or move from one framework to another without affecting the CMS.

Enhanced Security

Because a headless CMSes content is separated from the presentation layer it’s a smaller area of attack.

More Channels, Bigger Audiences

A headless CMS isn't tied to a single presentation layer, say one specific website. This means it can reach audiences across multiple digital channels (ex. multiple websites, apps, VR/AR headsets, TVs, smartwatches, internal admin websites, etc).

Update Once, Update Everywhere

When you need to update a product, service, or campaign across every instance, it's tedious. With a headless CMS, you update it in one place. And when ready, it publishes to every instance, even across multiple platforms.

Faster Authoring Experience

With a Headless CMS, you don’t have to manage website concerns every time you publish content. This substantially increases the pace at which your business team and website team can work.

Future-Proofing Your Business

Since a Headless CMS can deliver content to any channel, you're set for new platforms that appear in the future. Adopting new platforms like smartwatches means you won't have to reauthor content. You simply access the content through their API and display it in their format.

Use Cases for Headless CMS

For Companies

  • You support multiple websites and/or native mobile apps. You want to publish content once and have it display everywhere, instead of reworking it for each channel.

  • You have many sub-brands or experiments that you run across new websites. You want the ability to spin up new pages and experiences quickly, without getting bottlenecked by the tech team.

  • You’re publishing a lot of content, frequently. You need to ensure consistent brand voice, workflows for publishing, the best user experience possible.

For Developers

  • You want to enable marketing to update the website and any digital platform without needing to be part of the process.

  • You need custom integrations and tooling that don’t integrate with a traditional CMS.

  • You want to own the code and the hosting experience behind the site for better control of the user experience.

  • You’re serving content on many platforms and need structured content to support them all.

For Business Users

  • You’re publishing content frequently enough that you need to set brand guidelines to ensure a coherent user experience.

  • You want to publish content without including your tech team in every publishing cycle.

  • You want more granularity over controlling marketing aspects like SEO, site structure, and how content appears across platforms.

  • You want to control the editorial workflow of what happens between the time of first edits to clicking, “Publish.”

Checklist for How To Choose a Headless CMS

1. Do you need an API-based or Git-based CMS?

With a Git-based CMS, you access your content by querying files stored in your repository. If all you need is a website(s), it's incredibly flexible and less expensive — there are no bandwidth limits, data caps, or vendor lock-in as you fully own everything.

With an API-based CMS, you access your content via the CMS API. If you need to power multiple digital platforms or have complex roles and permissions, this is the solution for you.

2. Consider, is it industry-specific?

Some CMS solutions are meant only for e-commerce or content applications. Before you commit to a CMS like this, are you confident that being locked into an industry-specific tool will allow you to scale?

3. Do you have to learn new frameworks?

A CMS that lets your team work in their preferred coding languages will speed up your time-to-value and make maintenance easier. If you have to write special frameworks or wrappers to make a certain CMS work, consider that your time-to-value will likely be slower.

4. Is there a simple way for business users to create and update content?

Someone will need to create and publish new pieces of content. Does the CMS you’re looking at have a simple, visual way to achieve this? Make sure you can understand how the publishing flow will work for your business like before you commit!

5. Can you create structure around how content is created and published?

As your company grows, you’ll want to align the ever-growing creation of content with your brand identity. Does your CMS allow you to set up editorial workflows for what can be published, as well as what that content will look like on different platforms?

6. Do you own the code underlying the website?

Code ownership will allow your company to truly control your company’s website and digital properties fate. Ask if the headless CMS requires any dependencies, wrappers, or plug-ins that will force you to marry your digital properties to their system.

7. What integrations can you use with the tool?

Some industry-specific CMS or “easy site builder” solutions have limited integration libraries. Before you commit, make sure you are confident they have the integrations for the tools you need. Look for solutions that allow you to own the code beneath the website and other digital properties.

The 3 Honest Downsides of Using a Headless CMS

1. They require a developer

A developer needs to be on hand to implement a Headless CMS. For future maintenance, you’ll also want a developer as customizations are too technical for a business user to enact.

2. Workflows often end up with a developer bottleneck

Because a headless CMS’s UI looks a lot like a database, all too often marketers end up dependent on developers to implement even the simplest of updates.

This can overflow the tech team’s ticketing queue with marketing requests; frustrate developers because they waste time on low-value requests rather than writing scalable code; and frustrate marketing because they can’t independently ship against their KPIs

3. There is no visual editing experience

Marketers today are used to using visual site builder when editing their website. With a headless CMS, marketers are forced to use a UI/UX that can be very hard to navigate causing inefficiencies with their workflows.

Stackbit fixes this.

Stackbit: A Headless CMS and More

With all their benefits, headless CMSes still have one big problem.

The developer bottleneck.

Because a headless CMS’s UI looks a lot like a database, all too often marketers end up dependent on developers to implement even the simplest of updates.

This overflows the tech team’s ticketing queue with marketing requests; frustrates developers because they waste time on low-value requests rather than writing scalable code; and frustrates marketing because they can’t ship against their KPIs.

Businesses from venture-backed startups to Fortune 500 companies are using Stackbit to fix this.

Stackbit, out of the box, provides you with a headless CMS and a visual website editor.

Need to swap in a specific headless CMS like Contentful or Sanity? It’s no problem. Stackbit’s visual page builder continues empowering marketing to create new pages and add components.

And unlike other visual headless tools that force your to use their frameworks, Stackbit uses an annotation-only methodology to turn your custom website into a visual page builder.

<Link href={url} *data-sb-field-path={annotations}*>
  <span>{label}</span>
</Link>

The only code tied to Stackbit to make content editable is lightweight data attributes. And these attributes can be ripped out at build time to keep your bundle small.

With no set frameworks, wrappers, or plug-ins — you get an unparalleled combination of limitless development flexibility and marketer independence.

Architecting a new website or digital experience? Looking to unblock your marketers who are already using a headless website?

We can help.

Book a free architecture consultation

Book a demo, no strings attached