The ol' Headless vs. WP Debate. A '25 refresher.

Once upon a time (like, maybe a little less than a decade ago), the narrative was clear: headless CMS platforms like us were the slick, modern alternative to the "bloated, outdated web builder monolith" like WordPress. WordPress was for PHP developers and templated blogs; headless was for people who wanted freedom, flexibility, and performance.

We loved milking that narrative on how headless was the future for EVERYONE.

But today? Things aren’t so black and white.

And let's be honest, the WordPresses aren't going anywhere.

Many if not all classical CMS have started to blur the lines on capabilities between them and the headless ones, with better APIs, stronger feature sets, and multichannel capabilities. So let's do a little status update on the landscape, by comparing WP to DatoCMS and see where the differences lie.

Right off the bat, credit where credit's due. WordPress now has its own headless option with WPGraphQL and REST APIs and Faust.js. There are decent solutions for content previews, scheduling, and localization. The plugin ecosystem continues to thrive. On the other side, headless platforms like us have spent the last few years seriously leveling up our editorial experience, so much so that the old “headless is painful for editors” critique just doesn’t hold up anymore.

So the question in 2025 isn’t “Is WordPress dead?”, it’s: what do you actually need from your CMS, and which tool handles that best?

And just to keep things clear: when we say WordPress here, we mostly mean classic WP (the .org PHP app with themes, templates, and plugins). Where Headless WP is relevant, we’ll call it out specifically.

Let’s break it down. We’ll keep this simple. And we'll sprinkle some 🧠 moments from chats we've had with our customers who faced the same problem before.

TLDR:

Content Modeling: Structured vs. “Hope This Field Works”

In WordPress, content modeling means either using the default "Posts" and "Pages" setup or extending it with popular plugins like Custom Post Types and Advanced Custom Fields (ACF). Want to make a “Case Study” type? You’re either coding that yourself or relying on ACF or a plugin that stores your data as serialized blobs inside the db. Relationships between entries? Not great. Data types? Loose at best.

Over here, content models are first-class citizens. Every model is explicit. Every field is typed. Relations are real relations, not just text references. Need a list of related Products on your Case Study page? That’s an actual link to the Product model, not some stringified slug in a meta field.

What this means in practice:

• Clean GraphQL schema auto-generated from your models

• No guessing which field contains what data

• Easy to enforce content integrity across models

If you’re using Headless WP, you’re still stuck building your own schema via WPGraphQL. Better than nothing, but I still feel like it's forcing the tool to do something it wasn’t built for.

Localization: Built-In vs. Plugins

Multi-language content in WordPress almost always means installing WPML, Polylang, or some other plugin. These work. Until they don’t. Performance drops. Translation status becomes messy. And content duplication happens a lot more than you’d expect.

We handle localization at the model and field level. Any field, any model, any locale. You decide which fields are localizable. You get a clear UI showing where translations are missing. No duplication. No confusion. Want to take it a step further and automate translations with AI? There's a plugin for that. But for the very essence of localization, that's built in.

For example, if you're tweaking your global SEO settings, you can choose to localize only the title and description fields. Working on an eCommerce site and have a Product model? Localize the descriptions but keep shared product IDs and images. Simple

Even on the Headless side in WP, localization is still a plugin problem. WPGraphQL for WPML exists, but it’s yet another layer of complexity.

Previews

Previewing unpublished content in WordPress is fine as long as you’re in the classical WP world. In fact, it's great! It's built in by default, something even we and most Headless CMS don't have without a plugin (since technically we're not just website builders). But in the headless space, previews get messy fast. You’re usually wiring up something with WPGraphQL and Faust.js or relying on iframe-based previews via plugins.

We give you flexible, API-based preview setups with the Web Preview plugin. You configure your preview URLs per environment. Editors click “Preview” and see exactly what the content will look like on the frontend with custom breakpoints for different devices. Doesn’t matter if it’s a React site, a mobile app, or something else like a TV app.

Added bonus? Previews are tied to each of your models, so you’re not just previewing a blog post template. You can preview complex pages with modular content and dynamic relationships, no hacks needed.

APIs and Developer Experience

One of the biggest arguments from the dev side in favor of Headless CMS have always been framework flexibility. WP boxed devs in to working with PHP whereas Headless let everyone work with whatever they prefer - Astro, Vue, Next, Svelte, whatever. No restrictions.

So headless CMSs in general are just a lot more flexible in terms of what sort of front end you have. For example, the hoops you have to jump through to make a WordPress site headless are a lot because you must, you have to find somewhere to host your CMS for WordPress.

WordPress started as PHP templates and MySQL queries. The REST API was bolted on later. WPGraphQL? Plugin-based. Schema? You build it manually.

The memes hit hard.

Headless CMS on the other hand are API-first by default. Our API is GraphQL-first, with the schema auto-generated directly from your models. You get introspection. You get predictable queries. You get type safety. Every change in your content model is reflected immediately in your schema.

This is why dev teams who care about DX and reliability tend to prefer the headless option:

• Zero plugin setup for APIs

• CDN-backed API responses

• Image transformations, responsive assets, and SEO metadata via the API

Modular Content and Page Building

Gutenberg is WordPress’s block editor, but it’s really designed to output HTML directly into the frontend. This works if you’re sticking to WordPress themes. In headless setups, Gutenberg blocks get serialized and shipped via the API, but you’re manually parsing HTML in your frontend.

We do modular content differently. Content blocks are structured models themselves. Your frontend gets clean JSON data, not HTML blobs. Editors can mix and match blocks like “Hero Banner,” “FAQ Section,” “Image Gallery,” or whatever your design system uses.

This ensures that you're not parsing HTML in your app and there's no weird coupling between the backend and frontend. It also gives you the full flexibility to change your rendering logic without touching the CMS, or change the layouts of your content without needing editors to get developers to change anything in the repo.

And if you want to use a static front end with WordPress, you then need to manipulate WordPress so that when you publish a post, it will force your front end to rebuild, which WordPress, like the vanilla WordPress, is not built to do, it's not designed to do that. So you have to then reach for plugins or write your own PHP scripts to do that.

Permissions and Workflows

WordPress user roles are basic: Admin, Editor, Author, Contributor. Want anything more fine-grained? You’re reaching for User Role Editor or a similar plugin. Another dependency. Another performance hit.

We offer role-based access down to the field and model level. Want your German marketing team to only edit German content? Easy. Want interns to create drafts but not publish? Done. Need an approval flow for certain content types? Built in.

This isn't possible in classic WP without heavy plugin customization.

Security, Hosting, and Maintenance

One of the biggest things that quietly eats up time (and budget) with WordPress is the ongoing care and feeding required to keep things running smoothly. Security patches. Plugin updates. PHP version upgrades. Theme compatibility checks. Caching setup. Hosting performance tuning. Rinse and repeat.

If you're self-hosting WordPress, this is your responsibility. If you're on a managed host, you're paying them to handle it, but only to a point. Security features like malware scanning, backups, and DDoS protection are often part of the upsell, and not included out of the box.

The one project where I introduced Dato to the client, who is still happy, one of his requests was, he had a different agency that did a similar thing for him, and they convinced him of self-hosting [***]. And it worked quite well for a bit, but it became super slow. And then his request was, "I don't want to self-host anymore. I want headless." That was one of the first things he said to us, because it scales better for him.

Plugins also add risk. Every additional plugin is another thing that needs updating and patching. Vulnerabilities in the plugin ecosystem are one of the most common sources of WordPress hacks. And if your plugin stack isn’t maintained properly, your whole site can break on the next update.

Even in Headless WP, you're still running the full WordPress backend somewhere. That means PHP, MySQL, plugins, and all the maintenance that comes with it. Just because your frontend is React doesn’t mean you’ve escaped the WordPress server stack.

With us and most Headless options? You don’t host the CMS at all.

For smaller clients, I think the main thing is that they don't need to maintain the CMS. It's not there. There's no overhead involved in updating and maintenance and hosting it yourself.

We handle the infrastructure, the scaling, the patching, the security. Our APIs are CDN-backed, so your content is delivered fast and globally without you needing to worry about caching plugins or server configs. You focus on building your frontend. Your editors focus on content.

Basta 🤌

No plugins to patch. No PHP stack to maintain. No theme compatibility issues. No servers to babysit.

And if something goes wrong? You’re not chasing down which of your five caching plugins broke the site. You're just pinging us and we're solving it with you.

What about Page Builders?

For so many users, this is really where WP's UX shines - the classic WYSIWYG approach to EVERYTHING. We can’t really talk about WordPress without talking about page builders like Elementor, Divi, or Beaver. They’re a huge part of why WordPress remains so popular today. They give content teams the power to build out pages visually, drop in widgets, and get stuff live without touching code.

But here’s the tradeoff: the HTML output from these builders is very opinionated, very bloated, and often pretty rough under the hood. You’re at the mercy of whatever markup the builder spits out, which means your frontend stack ends up buried under a pile of auto-generated <div> clutter.

The tool makes decisions for you, something we're personally not fans of.

To be fair, the headless world has its own versions of this. Tools like React Bricks, Builder.io, or Plasmic offer visual page building for headless setups. The key difference? Their output is structured data, not tangled HTML. Your frontend(s) still consume clean JSON and renders it the way you decide, not the way the builder decides.

If visual page building is important to your workflow, that’s fine, but choosing tools that respect structured content (and your frontend’s integrity) is going to save you a lot of headaches down the line.

So. When to go Headless

I guess it all comes down to figuring out if Headless is right for you?

Here’s the simple checklist:

• You have editors and developers who need to work alongside each other without stepping on each other’s toes. If Dev resources are really not on the table, or if you're working with highly specialized WP devs, honestly, we'd suggest sticking to that.

• You want to use modern frameworks like React, Vue, Svelte, Astro, or plain static HTML without CMS constraints.

• You’re running multiple frontends: maybe a website, maybe an app, maybe a kiosk or digital signage, and you want one content source for all of them rather than juggling multiple tools and CMS.

• You care about scaling without stress: global CDNs, no plugin performance issues, no self-hosted CMS stack to babysit, no security patches on your side, etc. etc.

• You want clean separation of concerns between content and presentation so your editors don’t need to touch code, and your developers don’t need to untangle WYSIWYG blobs

Compare that to the headless WordPress experience: you’re still running the full PHP app stack somewhere just to serve your API. You still need to manage plugins. You still need a server or hosting plan for WordPress itself. Even if the frontend is headless, the backend is... still WordPress.

With us, you don’t have to run or host the CMS at all. We handle the infrastructure, scaling, and performance for you. Your developers focus on building great frontends. Your editors focus on creating great content.

Easy.

Where WordPress Still Wins

Ok I've 💩 enough on WP so far, but there's some very credible reasons why they're still powering like 40% of all websites. There are situations where it makes total sense:

• Your site is small and simple: blog, landing page, contact form, done.

• Your team knows WordPress inside out and doesn’t have developers on hand.

• You need fast time-to-market without worrying about APIs or frontends.

• Budget is limited and performance at scale isn’t a concern you want to trouble yourself with yet.

• If you work with a WP-specialized agency it might be a chore and/or too expensive to swap out to a new agency or stack.

• There's certain considerations on data portability. WP offers a clean data export which can be standardized to be imported into DatoCMS, but depending on the Headless CMS you choose, not all have that straightforward approach. This could be quite the expensive rabbit hole to go down accordingly.

If those points sound like you, sticking with WordPress is probably the right call.

But if your content strategy needs more than one language, more than one site, or more than one type of frontend, or if you’re tired of the plugin stack fragility, that’s where we come in.