-Headless CMS Differentiating Factors

This blog post describes some factors that can help headless content management software vendors differentiate their offerings from most of the competitors in their field. Please comment on this blog post to describe important factors that differentiate headless CMS offerings for you.

Update 15.Dec.2025: After years of frustration with WordPress, I am finally abandoning this blog. The content will likely stay here for some time, but new content will appear here:

• jpw3.com

Composable software applications in saturated industries have become largely commodities. By this I mean that there is little apparent differentiation between most of the offerings in a single market segment such as content management or search, and those differences can be extremely difficult to identify and evaluate. As an enterprise architect, I would look for the following aspects in a headless CMS.

Data Modeling Capabilities

While the list of supported field types is important, what I really need is something that Interwoven TeamSite had as long ago as the year 2000: the ability for a group of fields to repeat within a content entry. I don’t mean that a single content entry can reference some number of related content entries (or have child entries, in a CMS that supports hierarchies); any CMS should be able to do that. I mean that more content can appear inline within a single entry rather than requiring users to locate and manage (lock, version, workflow, translate, publish, etc.) numerous fragments just to create a single page.

The simplest example is something like a FAQ that consists of some general content fields followed by a list of some number of questions and answers. I believe that most users would prefer to manage that content as a single entry, although there are advantages to breaking it up (individual Q/A reusability, ability for multiple users to work on the FAQ simultaneously, and so forth).

From my research, Contentstack has the best implementation of this that I’ve seen in both its Group Fields and Modular Blocks features. I wish that more CMS vendors would provide equivalent functionality. Another great data modeling feature in Contentstack is that basically any individual field can contain a repeating list of values.

Additionally, the JSON representation of this data should be clean and simple, with minimal vendor-proprietary details. Contentstack does a pretty good job of that as well. If you know of any other CMS that does anything similar, please comment on this blog post.

Another consideration is data structure reusability, meaning that multiple content types can use common data structure definitions. For example, every entry that represents a page can include the same fields for storing page title and metadata without redefining those fields.

Sitecore CMS did a great job of this (and many other things, honestly), in this case using “template inheritance”, where Sitecore defined “template” to mean what we now call “content type” or “model”. Interwoven TeamSite had this capability, but I forget the terminology they used – I think a “template” (content type definition) could call some custom Perl script or something. Contentstack has it in its Global Fields functionality. I’m less familiar with other CMS products, but I’m sure that many have equivalent functionality. Who would want to implement a CMS solution without this capability?

Hierarchical Data Representation and Default URLs

In most content management systems, some content entries represent pages on the website. In most websites, sections contain pages. This implies a hierarchical data structure for content entries, where one entry represents the home page of the site, some of its child entries represent section pages, and those section entries can contain pages, with entries nested to any level. Basically, the CMS exposes something like a file system tree, but storing entries in its document database rather than a file system. Though files aren’t always the worst way to store data…

Related to this is the ability to construct a default URL for a content entry based on its name/slug and location in the hierarchy relative to the names/slugs of its ancestor entries. Interwoven TeamSite had this (or could have; I think I had to write some Perl to do it how I wanted), but that’s because it generated static files. Sitecore CMS had this, as well as aliases to override the default URL for an entry. If I remember correctly, Kontent.ai has something relevant, but in some kind of option pack rather than its core offering, and not exactly how I would prefer. The gap in headless CMS is significant enough that Uniform.dev addresses it with “project maps” as well.

Before commenting about omnichannel, experience orchestration, or how I shouldn’t think so page-centrically, please see the full discussion at the following URL, noting that we need to meet the users where they are or half a step ahead, and that users think about and honestly demand page concepts:

• https://www.linkedin.com/posts/johnwest3_cms-headlesscms-composable-activity-7190939629389283328-Sc0A/

Retrieve Content Entry by URL Path

This is basically the opposite of the requirement above: if an entry has a location in a hierarchy, and a URL based on that location (or really, any URL, if the user doesn’t want to use the default), then I want to be able to retrieve that entry by its URL path without knowing the content type of that entry, and especially without knowing its ID. It’s stunning to me that to achieve this with most headless content management systems I would need to hard-code URL routing in the front-end or specify every possible page content type in a GraphQL query.

Worthy Mentions

There are countless other potential differentiating factors. But without addressing my core needs as an architect or engineer, these aspects are less relevant. Customers selecting a content management system should consider the factors that are most important to their users. Here are a few that come to mind.

• AI: Of course, every vendor is embedding “AI” into their products today. Kontent.ai has the best implementation that I’ve seen for assisting users.

• User Interface: Usability is key to user acceptance and productivity. I’m more of a “just edit data in a table with almost no whitespace” kind of guy, so I’m not the right person to evaluate user interfaces.

• Page Design: Another necessary evil.

• Head Technology: Yep, I said it. Give the customer what they need to achieve their objectives efficiently.

Conclusion

Let the flames begin.

PS: Sorry, after an incredible number of tries, I gave up on ChatGPT creating a decent image with the monitor pointing the right direction. And apparently its dataset on images of monitors is about as old as I am.