Headless WordPress and REST API — What It Is, When It Makes Sense, and How It Works

Published: March 20, 2026 · Author: Marcin Szewczyk-Wilgan

WordPress traditionally handles everything: storing content, processing logic, and generating HTML displayed in the browser. In headless architecture, these roles are separated — WordPress serves as the backend (content management CMS), while the frontend is built separately in JavaScript technology (React, Next.js, Vue, Nuxt, Astro). Communication between them occurs via REST API or GraphQL. This approach is gaining popularity in projects requiring extreme performance, delivering content to multiple platforms, or full control over the user interface. But it is not for everyone — and should not be. In this article, we explain what headless WordPress is, how REST API works, when headless architecture makes sense, and when it is unnecessary complexity.

How Headless WordPress Works

In traditional WordPress, a user visits a page → WordPress executes PHP → generates HTML → sends it to the browser. In headless architecture, this chain is broken:

WordPress as backendWordPress works normally — with admin panel, Gutenberg editor, plugins, users. Editors create and manage content just as in a traditional installation. The difference: WordPress does not generate the frontend — it does not display the page to the end user.
REST API / GraphQLWordPress exposes content via REST API (/wp-json/wp/v2/) or WPGraphQL (/graphql). The frontend sends HTTP requests and receives data in JSON format. REST API is built into WordPress core. WPGraphQL requires a plugin but is faster for complex queries (one request instead of several).
JavaScript frontendA separate application built in React (Next.js), Vue (Nuxt), Astro, Gatsby, or another technology. It fetches data from the WordPress API and renders the user interface. Can be hosted on a CDN (Vercel, Netlify, Cloudflare Pages) — delivering extremely fast loading.
Two servicesHeadless WordPress means two separate services: backend (WordPress on a PHP server) and frontend (JS app on CDN/separate server). Two services to maintain, monitor, and update. This is a fundamental change in architecture — not just in frontend technology.

When Headless WordPress Makes Sense

Headless is not an upgrade — it is a different architecture. It makes sense in specific scenarios, not as a default choice:

Performance

Extremely fast frontend

Statically generated pages (SSG) served from CDN edge achieve TTFB below 50 ms — worldwide. Ideal for high-traffic content sites where every millisecond matters for SEO and conversion.

Multi-platform

Content for multiple platforms

The same content served to website, mobile app, kiosk, digital signage. WordPress as a single source of truth, API as a universal interface. If you need content on more than one platform — headless eliminates duplication.

UI control

Full control over the interface

Complex, interactive interfaces that are impossible or impractical to build with PHP templates. Animations, real-time data, SPA experience. When the frontend must do more than display content — headless gives the team full freedom.

Team

React/Vue frontend team

If the development team works in React or Vue and does not know PHP — headless lets them use their primary technology. WordPress handles content management, the JS team handles the interface.

Limitations and Disadvantages of Headless WordPress

Headless is not free — you gain performance and flexibility but lose the WordPress ecosystem and simplicity:

Loss of plugin ecosystemMost WordPress plugins work with the traditional frontend (PHP). Contact forms, SEO (Yoast, RankMath), page builders, popups, sliders — do not work in headless. Every feature must be recreated on the JavaScript frontend. This significantly increases development cost.
No editor previewThe Gutenberg editor shows content preview in the context of the WordPress theme. In headless — what the editor sees in the panel is not what the user sees on the front. Preview requires additional configuration (preview mode in Next.js/Nuxt).
Higher costsTwo services to maintain, frontend hosting + WordPress hosting, a team knowing both WordPress and a JavaScript framework. Development and maintenance costs can be 2–3x higher than traditional WordPress. For most business sites and blogs — an unjustified expense.
WooCommerceHeadless WooCommerce is possible (WooCommerce has a REST API) but extremely complex. Cart, checkout, customer account, product variations, coupons, shipping — everything must be built from scratch on the frontend. Ready solutions (e.g. headless WooCommerce starters) exist but are young and limited.

REST API vs WPGraphQL

Two ways to fetch data from WordPress in headless architecture:

REST APIBuilt into WordPress core (since 4.7). Endpoints: /wp-json/wp/v2/posts, /wp-json/wp/v2/pages, etc. Separate HTTP request for each data type. Simple, well-documented, no additional plugins needed. Limitation: over-fetching (retrieves more data than needed) and under-fetching (requires multiple requests).
WPGraphQLA plugin adding a GraphQL endpoint. The frontend defines exactly what data it needs — in a single request. Eliminates over-fetching and under-fetching. Faster for complex queries (post + categories + media + author in one request). Requires an additional plugin and GraphQL knowledge.

Summary

Headless WordPress is a powerful architecture — but not a universal one. It makes sense for high-traffic content sites, multi-platform content delivery, complex interactive interfaces, and teams working in React/Vue. For most business sites, blogs, and WooCommerce stores — traditional WordPress with a well-optimized theme is simpler, cheaper, and gives access to the full plugin ecosystem. Headless is a tool, not an upgrade — choose it when you have a specific reason, not because it sounds modern.

At WebOptimo, we build both traditional and headless WordPress solutions. We help clients choose the right architecture for their needs — and implement it from the backend CMS to the production frontend. Contact us or check our custom WordPress solutions offer.

Frequently Asked Questions About Headless WordPress

An architecture where WordPress serves as the backend (CMS) and the frontend is built separately in React, Next.js, Vue, or another technology. Communication via REST API or WPGraphQL.

A built-in programmatic interface (/wp-json/wp/v2/) for fetching and modifying content in JSON format. Part of WordPress core since version 4.7.

Extremely fast frontend (SSG + CDN), multi-platform content delivery, full UI control, frontend team working in React/Vue.

Loss of plugin ecosystem, no editor preview, 2–3x higher development costs, infrastructure complexity, loss of PHP-based WooCommerce features.

A plugin adding a GraphQL endpoint. Frontend defines exact data needs in one request — faster than REST API for complex queries. Requires an additional plugin.

Let’s Talk About Custom WordPress Solutions

We will help you choose the right architecture and build the solution. No commitments — a concrete proposal after a conversation.

Phone

+48 608 271 665

Mon–Fri, 8:00–16:00 CET

E-mail

contact@weboptimo.pl

We respond within 24h

Company

WebOptimo

VAT ID: PL6391758393