As with all technological choices, deciding on what powers your website centers on the right trade offs.
Headless CMSs, single page applications and static site generators have been around for a while now in the web development world. In many enterprises these choices are frequently made without considering all the technical implications of the final implementation and often left opaque for many marketing stakeholders in what’s typically a development/IT endeavour. This thought piece is an attempt to get a high level view at those choices from a perspective of a digital marketing agency that’s been asked this question fairly frequently.
While applications for the headless CMS are many, lets focus on a particular use case of this technology, the company website. To frame the discussion further, lets consider a few common needs digital marketing has in terms of a 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
So what is a headless CMS?
A headless CMS is part of a architecture pattern that emerged recently as an answer to specific problems companies with a large digital presence had. It aims to decouple the responsibilities of maintaining content and displaying it, mainly because in the landscape of numerous platforms and mobile applications that were displaying the content, it wasn’t feasible to keep duplicating the effort of rebuilding content management interfaces or pass around content in word docs.
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. These CMSes provide most basic features you would expect from a enterprise CMS like fine grained access control, localization support, scalability and high availability and even things like media management with CDNs.
Some of the products in this category do specialize in certain types of content or scenarios but everything you need to define a content structure, operationalize a workflow and make the content available via neat REST APIs is there, and then some.
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 it 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, its 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 its easy to make the wrong trade offs.
Angular, React, Vue Et Al.
The reactive paradigm of building web applications that got popularized by FaceBook and their React library made creating single page and mobile applications much more streamlined and maintainable. It solves various problems of building a web application that requires displaying rapidly changing content. 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.
Predating React, Angular is a web framework made by Google that addresses many pain points of building complex single page applications on the web. One of its main features includes two way data bindings that allows for elegantly writing highly interactive apps.
While the distinction between websites and a web applications is often blurred these days, it still remains that most websites are not highly interactive or update a few times a second. The JavaScript libraries and frameworks mentioned above modernize some aspects of web development benefiting the development team and potentially company IT, but its important to consider how they fit in a marketing context and what benefits they deliver to the average CMO.
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 and their clientside nature supports that effort in various ways, a lot of times it fails to do the same for the search engine crawlers, thus leaving a lot to be desired in terms of their SEO value. A good website is really only good if somebody can easily find it.
A website built purely with JavaScript, really only exists in the visitors browser, making its contents and structure more difficult to parse for the search engines than traditional websites. While its true that search engines have gotten way better at parsing such websites, its also true that it costs more resources for them to do so. This leads to such websites being penalized in favor of ones that are easier to parse and the updates to their content are indexed less often.
Operational value
Creating new landing pages, releasing new products or crafting new sections for the company website are a frequent task for Marketing departments and teams belonging to that purview. For a good marketing operation, its important that these tasks are efficient and happen with as little friction as possible.
Because the building blocks of a headless CMS powered website are more generic and non-specialized, they often lack basic features of websites and content management: metadata, user-editable menus, blog sections and post indexes, RSS feeds, site search, editable URLs for pages, protected pages, content previews and scheduled publishing etc. Reduced complexity is great and beneficial for many software projects, but when its faced with day to day website management, its often a debilitating to find out a basic feature hasn’t initially been scoped for and needs to be built first.
Building things from the ground up allows for more control of end result, but it also bears a greater risk of broken implementation. Having a large and capable development team with many specializations and dedicated QA makes that possible but the feasibility is a very personal question for most organizations.
In a lot of cases, even smaller content updates and modifications end up asking for developer time, creating a bottleneck that slows down any 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 resolved by implementing SSR (server side rendering) of your JavaScript applications or using static site generators instead of clientside JavaScript.
Workarounds like that do inevitably create complexity in software, have drawbacks and caveats and should be carefully weighted out. The more complex the project becomes, more resources it consumes – requiring more developers, more time and more effort.
To be perfectly clear, its 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, security and cost effectiveness, the extra complexity is a good trade off.
Traditional CMSs
While discussing the topic of headless CMSes, its worthwhile saying that the more traditional players in the CMS segment these days all fit perfectly into this architecture pattern and are able to work headless. Well represented open source systems like WordPress or Drupal both 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, its 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.
Recap
Various headless CMS architectures and approaches have a lot of applications across industries but to cope with the underlying complexities they require resources and dedication usually available in large enterprises.
Pros
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
Cons
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
- Content management for a interactive web application; Any new or existing application on almost any platform can leverage the restful APIs of a headless CMS
-
; Content repository powered by a headless CMS that powers email marketing, personalization engines, numerous web properties
