The case against WordPress usually focuses on the frontend: the theme system, the template hierarchy, the PHP mixing with HTML. Those criticisms are fair.
They are also irrelevant when WordPress is used purely as a content backend. The REST API and WPGraphQL let you treat WordPress as a database and editorial interface, and serve the frontend from Next.js or any other framework.
Why WordPress wins as an editorial tool
The Gutenberg editor, block patterns, and custom post types give non-technical editors a content management experience that Contentful, Sanity, and Payload have not matched for general-purpose page building.
More importantly, WordPress is the tool that millions of content editors already know. Choosing it as the CMS for a project means zero training cost for editorial teams who have used it before.
The WPGraphQL approach
WPGraphQL exposes WordPress's content model as a typed GraphQL API. Custom fields registered via ACF or custom post types automatically appear in the schema. Queries are co-located with the components that need data.
The developer experience is closer to Contentful or Sanity than to traditional WordPress development. The client application does not know or care that it is talking to WordPress.
What headless WordPress solves
- Editorial teams stay on a familiar interface. No migration cost, no training investment.
- The frontend is fully decoupled. React, Vue, Svelte — any framework works.
- Performance is under your control. Static generation, incremental regeneration, edge caching all become options.
- Security surface is reduced. The WordPress admin is not publicly accessible on the same domain as the frontend.
The real tradeoffs
The WordPress plugin ecosystem is built for traditional WordPress. Plugins that affect the frontend — page builders, sliders, popup tools — do nothing in a headless setup. You lose that ecosystem.
Hosting requires two services: the WordPress backend and the frontend application. The operational simplicity of single-server WordPress disappears.
For projects where the editorial team is the primary constraint and the frontend needs to be a modern React application, headless WordPress is a pragmatic choice. For everything else, a purpose-built headless CMS is probably cleaner.