Where GraphQL for WordPress Stands Now
Three years ago, WordPress developers evaluating GraphQL servers had two real options: WPGraphQL and Gato GraphQL (then known as GraphQL API for WordPress). A lot has shifted since then — not just in the plugins themselves, but in how the broader ecosystem treats headless WordPress and what role GraphQL plays beyond it.
One thing that hasn't changed is the gap between enthusiasm for headless WordPress and its actual adoption. Headless setups — whether powered by GraphQL or the WP REST API — still represent a small fraction of the overall WordPress market. WPEngine's "State of Headless" research during the 2019–2021 period showed meaningful growth among enterprise adopters, jumping from 53% to 64%, and predicted headless would become standard for large-scale organizations. Yet an informal poll of the r/WordPress community a year ago tells a different story: interest and curiosity are high, but real-world usage remains limited. Headless WordPress is less a mainstream alternative than a particular development flavor with a dedicated following.
WPEngine Doubles Down on Headless
WPEngine continues to bet heavily on headless WordPress becoming the default approach. Its Faust.js framework, built on WPGraphQL, pairs WordPress as the back-end CMS with Next.js handling front-end rendering. Faust.js goes as far as replicating the WordPress template system for Next.js, making it easier to adapt familiar site structures to a headless setup. This strategy fits neatly with Atlas, WPEngine's platform for hosting both Node.js and WordPress, and with its acquisition of Advanced Custom Fields, which helps model entity relationships in WordPress. Add in WPEngine's takeover of the Headless WordPress Discord server, and practically every pillar of headless WordPress tooling now has WPEngine behind it.
Rethinking What a GraphQL Plugin Can Do
The reframing of Gato GraphQL (formerly GraphQL API for WordPress) reflects a broader evolution in how GraphQL is used with WordPress. The original plugin converted REST API data into structured GraphQL responses. The current version, available for free in the WordPress Plugin Directory, is a full freemium offering: the open-source plugin provides the GraphQL server, maps the WordPress data model into the schema, and supports custom endpoints and persisted queries. The commercial add-on layers on multiple query executions, automation, and an HTTP client for calling external services.
More important than the feature breakdown is the underlying philosophy. WPGraphQL moves data in a single direction — converting REST API output into GraphQL responses for consumption by a front-end. Gato GraphQL treats GraphQL as a two-way, agnostic tool for interacting with data. That means the same query language can send notifications when posts are published, regex search and replace strings across all posts during a migration, import content from RSS feeds or CSV files, or call external services. Paired with WordPress hooks and WP-Cron, these interactions can run as automated tasks, giving GraphQL a role in everyday content operations, not just headless front-ends.
The JavaScript Framework Landscape Shifts
Gatsby was arguably the go-to framework for headless WordPress in 2021 — but that's no longer the case. Gatsby's decline has steepened, and its official WordPress integration is no longer actively maintained. Next.js remains a strong contender with starter templates built specifically for WordPress back-ends. Meanwhile, SvelteKit and Nuxt are gaining ground, a topic that came up at WordCamp Asia 2024 in a session about choosing frameworks for headless WordPress. Astro is another recent entrant with official WordPress documentation. The overall picture hasn't fundamentally changed — developers still pick a JavaScript framework to fetch WordPress content via GraphQL — but the roster of viable options is wider and the barrier to entry is lower thanks to more off-the-shelf templates.
GraphQL Quietly Becomes WordPress "Core"
WordPress 6.5 introduced Plugin Dependencies, a feature that lets plugins declare other plugins as required via a "Requires Plugins" header comment. WordPress checks the Plugin Directory for those dependencies and installs the entire set together. The practical effect for the GraphQL ecosystem is significant: since both WPGraphQL and Gato GraphQL live in the Plugin Directory, any developer can now ship a plugin that depends on a GraphQL server without forcing users through extra installation steps.
/*
Plugin Name: Example plugin
Requires Plugins: gatographql, advanced-custom-fields
*/
This opens the door to plugins that use GraphQL internally — fetching data to render Gutenberg blocks, for instance — without worrying about how the GraphQL layer gets installed. And on a technicality worth noting: any plugin available in the WordPress Plugin Directory is now, in effect, part of WordPress Core per this dependency mechanism. That means GraphQL, in practical terms, is available as a core feature for any plugin developer who wants to build on it.
Whether that counts as GraphQL becoming a first-class WordPress citizen — or sidestepping the question of whether it belongs in Core at all — depends on your perspective. The security and architectural concerns that argue against embedding GraphQL in WordPress Core itself may still hold. But with Plugin Dependencies in place, those debates are largely moot for developers who simply want to deliver plugins that depend on GraphQL functionality.
What's Changed in Practice
The fundamentals of choosing between WPGraphQL and Gato GraphQL haven't changed: WPGraphQL is built around serving GraphQL to front-ends consuming WordPress content, while Gato GraphQL approaches GraphQL as a general data interaction layer, useful for site management tasks beyond headless delivery. What's different in 2024 is the surrounding context — a plugin dependency system makes GraphQL a practical foundation for other plugins, the JavaScript ecosystem has churned with Gatsby falling behind, and the commercial backing behind headless WordPress is deeper than it was. None of these developments have made headless WordPress mainstream, but they've made GraphQL more deeply woven into the options available to WordPress developers, whether they're building headless sites or not.
GraphQL as WordPress’s Missing Integration Layer
At WordCamp Asia 2024, Human Made co-founder Noel Tock made a pointed case about WordPress’s trajectory: growth has flattened, not because the CMS is obsolete, but because a new wave of composable services lets developers assemble content stacks tailored to their exact needs — something WordPress has struggled to match out of the box.
Tock’s prescription for renewed momentum is twofold: clean up the plugin ecosystem and build first-class integrations with external services. That second point is where GraphQL enters the picture. Rather than treating GraphQL as merely a headless accessory, it could function as the connective tissue between WordPress and the broader web of services it increasingly needs to talk to.
The Plugin Dependencies feature introduced in WordPress 6.5 is an early signal of this direction. When plugins can declare other plugins as dependencies, the plugin directory effectively becomes an extension of WordPress Core itself. WPGraphQL and Gato GraphQL are both listed there, which means any plugin developer can lean on GraphQL capabilities without reinventing the wheel.
The Road Ahead for GraphQL in WordPress
Headless WordPress remains a frequently discussed “future” that has yet to see widespread developer adoption. Interest in headless architectures is real, but most WordPress developers still use the CMS as a full-stack platform rather than a pure back end.
The frameworks that do push WordPress into headless territory — tools that query data via GraphQL — are not going anywhere. Many of those frameworks already depend on WordPress plugins that bridge the REST API into structured GraphQL responses, creating a practical path for developers who want modern data-fetching without abandoning WordPress’s native ecosystem.
This is where GraphQL’s real potential lies. It is not only a tool for decoupled front ends. GraphQL can drive content transformations on the WordPress side as well, whether those transformations happen locally or trigger external services. Because those transforms can be automated, they open up content management workflows that operate both inside and outside the WordPress admin — data flowing in both directions.
The conclusion from all of this is straightforward: headless may remain WordPress’s perpetual “next step,” but GraphQL can be the mechanism that makes WordPress a more adaptable platform today. By giving developers a standard way to query and mutate content across internal and external boundaries, GraphQL positions WordPress as a central hub rather than a standalone monolith. That is the kind of innovation that could help WordPress reclaim its role as a driving force in the CMS market.
