The Future of Content Management Systems is Here — and It’s “Headless”

If you’re in the business of publishing content (and who isn’t these days?), the choice of a content management system (CMS) is probably one of the most important ones you’ll make.

Traditionally, platforms like Drupal or WordPress have been the go-to choice for many content publishers. While these platforms have stood the test of time and helped countless companies grow, they have one critical flaw: They’re just not flexible.

They run on technologies like PHP, which tightly couples your content with how it’s presented. They bank solely on “server side rendering.” And they prescribe a workflow that you merely adapt to. In other words, they weren’t built for the “internet of things” — at all.

This wasn’t actually a bad thing…back in 2010. But in a multi-modal, multi-channel digital environment, traditional, monolithic CMS platforms are becoming dinosaurs.

There’s a new world order now, one that calls for more robust and flexible content publishing capabilities, allowing businesses to de-couple their content from the design and make it available to easily and seamlessly publish and update across any channel or device.

Enter the “headless CMS.”

What is a Headless CMS and What are the Benefits?

A headless content management system, or headless CMS, is a back-end only content management system built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device.

Its cloud hosted, less cluttered and focuses mainly on content creation through an intuitive user interface. The goal is to let content creators focus on adding content without having to worry about things like templates, plugins and databases.

To really illustrate the benefits of a headless CMS implementation compared to more traditional content management systems, let’s turn the clock back for a minute and run through a quick scenario to see where we’ve been (which helps explain where we are today):

2010

It’s 2010. You’re a successful internet content publisher with a solid user base. Your articles are top notch and you’re even publishing video content. You’re ahead of the curve. Ad revenues are rising.

Cut to 2012

More users are using their smart-ish phones to access your site. Their experience is less than ideal because your site is not optimized for mobile but your content is so good, that they put up with your broken UX. But you’re no amateur and care deeply about your users. You bring together your best front-end developers and, within a few months, they help turn your site “responsive.” It works like a charm on mobile browsers. You’ve navigated the tumultuous highway of technology and mobile traffic skyrockets. Business is booming.

Now warp to 2018

Your content pipeline is amazing but let’s face it, people just aren’t reading as much as they used to. Your users want more video. You want to live stream events, create podcasts and push your content through third-party channels. Your marketing team wants to rebrand everything and launch your very own mobile app.

But wait…all your content is still locked in WordPress!

Can you syndicate content out using an API to third parties…

Not easily.

Can you drive a mobile app using WordPress?

Uh, no.

What about live streaming???

Never.

You’re still trying to find the right plugin to help you do all these things… but what you ended up getting was unsafe malware that stole your data.

What the hell!?

Welcome to the new world order

You’ve just gone from being a content company to a data company. And as someone famous once said:

“With great data, comes great responsibility”

Your users have changed, your content is more dynamic and you need to push content to more channels than ever before. How do you handle all this variability?

The answer is one you don’t hear a lot about when dealing with a traditional CMS: application program interfaces, better known as APIs.

Over the last decade, APIs have exploded. Whether its getting your weather update when you wake up or looking up the shortest route to work on your phone, everything is essentially driven through APIs. In essence, APIs are the communication standard that power everything on the web.

So it only makes sense that you expose all that content you’ve written, created or curated over the years using APIs. Right?

You’re probably wondering: “But I don’t even know what A.P.I stands for. How am I supposed to rig these up to expose all my content?”

And that’s where a headless CMS shines. It comes with the “APIs” built in. Only published content is API accessible.

So let’s say you’re working with a vendor that’s building a mobile app to serve your content. You can give this vendor an access key. The vendor sets up an application server (or web server) on the cloud. The vendor can now use his/her access key to pull all your content out using the API provided by your headless CMS. Alternatively, with a little configuration, you can setup your CMS to ping the vendor’s server whenever new content is published.

Pretty neat :-)

But now that you’ve got this basic setup going, you’re probably wondering: “But what happens when I don’t want to work with Vendor A but want to continue working with all my other vendors/partners? Can I selectively turn off their access to my content?”

Yes. You can simply change or delete their access key. No more content for them (lol… cheeky!)

“All this seems too good to be true, what am I missing here?”

Key Considerations When Choosing a Headless CMS

While a headless CMS can often be liberating at first, things can get out of hand if you’re not careful. Here are a few things you should consider before selecting a headless CMS:

Monthly fee

Because this headless CMS is a cloud-hosted platform, you’re likely to be paying a monthly subscription fee (as opposed to a one-time licensing cost). Depending on which CMS platform you choose, your monthly burn can be anywhere from a few hundred to about a thousand dollars a month. Depending on the scale of your operation, pick a headless CMS that fits your needs as well as your budget.

Data migration can be a major lift

If you have a lot of content sitting on a traditional CMS like Wordpress, migrating that over to a headless system can be a bit daunting. Headless CMS work on very strong internal schemas (just a fancy name for a specification for organizing data). This is especially true for outfits that don’t have a strong engineering team (and no, while your IT department is great at their job, they may not be equipped to handle the considerable engineering effort that is needed to handle data migration). For instance, if you’re currently on WordPress, you’ll have to pull all your content out (from WordPress’ database), write scripts (yes, actual coding is involved) to turn all this data into the schema supported by your headless CMS and finally, import all this formatted data into the headless CMS. If your formatted data isn’t “schema-perfect”, the CMS might reject the entire import or worse, you might end up with fragmented imports.

No Plug-ins. That’s a double-edged sword

Most headless CMS’ are gigantic data stores that provide API-driven access to your content. Since they don’t deal with the rendering of this content (no templates, remember), they have no need or incentive to provide plugins that “plug data into your templates.”

This approach is definitely more secure (remember how some WordPress plugins are actually malware and can cause major damage). But in the same vein, the onus of building rich features falls completely upon your engineering team. You can’t just install something that adds ‘Search’ to your site. You’ll have build ‘Search’ on a custom backend. While that’s not impossibly difficult, you need a strong engineering team that knows what it’s doing to get around this construct.

Adopt a CMS with a component-based data model

While most headless CMS’ support this, it wouldn’t hurt to double check before you take the plunge. The content you create has to be displayed somewhere or consumed by someone. Being able to organize your content through a flexible, component-based approach is critical to easily presenting this data across multiple channels. Trust me, your web and app development teams will thank you for it.

In Conclusion…

To sum it up, choosing a headless CMS is not an easy decision. You have to evaluate your needs, the needs of your users, your own technical capability and potential use cases very carefully before diving in.

Having said that, if you’re looking to grow now and build a strong foundation of meaningful content for the future, switching to a headless CMS is not a matter of “if” but “when.”