"Let's go headless WordPress." We hear this more and more from clients who read an article, watched a conference talk or got a proposal from another agency. Does it actually work? The honest answer is: it depends. And in most of the cases we see, it is not the best fit.
What headless means
WordPress is born as a monolith: the backend manages content and the PHP theme renders HTML. Headless splits the two: WordPress stays as the CMS and exposes content via REST API or GraphQL (with plugins like WPGraphQL), while the frontend is a separate app, typically Next.js, Astro or Nuxt.
When it makes sense
- Content consumed across channels: web, mobile app, kiosks, in-store displays. A single source of truth feeding many touchpoints.
- Performance and Core Web Vitals critical: a static frontend built with Next.js or Astro is almost always faster than a PHP theme with ten plugins loaded.
- Separate frontend team: if your designers live in React and refuse to touch PHP, headless removes friction.
- Heavy interactive customisation: product configurators, calculators, members-only areas with serious logic.
When it is overkill
- Brochure sites with ten pages, a blog and a few forms. Headless adds complexity without a return.
- The client wants full backend control with SEO, forms, e-commerce plugins: those plugins often assume they live inside a PHP theme and behave poorly when exposed via API.
- Tight maintenance budget: two systems mean two deploys, two monitors, two failure points.
The hidden costs
The first one is preview. In classic WordPress you preview by clicking a button. Headless requires an ad-hoc pipeline with tokens, protected routes and revalidation. The second is versioning: frontend and backend evolve independently, and a breaking change in the CMS can break pages silently until an editor publishes. The third is SEO: meta tags, sitemaps, redirects — all plugin-driven in classic land — must be reimplemented.
Our take
For most Italian business websites, well-built monolithic WordPress remains the cheapest and most robust option. We propose headless only when at least two of these three factors are present: significant traffic (above 100k pageviews/month), content distributed across multiple channels, or an in-house frontend team. Otherwise the overhead does not pay back.