Considering WordPress as a headless CMS? Think again.

You'll struggle to find a more qualified team to talk about WordPress, who are now at the cutting edge of headless CMS solutions. Before you allow familiarity to steer you towards WordPress, read on...

Tim Dodd

Head of Product & Technology

WordPress heritage

All good things must come to an end; even WordPress

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.

Conceived 20 years ago

WordPress isn’t built as a headless CMS

WordPress was designed as a blogging platform and, over the next 20 years, evolved into a full-fledged CMS. It has struggled to perform many of the operations a modern, commercial entity demands of its CMS even before you attempt to go headless with it.

It was not built from the ground up to function as a headless CMS. Retrofitting it into this role requires a lot of wrestling with the default features and core architecture. It almost seems unfair to even attempt to make it work in this way.

Even then, the core performance, security and scalability are simply issues that can't be circumvented.

Structurally inflexible

Limitations in the REST API

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.

Headless inherits the same bottlenecks

Performance issues for WordPress as a headless CMS

The monolithic architecture of WordPress will still introduce significant performance issues, even when used as a headless CMS. The database inefficiencies in WordPress's querying mechanism and the infamous 'WordPress loop' drastically limit the speed of response to any API request which still needs to run through the core of the WordPress application. This is especially true as your content base grows and many hundreds or thousands of Advanced Custom Field values are piled on.

This adds strain to your infrastructure, leading to higher costs and decreased site performance - a costly drawback, both in terms of user experience and server expenses. At the heart of it all is an inefficient MySQL database which doesn't naturally scale horizontally.

The increased costs, complexities and larger attack surface are especially difficult to stomach when you consider this infrastructure (web servers, load balancers, database server), its patching and maintenance are wholly unnecessary when using a cloud-native headless CMS.

No need to take the risk

WordPress security concerns

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?!

Increased maintenance overheads

Diverting resource away from generating real business value

Using WordPress just as a traditional CMS will result in an unnecessary increase in your ongoing maintenance time and costs (commonly quoted as a reason to move away from a monolithic CMS and to a headless architecture).

Given the modifications required to make WordPress work as a headless CMS, and the extra complexities these introduce, along with the ongoing patches and updates, the total cost of ownership quickly escalates. Critically, this is diverting valuable development or engineering resource away from generating business value and focusing it on just keeping your website alive.

Not only that, but you also now need your development resource to be proficient (if not experts) in a much broader skill set (SysOps, DevOps, PHP, WordPress, Javascript frameworks for the front-end, database management, security, performance optimisation, and so on). That blend doesn't fit the profile of the modern engineer who has cut their teeth on using just Javascript/TypeScript throughout the tech stack.

Demands on the CMS have increased

WordPress is weak in the 'multis'

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!

Not winning the editor's pick

Lack of built-in features for a headless CMS

WordPress has sadly fallen behind the times in its delivery of key features which are typically available in a modern, cloud-native, headless CMS.

Real-time editing, content authoring and commenting, content workflows and sign-offs are all missing in WordPress. This often leads to users managing the content process away from the content management system (as bonkers as that sounds) and/or drastically impacts on their productivity.

WordPress simply make it significantly more difficult for stakeholders to manage and preview content before publishing. This has a significant impact on all disciplines in your team's workflow and their productivity; whether they're trying to be responsive to trending topics, support a campaign or actively nudge the dial through conversion rate optimisation initiatives.

Conceived with headless in mind

Thankfully, cloud-native headless CMS solutions exist

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.

Mitigate risk and don't waste your budget

WordPress simply can't compete with cloud-native headless CMS

In conclusion, using WordPress as a headless CMS will fail to deliver the advantages of the JAMStack web architecture, maintains the significant issues and barriers imposed by the rigid monolithic structures, and comes with the additional complexities of trying to make it perform functions it was never designed to undertake.

If you want to mitigate risk, avoid wasting budget and repeating the same project in the near future, look beyond the well-worn slipper that is WordPress. Using it as a headless CMS will not address your pain points and is likely to leave you with a very expensive and inflexible mess on your hands.

Continue reading


Are you ready to make a digital step-change?

We believe that moving too slowly in digital is the biggest risk your business faces. If you are ready to move faster in digital, and are explore website solutions and headless CMS options, we are here to help.

Get In touch