Most of us working in digital are well-acquainted with WordPress. Until about four years ago, it would have been our preferred CMS and over more than a decade of being WordPress experts, we had stretched its capabilities into powering all sorts of custom digital experiences.

There's no doubt that it has been one of the most popular content management systems (CMS). So you may be forgiven for considering it as a headless CMS - a separation of the front-end presentation layer from the back-end content repository.

On paper, it may seem like a viable option too. It manages content and it has an API to access it from an external codebase. It almost feels like some form of digital treason to say this, but let's delve into why this could be a disastrous move for your business.

For a standalone CMS to be headless, it must possess a robust API. While WordPress does offer a REST API, it presents limitations that become apparent in a headless context.

WordPress's API responses can become increasingly complex as custom post types and custom fields get added, leading to large, unwieldy objects. Content filtering options are limited, and pagination can also be troublesome; both of which will seriously hinder a developer's ability to effectively retrieve content.

The WordPress REST API was conceived with fixed endpoints, meaning that targeting specific content or a leaner response requires additional development time to adapt an existing or create new, custom endpoints.

Conversely, the cloud-native headless CMSs tend to offer a GraphQL API out of the box - providing an interface for an external codebase to make very narrow or very broad requests for content from a single, flexible API endpoint.

Security is huge concern when using WordPress as a headless CMS. While WordPress itself has made improvements to its security over the years, it remains the target of many attacks. A prime example being the Panama Papers scandal that resulted in considerable legal and financial fallout (the result of a vulnerability in a third-party, carousel WordPress plugin).

The WordPress REST API itself uses cookie-based authentication which might work for plugins and themes but simply isn’t robust enough for external requests. When using WordPress as a headless CMS, additional security measures (like JWT or OAuth methods) need to be put in place to protect the exposed API endpoints. This adds to the complexity, time and cost.

And of course, you're still left with infrastructure and a never-ending stream of security patches for server-side languages, packages and frameworks; not to mention the steady stream of WordPress core and third-party plugin updates ...and you've checked deep in the code for what each of those plugins is actually doing to codebase and your customer's data, right?!

The biggest struggles for any monolithic CMS, especially WordPress, have tended to come from working with the multi-site, multi-market, multilingual or multi-channel set up (or a combination of those). Yes, there are plugins and well-documented methods to help ease the pain, but WordPress's core structure is founded in it being a single-purpose, blogging platform.

The modern, cloud-native CMSs have addressed these notoriously challenging areas in a variety of simple and intuitive ways; they’ve had the benefit of learning from the struggles of each of the CMS platforms for the last two decades. The avoidance of complexity and the huge productivity gains from the modern take to solve these issues for both the editorial and technical stakeholders will knock your socks off!

Fortunately, there are robust alternatives to WordPress for a headless CMS setup. The likes of Storyblok, Contentful, ContentStack and Strapi (to name just a few), are significantly more powerful and productive alternatives to a headless WordPress set up.

Even if you ignored the cost, performance, flexibility, time, and scalability gains to be made with a ‘proper’ headless CMS as a result of the JAMStack web architecture, WordPress would still come up short on a direct comparison of the pure content management capabilities alone.