Web API, services, architectures, REST and RESTful APIs, cross-platform applications, progressive web app, single page app, router — these technical terms and the many related subtopics they lead to — I hope I haven’t left you lost.
All of these processes reflect a fascination I’ve experienced while working with data — particularly when accessing and using data. The handling of content (content) requires a distinct and separate context. Consider this: approximately 60% of accessible websites are built on WordPress, and every second, 17 pieces of content are being published through WordPress1.
Of course, all of this volume brings with it problems, as well as new perspectives and solutions. The concept of Headless CMS, which is the focus of this article, is one of the concepts/methods that emerged from these new thinking and solutions.
Headless Content Management System (CMS)
Before defining Headless Content Management System (CMS), we need to understand what “headless” (or API-based) means. Having just discussed WordPress’s remarkable usage, let’s continue with the headless approach using WordPress as a reference point.
[object Object]A WordPress website has both a front-end and back-end. The code is rendered on the server and then displayed to the user in their internet browser. With frameworks such as React, Angular, or Vue, this process is being reevaluated, and the View layer (as in MVC architectures) now operates directly within the user’s browser. This approach distributes server load and resources. In this context, headless refers to the front-end, while body refers to the back-end.
The head (head) is separated from the body (body), resulting in a headless architecture. Thanks to this approach, the content management system (CMS) consists solely of the back-end. When content is requested via any device, a request is sent to the browser, the server responds, and the browser processes the response. The content (let’s say data) can be stored anywhere (e.g., Google Drive, GitHub repository, etc.) or not stored at all, being retrieved instead from different services (via APIs). The CMS is solely responsible for content handling and has no other responsibilities.
I should also mention that a headless CMS can be described as Content as a Service (CaaS) or managed content as a service (MCaaS) within the context of a service-oriented model, or even as a Software as a Service (SaaS) CMS.
Content management systems like WordPress (monolith CMS, let’s say) typically include both a content (content layer) and a presentation (presentation layer), whereas a headless CMS consists only of a content component; it handles responsibilities such as organizing content management operations, content workflow management, and structuring content hierarchically. Since the headless CMS does not include a presentation layer, it is considered “pure,” and can be easily displayed on any device (website, mobile, tablet, Internet of Things devices, smartwatches, etc.)2.
I don’t want it to be perceived as a criticism of WordPress. A headless CMS hasn’t emerged to replace traditional content management systems, but rather as a new way of approaching content distribution—establishing a foundation for API-driven content delivery3. Indeed, there is an overlap between the two approaches. However, the decision should be based on how content is acquired and presented. For example, WordPress enables access to content in a separate, dedicated manner through its WordPress REST API4, and allows for content management5.
Headless CMS Examples
You can access numerous different headless content management systems via Headless CMS. Below are some of the most prominent examples: