Book now

Headless WordPress in 2026: When Decoupling Is Worth It

by Francis Rozange | Oct 2, 2026 | WordPress

A glowing glass core separated from its shell, linked by thin streams of light

On September 13, 2022, The Verge relaunched its website on a brand-new front end. Its content management system had not changed: the outlet only replaced its in-house tool with WordPress later, underneath a site that was already live. That feat was only possible because display and content management were separate.

That is the promise of headless WordPress: WordPress manages the content, another application displays it. The front end becomes free, while the CMS stays familiar to editorial teams. The promise is appealing, and it comes at a price that demos often leave out.

Even the host WordPress VIP, which sells headless architectures to large media groups, admits it in a 2026 article: without a team able to tune each component, headless WordPress will likely be slower.

This guide takes stock in October 2026: what the word covers, the choice between the REST API and WPGraphQL, the possible front ends, previews, SEO, security, hosting and its cost, then the cases where you are better off staying away.

What “headless” means

The front end, the back end and the API in between

In a classic WordPress site, the same software stores content and builds pages: the theme turns posts into HTML on every visit. In a headless setup, WordPress no longer serves pages. It exposes its content through an API, and a separate application, often written in JavaScript, fetches it to build the site.

Writers keep working in the block editor, managing media and accounts as before. Visitors never see WordPress: they browse the front end, hosted elsewhere, with its own caching and deployment rules.

Headless, decoupled, hybrid

All three words are used, with nuances. Headless means WordPress with no public rendering at all. Decoupled stresses the separation of the two applications. Hybrid describes a site where some sections are still rendered by WordPress and others by a separate application, an approach WordPress VIP promotes to avoid rebuilding everything.

So the choice is not binary. Before comparing WordPress with other platforms, as in our WordPress vs Shopify vs Webflow comparison, ask which part of the site would really benefit from being separated.

REST API or WPGraphQL: choosing your pipe

The REST API, already in core

WordPress has exposed its content as JSON since version 4.7, released in December 2016: posts, pages, comments, terms, users, metadata and settings. The block editor itself relies on this API. No plugin is needed to use it.

One point often surprises people: public content is also public through the API, for any visitor, and the API does not check where requests come from. That is a documented design choice. Drafts and edit-context fields, on the other hand, require an authenticated request.

Astro’s official documentation uses this API for its WordPress guide, and it is often the shortest path for a simple content site.

WPGraphQL, announced as a canonical plugin in October 2024

WPGraphQL adds a GraphQL API to WordPress: the front end asks for exactly the fields it needs, nests relationships in a single query and relies on a typed schema. Created by Jason Bahl in 2016, the plugin was funded first by Gatsby, then by WP Engine from 2021.

On October 7, 2024, Matt Mullenweg announced that WPGraphQL was becoming a canonical WordPress.org plugin, on the day its creator left WP Engine for Automattic, in the middle of the dispute between the two companies. The plugin is still a plugin: it is not part of core, and the REST API remains WordPress’s official API.

In October 2026, WPGraphQL is at version 2.23.1, with more than 30,000 active installs. Since early 2026, the plugin and its main companions, Smart Cache, WPGraphQL for ACF and the IDE, have lived in a single code repository. None of them was yet marked as tested with WordPress 7.1 at the time of writing.

The plugins around it

Several plugins complement WPGraphQL. WPGraphQL for ACF exposes ACF custom fields; a request for compatibility with Secure Custom Fields, the version maintained by WordPress.org, is still open in October 2026. WPGraphQL Smart Cache handles query caching and invalidation. WPGraphQL Content Blocks, from WP Engine, exposes editor blocks as typed data.

For SEO, a community plugin connects Yoast SEO to WPGraphQL. Rank Math offers no native GraphQL support.

How to choose between them

The REST API is enough for a simple content site: posts, pages, categories, a single front end. It needs no plugin and works with the Yoast and Rank Math endpoints.

WPGraphQL pulls ahead when the content model gets complex: many custom fields, relationships between content types, several front ends or apps to feed. Its documentation compares the same list of one hundred posts, 335 KB over REST against 6.4 KB over GraphQL; that is the project’s own argument, and the REST API can also trim its responses with the _fields parameter: compare on your own queries. To benefit from Smart Cache network caching, queries must use GET, and the site must be on a supported host.

The front end: Next.js, Astro and the rest

Next.js and the official example

The Next.js repository includes an official WordPress example. It relies on WPGraphQL and WPGraphQL JWT Authentication for previews, Yoast SEO and its GraphQL bridge, Redirection for redirects, and a minimal theme that points previews and links to the front end. It also requires the Classic Editor plugin, a telling detail: the example does not try to reproduce blocks.

Next.js brings incremental regeneration, which rebuilds a page in the background, on the first visit after a set delay or on demand, and a draft mode for previews. These mechanisms are powerful, but they have to be wired to WordPress: publishing a post must trigger a rebuild of the right pages.

Astro, the simplest REST route

Astro publishes its own WordPress guide, based on the REST API, with static or server-side generation. For an editorial site with no user accounts or commerce, it is often the lightest option. Nuxt and SvelteKit work too, but their documentation offers no dedicated WordPress guide; WP Engine publishes some for its own platform.

Faust.js and Gatsby: what became of them

Faust.js, developed by WP Engine, used to present itself as the headless framework for WordPress. In February 2025, the team repositioned it as a simple toolkit for Next.js and dropped its experiment with Next.js’s newer router. Do not pick it by default for a new project.

Gatsby, long associated with headless WordPress, has belonged to Netlify since February 2023. Releases still come out, slowly: the latest dates from February 2026. Gatsby is no longer the natural starting point it once was.

Previews and the editing experience

Rebuilding the Preview button

It is the first thing editorial teams notice. In WordPress, the Preview button opens the WordPress site itself, which no longer exists for the public. You need to redirect that link to the front end with the preview_post_link filter, then have the front end fetch the draft through an authenticated request and display it outside the cache.

Next.js provides a draft mode for this, turned on by a dedicated route protected by a secret. Its documentation recommends redirecting to the address supplied by the CMS, not to a request parameter, to avoid an open redirect. WPGraphQL reworked its preview handling in late August 2026, in version 2.21.0, with one trap to know: an unauthorized preview request silently returns the published version, with no error.

Blocks outside WordPress

A post written in the block editor reaches the front end either as ready-made HTML or as block data to rebuild component by component. In the first case, you have to reproduce the block styles; in the second, every block in use needs its counterpart in the front end.

The Interactivity API, which powers some recent blocks, relies on WordPress’s PHP rendering: a decoupled front end does not run it as is. The editor’s recent features, covered in our overview of what changed in WordPress 7, therefore do not automatically carry over to a headless front end.

A new lit glass facade in front of an older structure being replaced behind it

The Vox Media case: leaving an in-house CMS for headless WordPress

Vox Media, which then published The Verge, Vox, SB Nation, Eater and Polygon, first gave The Verge a new front end in 2022, then moved its sites to headless WordPress between 2023 and 2025. The project is documented by the publisher itself, by the host WordPress VIP, by the agency XWP, in charge of the back end and content migration, and by a talk at WordCamp US 2024. It is one of the most complete examples of what this architecture costs and delivers.

Chorus, an in-house CMS

For more than ten years, Vox Media published its sites on Chorus, a CMS built in-house. In 2018, the group even opened it to other publishers, presenting it as the backbone of the company. Maintaining your own CMS has a cost, though, and in August 2023, WordPress VIP announced that Vox Media was adopting it to replace Chorus, with a stated goal: more reliability, speed and uptime.

Front end first, CMS second

What sets the project apart is its order. As early as September 2022, The Verge moved onto Duet, Vox Media’s new display platform, built by its own engineers along with its design system. The CMS changed later, underneath a site that was already live. Duet connects to WordPress through WPGraphQL.

According to XWP, after a discovery phase, a proof of concept first confirmed that WordPress VIP could feed Duet, and dispelled internal doubts. The agency lists among the challenges skepticism about whether WordPress could handle the scale, preserving editorial habits from the Chorus era and different data structures from one site to another. Forty-two people from XWP and Vox Media worked on delivery.

A brand-by-brand migration

Vox.com led the way, with a redesign launched in May 2024 for its tenth anniversary. Polygon followed in August 2024; its publisher explained that the new version rests on Duet, coupled with a more flexible back end on WordPress VIP. In September 2024, a joint team presented at WordCamp US the migration from Chorus to a headless WordPress multisite network, with a custom GraphQL API for Duet.

SB Nation followed in August 2025, with nearly two hundred fan communities. According to XWP, more than fifteen million comments a year were preserved through the migration. The agency also reports a 40% traffic increase for Vox.com over the first forty days, a figure to treat with caution: it is not broken down, and the design overhaul shipped at the same time.

The page source shows it today: The Verge, Vox, SB Nation and Eater are rendered by Next.js, with media served from /wp-content/uploads/sites/ paths, the signature of a WordPress multisite.

What the case teaches

Decoupling let Vox Media ship a new front end before replacing its CMS, then swap the engine underneath a running site. That is the strongest argument for headless, demonstrated at the scale of a media group. The cost matches: an in-house front-end framework and design system, a team of more than forty people, a high-end host and a program spread over three years, from The Verge’s new front end in 2022 to SB Nation in 2025.

The difficulties named by XWP, which handled the back end, are both editorial and technical: workflows, data migration, community features. The front end was Vox Media’s own work, and that account does not cover it.

A final, unexpected lesson: in May 2025, Polygon was sold to another group, less than a year after its migration. In 2026, the rest of Vox Media was split between two buyers. What happens to the shared platform is not documented. A headless investment of this size is also a bet on the stability of the organization behind it.

SEO: metadata, sitemaps, canonicals

Yoast and Rank Math through the API

SEO metadata is still managed in WordPress. Yoast SEO adds it to REST API responses and offers an endpoint that returns the full head for a given address. Rank Math offers an equivalent endpoint, to be enabled in its settings. Our comparison of WordPress SEO plugins details their other differences.

Identity comes from the front end

The classic trap is about addresses. If the site address in WordPress’s general settings points to the CMS, canonical tags, Open Graph data and structured data will point to the CMS, not to the public site. Jason Bahl, who runs the WPGraphQL site headless, summed up the rule in 2026: take content from WordPress, take identity from the front end.

Another trap he describes: if the CMS is set to discourage search engines, Yoast will return a noindex directive that the front end must not copy. Finally, the sitemap, robots.txt and redirects must be served by the front end. Next.js’s official example disables Yoast’s sitemaps and generates its own on the front end.

Authentication and security

Application passwords, JWT and cookies

To read drafts or write to WordPress, the front end has to authenticate. Since WordPress 5.6, application passwords, sent as HTTP basic authentication over an encrypted connection, are the built-in solution. The documentation gives this example.

curl --user "USERNAME:PASSWORD" https://HOSTNAME/wp-json/wp/v2/users?context=edit

These passwords stay on the server side, never in code sent to the browser. Plugins offer JWT tokens, and more complete login solutions exist for WPGraphQL. Cookie authentication requires a security token, otherwise the request is treated as anonymous.

A public API by default

The REST API documentation advises against disabling it. To require authentication on every request, it offers this filter.

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }
    if ( ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_not_logged_in',
            __( 'You are not currently logged in.' ),
            array( 'status' => 401 )
        );
    }
    return $result;
});

Beware: this filter also blocks anonymous reads. A static or regenerated front end will then have to authenticate on every rebuild.

The WPGraphQL settings to check

WPGraphQL’s default settings deserve a review before going live. The /graphql endpoint is open to anonymous visitors, like the REST API. Batched queries are allowed, up to ten per call. The query depth limit exists but is turned off: turn it on to keep an overly nested query from putting heavy load on the server.

Public schema introspection, which describes the whole API to anyone who asks, is only on by default in environments declared as local or development. Check that your production environment is declared as such, and that debug mode stays off.

September 2026: seven security advisories for WPGraphQL

Hiding WordPress behind a front end does not shrink the attack surface: it moves it to the API. In September 2026, the WPGraphQL project published seven security advisories, five of them rated high, including a privilege escalation up to the Administrator role and a flaw that let a Contributor publish.

Any WPGraphQL version older than 2.23.1 is exposed to at least one of them, and two of the advisories target its companions: you also need WPGraphQL Smart Cache 2.3.2 and WPGraphQL for ACF 3.0.0. The principles in our guide to WordPress security hardening therefore still apply to the CMS.

Hosting and the real cost of two stacks

Vercel, Netlify and WP Engine

A headless site means two applications to host, monitor and update. On the front-end side, Vercel’s free plan is reserved for personal, non-commercial use: a business site moves to the Pro plan, $20 per month per developer, with included usage credit and then pay-as-you-go billing. Netlify works with credits: a free plan, a Personal plan at $9 per month, then a Pro plan from $20 per month up to $126 for the largest credit tier. Every production deploy uses 15 credits.

WP Engine offers a platform that hosts both halves, with no public price: you have to request a quote. With Vercel or Netlify, add the hosting of WordPress itself, still required. Either way, the biggest cost remains the time of developers able to maintain two stacks.

Cache invalidation

Caching is both the strength and the difficulty of headless. A static front end is very fast, but every publication must trigger a rebuild of the affected pages. With several instances, Next.js’s default cache is specific to each one, and WP Engine’s documentation states that its optional edge cache, the Edge Full Page Cache, is not purged by events coming from WordPress and waits for its TTL to expire.

On a site with frequent content updates, such as a news site covering an evolving story, WordPress VIP notes that cache invalidation offsets part of the expected performance gains. Measure in the field, as our guide to Core Web Vitals fixes suggests, rather than assume.

When not to go headless

Headless gets expensive as soon as a site depends on what WordPress renders itself. Forms, page builders, membership or booking plugins work through their rendering in the theme: in a headless setup, you have to rebuild them or do without.

WooCommerce has an API dedicated to cart and checkout, the Store API. But each payment gateway expects different data, and WooCommerce admits it cannot document them all. A headless store remains a heavy project; to improve a classic store, our guide to WooCommerce checkout optimization offers more direct levers.

Be wary of headless in these situations:

  • The website is your only publishing channel: no app, no other screen to feed.
  • Marketing depends on many plugins that render in the theme.
  • You have no team able to build and run a separate front end, nor the budget to pay one over time.
  • Writers care about faithful previews and the visual editing of the block editor.
  • The site needs recent WordPress features as soon as they ship.

Summary table

Criterion Classic WordPress Headless WordPress
Front-end freedom Limited by the theme Complete
Previews and visual editing Built in To rebuild
Plugins that render in the theme Work To replace
SEO Handled by a plugin Metadata via the API, the rest in the front end
Security Site and admin exposed Surface moved to the API
Hosting One stack Two stacks, two bills
Best for The vast majority of sites Several channels, a dedicated front-end team

Frequently asked questions

Is a headless site faster?

Not automatically. A well-built static front end can be very fast, but cache invalidation, API requests and browser-side JavaScript can cancel out the gain. WordPress VIP itself warns that, without the right team, the result may well be slower.

Is WPGraphQL part of WordPress core?

No. It is a canonical plugin, announced as such in October 2024 and maintained in its own repository. The REST API remains the API built into core.

Can you keep Yoast SEO with headless?

Yes, for metadata, which it exposes through the REST API or through a community GraphQL plugin. The sitemap, robots.txt, redirects and canonical addresses, on the other hand, must be handled by the front end.

Is a headless WooCommerce store realistic?

Yes, with the Store API, but it is a substantial project: cart, sessions, payment and store plugins all have to be rethought. For most stores, a fast theme and an optimized checkout deliver better results at a much lower cost.

How much does hosting a front end cost?

For a business site, plan on at least Vercel’s Pro plan, $20 per month per developer, or a paid Netlify plan, since the free plan pauses the site once its 300 monthly credits are used, on top of WordPress hosting. The biggest expense remains the time spent developing and maintaining the front end.

Conclusion

Headless does not improve a site by itself. It moves the work: fewer constraints on display, more responsibility on development, API security, caching and SEO. Vox Media got real value from it, with a team and resources few organizations can bring together.

Ask yourself three questions before you start. Do you have several channels to feed, or a front end the theme genuinely cannot deliver? Do you have a team able to maintain two applications over time? Will your writers accept losing part of the editor’s comfort? If any answer is no, a well-optimized classic WordPress, or a hybrid approach, will serve you better.

Sources

LaFactory designs, builds and maintains WordPress and WooCommerce sites, and develops its own plugins. Talk to us about your WordPress project.

Francis Rozange

Former section editor at Libération, he runs LaFactory, an international web agency since 1996.

Cart