Decoupled—or “headless”—content management systems have been trending in the last few years. This web development strategy, in its most basic form, is a “write once, publish anywhere” technology that separates the content from the presentation layer. Well, um...what the heck does that mean? It means that you can publish a piece of content and then use different systems to display that blog post on a computer, a mobile device, a voice-based system like Amazon’s Alexa, or even a smart watch. Basically, it allows developers to write to many platforms without having to tediously recreate the wheel each time. (I think…)
It is a hot topic in the Drupal community. In fact, Acquia is holding Decoupled Developer Days this weekend (August 19-20 in NYC). Much of the conversation is still occurring in the developer community, but it is also important for marketers to understand the implications of this strategy as well. The strategy has its place, but is not always the best option for several reasons.
However, first, here are some terms marketers should know. Then I’ll share what factors you should consider when deciding whether to follow a decoupled CMS strategy.
What is Decoupled (Headless) Drupal? Some Terms to Know
A decoupled CMS is one where the CMS serves as the back-end to store, maintain, and edit content; but no longer necessarily provides the delivery of that content. It’s considered “headless” because it means chopping off the part of the CMS that provides the web display.
A headless CMS usually delivers content through an API, which means that it can deliver content anywhere, on any device. You will often hear this strategy as API-first.
API-first is an approach that starts with the RESTful API as the communication between the backend, headless CMS and user devices such as websites, mobile applications, wearable, IoT devices and more.
Content as a Service (CaaS) is like a Software as a Service (SaaS), headless CMS. Think of Drupal as the host, managing the content and offering that content as a service. This separated content management and display means that the content is easily used by other sites and apps.
The decoupled CMS approach is industry wide and affects more than just those using Drupal. But if you have a Drupal website, you will want to know more about headless Drupal. In normal installations, Drupal provides a way to store data, an administrative area to manage content, and a way to display data. In a headless installation, the data display functionality is replaced with an API to the data. Then, a different framework uses that API to access, format, deliver, and display the data.
Drupal 8 includes a RESTful Web Services module in its core which plays well into adopting a headless CMS. This module along with other powerful modules such as Views and Paragraphs makes Drupal a good choice for a decoupled application.
Benefits of Decoupled Drupal to Marketers
With a headless CMS, it is possible to build flexible, responsive, interactive experiences for your users. New devices are popping up all the time and one of the big questions that marketers need to ask is how they will provide content on them. When the user interface is decoupled from the CMS, the logic for displaying content on each device is on the front-end and can provide full control of the user experience in its native tools. In other words, you, as a content provider, no longer need to worry about how the content is going to be displayed as that is handled on the device itself.
Decoupled CMS may also be faster. When the logic is on the front-end interface, the back-end CMS can be streamlined. The back-and-forth interaction happens in real-time in the browser.
At this point, you might be wondering why everyone isn’t heading toward decoupled CMS. After all, as a marketer, being able to get content out to any device quickly is paramount. However, there is a price to be paid for this ability. In many cases, that price is quite high.
Reasons Why Marketers May Not Want to Decouple Drupal
Drupal is a complete CMS with years and millions of hours of development behind it to provide a full-featured system. Going headless bypasses the value that Drupal brings to content delivery. You lose a lot of functionality that must be re-created on the front end. That will cost you more in development time and expense. Often, headless sites need multiple layers of complexity to gain back the advanced features that you have lost by rejecting the full Drupal system.
For example, if you need multi-lingual content, you will pay more for that functionality with custom development for a decoupled Drupal backend. Meanwhile, the full Drupal CMS offers multilingual support out of the box.
When you choose to use a decoupled Drupal strategy, it is important to consider the impact on SEO. You will lose standard SEO functionality and SEO will take considerably more time and money.
Here are three examples of real-life problems we have faced when working with customers who have decoupled Drupal 7 or 8 websites:
Meta tags are not automatically output. While the Metatag module was installed and properly configured, the data wasn’t being pushed to the page. Search engines weren't seeing them. Extra code had to be written to retrieve the meta tags from Drupal. This took weeks of lost time and dozens of hours between the developer and the SEO team.
Decoupled sites that have non-standard URLs. If you are changing the way that URLs work, other things break, like Sitemap. This is another case where functionality had to be re-created. In fact, we opted to not use the available modules and use a third party service to crawl and create a sitemap manually because the development overhead would have been too costly. This functionality is trivial in a non-headless environment, not to mention free.
The current crop of SEO SAAS tools do not work on headless sites. If you use any third party tools like Moz, you’re out of luck when it comes to crawling and understanding your decoupled site. While those services may add support for headless CMS in the future, as of today, many hours of manual evaluations and looking at pages that used to take seconds with an automated tool are required.
And a lot more. Almost none of the recommendations I make on my SEO Checklist work with decoupled Drupal sites without some kind of additional development time and effort.
Keep in mind that all of this custom development means that you are responsible for maintenance and upkeep of this code. If there are issues or bugs with your website, your IT team will need to resolve them. Security problems? You’re largely on your own.
Can You Justify Headless Drupal?
If all you need is a CMS to manage content for a responsive website, headless Drupal is overkill and will actually slow time to market. The times to consider decoupling Drupal is when you have several different uses for the same content such as multiple websites displaying the same articles, various front-end device, and custom user experiences. Or, perhaps when you need truly real-time updates to a site where performance would be killed by using Drupal’s entire system (and even then, there are ways to do this without headless).
Powdr Ski Resorts could justify using headless Drupal because they have multiple websites for their network of ski resorts as well as around 50 unique events each year. They need flexibility to have different designs on the front-end but uniform data on the backend to manage content. The website project was completed by Elevated Third, Hoorooh Digital, and Acquia. You can learn about the challenges of this project in this blog: Decoupled Drupal: A 10,000 Ft View.
When the right situation exists, you still need to evaluate the financial impact of decoupling Drupal.
Additional costs for decoupling Drupal include:
Custom development to recreate existing Drupal capabilities
Custom development to create the data hand-off
Custom development for each device
Additional development to implement SEO
Added SEO maintenance and reporting costs
Maintenance of custom development
You may evaluate these costs and still find that headless Drupal is the way to go for your business. But in the majority of cases, the costs are too high.
And just to be perfectly clear: I’m not anti-headless Drupal. In fact, I’m very much in support of it when there are very good and specific applications that call for that particular set of functionality. It’s not bad, it’s just not the right tool for most sites.
That said, I’m very anti-headless when it’s just “for fun” or “that's the way the cool kids are doing it”. That’s crazy and expensive. Unfortunately, that’s what I’m seeing more and more. Implementing headless Drupal for static brochure websites is irresponsible and will drive people away from using Drupal in the long run.
Drupal SEO Services
Before you head down the decoupled Drupal path, be sure to factor in extra time and expense for Drupal SEO development. Volacci can work with your development team to ensure that the right functionality is available in the finished product. Contact us for an evaluation of your SEO needs.