What is Headless WordPress?
Headless WordPress is an architecture in which WordPress functions only as a backend (CMS) — storing content and exposing it via REST API or GraphQL — while the frontend is built in a separate technology, most commonly Next.js or Gatsby. "Headless" means precisely this: cutting the presentation layer away from the content management layer. The result: WordPress's convenient admin panels combined with the performance and flexibility of a modern frontend.
Traditional WordPress vs. Headless — how it works differently
In traditional WordPress the entire stack is monolithic: WordPress generates HTML server-side via PHP, the browser renders it. Every page request triggers a database query, HTML generation in PHP, and transmission to the client. Plugins, themes and business logic all live together in a single installation.
In a headless architecture, WordPress does only one thing: manages content. Articles, pages, products — everything is accessible via API as JSON. The frontend (e.g. Next.js) fetches this data and renders pages — either statically at build time (SSG), dynamically on request (SSR), or a combination of both. The result: pages load from a CDN as static HTML files, rather than being generated by PHP on every visit.
What Headless WordPress delivers in practice — measured data
| Parameter | Traditional WP | Headless WP + Next.js |
|---|---|---|
| PageSpeed mobile (LCP) | 45–65 pts | 90–99 pts |
| Time to First Byte (TTFB) | 300–800ms | 20–80ms (CDN) |
| Frontend security | Exposed to WP attack surface | Frontend has no access to WP |
| Design flexibility | Limited by themes | Full — code = design |
| Frontend hosting cost | VPS/shared hosting | Vercel/Netlify free or cheap |
| Implementation difficulty | Low–medium | High (requires Next.js developer) |
When Headless WordPress makes sense — and when it is overengineering
Headless makes sense when: performance is business-critical (e-commerce, media, high-traffic portals), you need full frontend control without the compromises imposed by WordPress themes, you are building a web application that needs both a CMS and dynamic features (calculators, dashboards, membership areas), or when the same content needs to be displayed on multiple platforms simultaneously (website, mobile app, kiosk).
Headless is overengineering when: you have a simple business site with a few subpages, your budget does not allow for maintaining two separate systems, nobody in the company has JavaScript skills to manage the frontend, or when the priority is fast deployment by any WordPress developer in the future. In these cases, a well-chosen WordPress theme + technical optimisation delivers 90% of the headless benefits without 10× the maintenance cost.
GraphQL vs. REST API — what to choose with Headless WordPress
WordPress exposes a REST API by default — ready-made endpoints for posts, pages, categories and users. It is straightforward to configure and well documented. The downside is over-fetching: the /wp/v2/posts endpoint returns dozens of fields, of which Next.js might use five.
WPGraphQL is a plugin that adds a GraphQL endpoint to WordPress. Instead of fetching a full post object, you query exactly the fields you need. On projects with a large number of queries (e.g. category pages listing 50+ articles), GraphQL can shorten Next.js build time by 30–50%. My headless projects have used WPGraphQL since 2023 as the standard.
How much does a Headless WordPress site cost?
A Headless WordPress + Next.js site costs more than traditional WordPress due to the architectural complexity. Indicative ranges: a simple business site (up to 10 subpages, no complex features) — €1,900–€3,500; a site with a blog, integrations and custom design — €3,500–€7,000; a web application with interactive features (membership areas, calculators, e-commerce) — €7,000–€18,500.
On top of that come hosting costs: the WordPress backend needs a PHP server (€12–€47/month), the Next.js frontend can be hosted on Vercel (€0–€24/month at normal traffic levels). Total operational costs are comparable to traditional WordPress, but you are building on a foundation that scales far better as traffic grows.
What does editing content look like in Headless WordPress?
This is the question I hear most from concerned clients: "will it be harder to edit than a normal WordPress?". The answer: no, provided the frontend correctly handles preview. The Gutenberg editor in WordPress works exactly the same regardless of whether you have a headless or traditional frontend. You write content in blocks, use categories and tags, add images to the media library — all unchanged.
The only difference is the live preview: traditional WordPress shows the page in its own theme, while headless requires configuring Preview Mode in Next.js. This is a one-off technical configuration, after which editors have a working article preview before publication. Headless WordPress sites combine editorial comfort with the performance that traditional PHP simply cannot achieve.
