These days, most websites use some kind of Content Management System, a CMS. WordPress is such a CMS and it has revolutionized the internet, making it easy for non-programmers to set up a website in a few hours, customize the design and start publishing content.

Which CMS is used by magazine publishers today?

WordPress powers almost 60% of all CMS based websites today, commercial and non-commercial. While there is no official figure, it's likely that this number is higher among magazine websites. It is very easy to launch a WordPress website and there is a large number of themes and plugins to select from to customize the website for ones needs.

Among RunMags' customers, most use WordPress, a few use Metro Publisher, a few ePublishing, three use Episerver, and a couple of them use the increasinly popular platform Umbraco. There's really nothing in particular that distinguish those customers using WordPress, vs. Metro Publisher vs. Episerver vs. Umbraco. Wordpress is also successfully used by a few of our Enterprise customers so it can definitely scale.

Enter Headless CMS

In our view, any publisher currently contemplating on developing a new website, they should educate themselves on the subject of "Headless CMS", where content channeling and website speed are the two major benefits for a publisher, compared to traditional CMS platforms, the so-called Coupled CMS. In the end "Headless" may not be where you want to go, but you should at least educate yourself on what that is.

To simplify it, a Headless CMS is a pure database content repository. Unlike a traditional Coupled CMS, it does not present the content, i.e. the text and images, on your website or app. Instead, you build a front end (website, app or other channel) on a different software platform to which the content from the Headless CMS is delivered via an API. Also to simplify it, the Headless CMS in existance tend to have a user interface that makes it easy for content generators (i.e. the writers of those precious articles) to produce their work, have it approved and published. Most traditional CMS:es don't have a great workflow engine for content generation and approval.

Omni-channel publishing

As it is becoming increasingly important to create content so it can be used in various channels (print, web, apps, smart watches, email newsletters, social media, bots, etc.), the publisher's content repository should be able to store and publish that content to all those channels with a minimum of manual labor. If the business strategy is to maintain print as a premium channel, reduced versions of the content should probably also be presented on the website to drive SEO. If there's an app published behind a paywall, then the full article should be presented there, possibly with video or other media.

For some time WordPress has been able to function like in a headless CMS solution and Umbraco recently announced Heartcore as their headless CMS solution. While there is certainly a hype around Headless CMS that may fade, the ability to drive website speed and enable omni-channel publishing should not be ignored by publishers. It should at least be explored in detail.

Some examples of Headless CMS worth taking a look at

It seems like these days, new Headless CMS platforms are appearing everywhere. There are both open source platforms and proprietary platforms available. Here are some that we have explored (please let us know if we have missed any) that could be suitable for magazine publishers:

• Umbraco Heartcore
• Episerver
• Contentful
• Adobe Experience Manager
• Sanity
• Squidex

Use skilled programmers

Whether a Headless content strategy is embarked on or not, a publisher should always employ a very skilled developer to launch a new website. Regardless of which technology that is used. While it is indeed quite easy for a non-programmer to launch a WordPress website and try out a few themes and plugins, this is a certain road to bad performance due to the residual garbage files and url errors that are created by WordPress if you're not careful.

A CMS that is more complex than WordPress is a bit "safer" in that sense as it is not reasonably possible for a non-programmer to launch a website without the help from a programmer. You're protected from yourself so to speak :-)