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
ETagandIf-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?
Top comments (0)