Maybe WordPress Should Stop Being the Default for Modern Content Systems

Pete Beeda — Fri, 03 Apr 2026 06:07:15 +0000

WordPress is still incredible software.

I also think we recommend it by reflex in a lot of situations where it is no longer the cleanest fit.

That is not the same as saying WordPress is bad. It clearly is not. It powers a huge part of the web, it solved publishing for millions of people, and it still wins plenty of perfectly valid projects.

But once your content has to outlive a single theme, a single frontend, or even a single site, I think "just use WordPress" often survives longer than the architecture case for it.

That tension is a big part of why I built HTMLess, an open source headless CMS.

This post is intentionally opinionated because I think this is a debate worth having:

WordPress is excellent at powering WordPress sites.

I just do not think that automatically makes it the best foundation for API-first, multi-frontend, multi-site content architecture.

WordPress is still a good choice for theme-centric sites and teams already invested in its ecosystem.
I think "just use WordPress" becomes shaky advice once content needs to be portable, API-first, preview-safe, and shared across multiple frontends or spaces.
In that world, plugin stacks often become accidental architecture.
I wanted a CMS where schema validation, preview boundaries, delivery caching, scoped tokens, and multi-site isolation were core design decisions, not retrofits.
I borrowed a lot from WordPress. I just stopped wanting my content model to inherit WordPress's deployment and rendering assumptions.

My take: WordPress solves website problems better than it solves content platform problems

That difference matters.

If I need:

a marketing site
a blog
a content team that already knows WordPress
theme-driven rendering
a fast path to launch

then WordPress is still a very rational choice.

But the problem changes when the same content needs to feed:

a Next.js frontend
a docs site
landing pages
internal tools
mobile surfaces
multiple client sites from one backend

At that point I am not really building "a website" anymore.

I am building a content platform.

And I think too many teams still reach for WordPress in that scenario because it is familiar, not because it is clearly the best fit.

Plugin stacks are not architecture

This is the point where I started losing patience.

WordPress can absolutely be stretched into modern headless use cases, especially with the REST API, custom post types, custom fields, the Block Editor, and a lot of plugin glue.

But "WordPress can do it" and "WordPress is the best foundation for it" are not the same statement.

In practice, the headless WordPress stack often becomes:

one plugin for structured fields
one for preview behavior
one for custom API responses
one for permissions
one for cache behavior
one for SEO or schema output
one more custom layer for webhooks or build triggers

At some point the answer stops being "we chose WordPress" and becomes "we assembled a fragile treaty between plugins."

That sounds harsher than I mean it to, but I think a lot of teams know exactly what I am talking about.

If content cannot survive a frontend rewrite, it probably was never structured enough

This is probably the most opinionated line in the whole article, but I mostly stand by it.

A lot of CMS content is only "structured" until you try to move it somewhere else.

Then you discover:

layout assumptions inside the content body
shortcode dependencies
theme-specific HTML
editor output that makes sense only in one renderer

That is why I wanted schema-first content types and block-based rich content as first-class concepts.

I wanted content to behave more like data than page markup.

Not because JSON is beautiful.

Because frontend rewrites are normal now. Reusing content across products is normal now. Shipping to more than one surface is normal now.

If the content layer breaks every time the frontend changes, the CMS is not really reducing complexity. It is just postponing it.

Preview should not be a side quest

I underestimated how important this was until I watched editorial workflows break around it.

Editors do not care whether a preview architecture is elegant. They care whether it is trustworthy.

They want:

the real frontend
the real draft
no public leaks
no weird cache bugs
no mystery rules nobody remembers six months later

That is why I stopped wanting preview to be "some custom route plus a token plus a plugin plus hope."

I wanted preview to be its own boundary.

That is one of the reasons HTMLess separates:

content management
published delivery
draft preview

Those surfaces should not behave the same way because they are solving different problems.

Public delivery wants cacheability.
Editorial management wants private mutation.
Preview wants temporary, tightly scoped draft access.

I think blending those concerns too casually is one of the reasons a lot of CMS setups feel fine at launch and frustrating later.

Headless makes security and correctness more important, not less

Another thing that pushed me away from the default WordPress path: once the CMS becomes an API backend, the boring details become the product.

I wanted the core system to assume things like:

scoped API tokens
short-lived preview tokens
object-level authorization
property-level filtering
webhook signing
retry behavior
optimistic concurrency with ETag and If-Match

None of that is flashy.

All of it matters.

Headless CMS discussions often focus on DX and forget that API-first content systems fail in very unglamorous ways:

drafts leak
tokens get over-scoped
builds publish stale content
editors overwrite each other
multi-site boundaries get fuzzy

That is the stuff I wanted designed in, not layered on after the first incident or awkward postmortem.

Multi-site should be a core boundary, not a heroic retrofit

This was another big reason I built my own CMS.

I work in an environment where one site is almost never the end state.

Teams accumulate:

brands
campaigns
docs portals
client spaces
staging environments
localized variants

So I wanted one install with isolated spaces.

Yes, WordPress Multisite exists. I know.

But that still was not quite the shape I wanted.

I was not trying to run many WordPress sites. I was trying to run one API-first content platform that could serve many projects while keeping boundaries around content, assets, tokens, schemas, and webhooks.

Retrofitting that later felt like the kind of decision teams regret only after the migration budget shows up.

Self-hosting should be intentional or not offered at all

This one is less provocative, but I feel strongly about it.

If a product says it supports self-hosting, it should actually support self-hosting.

Not in a README-fiction sense. In a "local, staging, and production all feel like the same product" sense.

That is why I wanted Docker-first workflows and an open source core.

I do not think everybody should self-host.

I do think teams that care about owning their content infrastructure should not be punished for it.

The irony: WordPress still taught me most of the right lessons

This is the part that makes the whole thing less tribal than it sounds.

I did not build HTMLess because I rejected WordPress.

I built it because WordPress got a lot of important things right:

drafts
revisions
media
roles
block-style editing
extensibility

WordPress taught the web that content tooling should work for editors, not just developers.

I still believe that.

What I rejected was not the editorial model.

What I rejected was the assumption that the best content authoring experience has to stay tightly coupled to one rendering architecture.

Where I still think WordPress wins

To keep this honest: there are still plenty of cases where I would choose WordPress over my own CMS.

I would pick WordPress if:

the site is theme-centric
the team already knows WordPress deeply
plugin leverage is more valuable than architectural purity
content portability is nice to have, not mission-critical
the fastest path to launch matters more than long-term content design

That is why I do not think "go headless" is automatically smart.

A lot of headless projects are over-engineered.

But I also think "just use WordPress" gets repeated way too casually in situations where the real requirements have already moved on.

Why I built HTMLess

I built a headless CMS because I wanted content to be:

structured instead of page-shaped
portable instead of theme-bound
previewable without draft leakage
cacheable without mixing editorial and public concerns
secure by default as an API product
self-hostable without ceremony
usable across multiple sites from one system

WordPress influenced a lot of that thinking.

It just stopped being the final architecture I wanted to live with.

If you are curious about the project that came out of this line of thinking:

The actual question

If you have used WordPress as a headless or API-first CMS, where did it hold up well for you, and where did it start fighting you?

And if you think I am wrong, I would genuinely like to hear that too:

Should WordPress still be the default recommendation for modern content systems, or are we using it by inertia more often than we want to admit?

Forem: Pete Beeda