Headless WordPress Is the Last Cope. Stop It.

There is a medieval practice called transi art: sculptures of rotting corpses dressed in the finery of the living. The idea was to remind the wealthy that death comes for everyone, no matter how expensive the doublet. Headless WordPress is the transi sculpture of web development. You have taken a body that lost its head years ago — the bloated, plugin-riddled, PHP-churning core — and you have draped it in a Next.js overcoat, called it 'modern architecture,' and pretended the smell was just DevOps.

“You did not save WordPress. You performed taxidermy on a corpse and entered it in a fashion show.”

The headless crowd loves the metaphor of decoupling. 'We separated concerns!' they cry, as if concern-separation is a moral victory and not a desperate attempt to quarantine a backend so infectious it should be handled with hazmat suits. The frontend is React. The frontend is Svelte. The frontend is whatever framework was trending on Hacker News the week the agency made its tech decision. But the backend? The backend is still WordPress. The same database schema designed when Britney Spears was a fresh face. The same plugin update roulette. The same XML-RPC attack surface. You did not decouple. You put a designer suit on a leper and called it couture.

The corpse has no head. Stop dressing it.

Let us be anatomically precise about what headless WordPress actually is. The 'head' — the presentation layer — has been removed. In its place, you have grafted a JavaScript framework that talks to the body via REST API or GraphQL. The body, meanwhile, continues to pump blood through arteries clogged with twenty-seven plugins, three page-builder shortcode engines, and a WooCommerce installation so old it remembers when Trump was just a reality TV host.

The problem is not the new head. The new head is fine. React is fine. Svelte is fine. The problem is that the body is dead, and no amount of tailoring can fix rigor mortis. You are not building a modern stack. You are building a haunted house where the ghosts are PHP fatal errors and the cobwebs are nested ACF fields.

• →The REST API is not a nervous system. It is a megaphone shouting database rows through a plugin filter chain that adds 400ms to every request.
• →GraphQL is not intelligence. It is a query language asking stupid questions of a stupid schema, then caching the answers because the backend cannot answer them twice without timing out.
• →The 'headless' frontend is not fast because it is headless. It is fast because you finally stopped rendering twenty nested divs in Elementor and started rendering ten nested components in React. The speed gain is from leaving the page builder, not from keeping WordPress.

The backend is the rot. The clothes do not matter.

Every headless WordPress project I have ever reviewed follows the same pattern. Phase one: excitement. 'We are going to use Gutenberg as a CMS and Next.js for the frontend! It is going to be blazing fast!' Phase two: reality. The REST API returns malformed JSON because a plugin is injecting HTML into the_content. Phase three: workaround. 'We will just write a custom endpoint.' Phase four: defeat. 'Actually, we are going to use WPGraphQL and a bunch of custom post types and maybe a few ACF field groups and —' Stop. You have already built a Rube Goldberg machine. You just call it 'composable architecture' in the pitch deck.

The backend is where the rot lives. It is the MySQL database that has not been optimised since 2019. It is the plugin that auto-updated last Tuesday and broke your custom endpoint. It is the security patch for a vulnerability in a contact-form plugin that you did not know you had because the agency that built the site in 2017 installed it and never documented it. You cannot dress that up. You can only smell it from further away.

“A headless CMS is only as clean as the body underneath. And WordPress has not been clean since it discovered commercial plugins.”

You did not decouple. You duct-taped.

The architecture diagrams look beautiful. A clean separation between 'content' and 'presentation.' The editor manages content in WordPress. The frontend consumes it via API. It is elegant on a whiteboard. In production, it is a horror film.

Here is what really happens. Your client logs into wp-admin to edit a page. They use a page builder because you installed one so they would not have to learn Gutenberg blocks. The page builder saves to the WordPress database in a proprietary shortcode format. Your custom REST endpoint tries to parse that shortcode into clean JSON. It fails because the page builder updated its rendering engine in version 4.2 and changed the shortcode signature. Now your frontend displays raw shortcode text where the hero section should be. Your client calls you. You tell them not to update plugins without asking. They tell you they did not update anything. It was an auto-update. You spend four hours debugging a conflict between a visual editor you swore you were not using and a frontend framework you swore was decoupled from it.

That is not decoupling. That is a marriage counsellor pretending a divorce is amicable while both parties are still sharing a bank account and screaming at each other over the dinner table. The frontend and backend are not separate concerns. They are estranged spouses forced to live together for tax reasons.

• →Authentication: you are still using WordPress cookies or JWT plugins because nobody wants to rewrite user management.
• →Preview mode: you are still rendering draft content through WordPress because your editors refuse to learn Git.
• →Search: you are still using a WordPress plugin for search because ElasticSearch is another bill you do not want to explain to finance.
• →Forms: you are still forwarding form submissions to WordPress because your marketing team loves Gravity Forms.

The React funeral shroud

There is a special cruelty in watching React — a genuinely good framework — being used as a funeral shroud for WordPress. React did not deserve this. React was built for interactive applications, for stateful components, for interfaces that need to be fast and responsive. It was not built to render static blog posts fetched from a PHP endpoint that takes two seconds to warm up because the shared hosting plan has not been upgraded since the Obama administration.

And yet, here we are. Static site generation powered by a dynamic CMS that requires a database connection. Server-side rendering of content that changes once a month. Hydration of a page that has no interactive elements except a mobile menu. You are using a Formula 1 car to deliver newspapers. It is fast, yes, but the newspapers are still yesterday's news and the delivery route is still through a swamp.

“Using React to render WordPress content is like hiring a Michelin chef to microwave a frozen dinner. The plating is impeccable. The meal is still miserable.”

What you are actually maintaining

Let us talk about maintenance, because that is where the corpse metaphor becomes truly grotesque. A headless WordPress site does not reduce maintenance. It doubles it. You are now maintaining two runtimes: the WordPress backend with its plugin updates, security patches, PHP version migrations, and database optimisations; and the frontend with its Node version dependencies, build pipeline breakages, framework deprecations, and deployment environment drift.

You did not simplify. You multiplied. Every plugin update on the backend is a potential API contract change. Every framework update on the frontend is a potential breaking change for your data fetching logic. You have taken a single-point-of-failure architecture and turned it into a two-points-of-failure architecture, then added a caching layer in between so you can pretend the failures are network issues.

And the hosting bill? Oh, the hosting bill. You need a server for WordPress. You need a server for the frontend build. You need a CDN for the static assets. You need a caching layer because the API is too slow without it. You need a search service because the WordPress search is unusable at scale. You need an image optimisation service because WordPress uploads full-resolution JPEGs by default and your frontend is trying to serve them to mobile users on 3G. The infrastructure cost of a 'simple' headless brochure site now rivals a mid-tier e-commerce platform. But at least it is modern.

• →Two build pipelines. Twice the CI/CD headaches.
• →Two security surfaces. Twice the penetration-testing invoices.
• →Two teams arguing about whose fault the 500 error is.
• →One client wondering why their brochure site costs more to host than their competitor's Shopify store.

The honest alternative: let the dead bury the dead

If you need a content API, use a content API. Sanity, Contentful, Strapi, directus, even a Git-based CMS like Decap — all of them were built for this decade. They were designed from the ground up to serve structured content over APIs to modern frontends. They do not carry twenty years of blogging-platform baggage. They do not require you to disable XML-RPC on launch day. They do not secretly install Akismet while you are not looking.

If you need a static site, build a static site. Astro, Eleventy, Next.js with static exports, SvelteKit — all of them can pull from a modern CMS, build at deploy time, and serve HTML without a database connection. The resulting site is faster, cheaper, and maintainable by a single developer instead of a DevOps team pretending WordPress containers are a good use of Kubernetes.

“The only thing WordPress brings to a headless architecture is the WordPress. And that is precisely the problem.”

But the real reason agencies cling to headless WordPress is not technical. It is emotional. They have spent a decade learning the platform. They have templates, plugins, workflows, and client training materials all built around wp-admin. Moving away feels like starting over. It feels like admitting that the skillset they sold as expertise was actually just familiarity with a decaying ecosystem.

It is. And admitting it is the first step toward building something that will not need a defibrillator every third Tuesday.

Final rites

Headless WordPress is not the future. It is the last stage of grief before acceptance. It is the bargaining phase where you tell yourself that if you just separate the frontend, if you just add a caching layer, if you just write one more custom endpoint, the platform will be viable again. It will not. The corpse is cold. The suit is bespoke. The audience is clapping out of politeness.

Stop dressing the dead. Bury it. Build something that breathes on its own.