Headless WordPress
Founded 2003
Headless WordPress Verdict
2.5/5Summary
WordPress powers 43% of the web, and that familiarity is both its greatest strength and its biggest trap in a headless context. Going headless with WordPress does not solve the underlying problems: you still run a PHP/MySQL backend, still manage plugin security, and still inherit years of monolithic thinking. Purpose-built headless platform give you a cleaner content model, better API ergonomics, and less ongoing maintenance burden. We moved away from WordPress headless for these reasons, and we have not looked back.
Best For
Teams with a large existing WordPress investment, a content team that refuses to leave the WP editor, or publishers serving multiple channels from a single editorial workflow.
Watch Out
Headless WordPress still runs the full WordPress stack on the backend, you have not escaped plugin bloat, PHP vulnerabilities, or database scaling challenges by decoupling the frontend.
What Is Headless WordPress?
WordPress headless refers to using WordPress purely as a content backend, while the public-facing frontend is built separately using a modern JavaScript framework like Next.js, Astro, or Nuxt. WordPress manages the editing experience, stores content in its MySQL database, and exposes that content via an API. The frontend consumes the API and handles all rendering independently.
There are two primary API approaches. The WordPress REST API ships with WordPress core and requires no configuration - it provides JSON endpoints for all standard content types (posts, pages, media, taxonomies) and can be extended for custom post types. WPGraphQL is a plugin that exposes the full WordPress data model as a GraphQL API, allowing more precise queries, nested data fetching in a single request, and better integration with ACF custom fields. As of 2026, WPGraphQL v2 has added persisted queries, per-field cache control directives, and federation support for composing multiple WordPress backends.
Teams consider headless WordPress for a few reasons: they have a large existing WordPress content library or editorial team, they want modern frontend performance without a full CMS migration, or they need to serve content across multiple channels (web, mobile app, smart TV) from a single backend. The pitch makes sense on paper. The reality of maintaining it at scale is where the complexity surfaces.
Key Features
- WP REST API - built into WordPress core since 4.7, no setup required, full CRUD support for all content types
- WPGraphQL - canonical plugin for GraphQL delivery, exposes ACF fields, custom post types, menus, and taxonomies in a typed schema
- Advanced Custom Fields (ACF) - the de facto standard for structured content modeling in WordPress, flexible content layouts, repeater fields, and relationship fields all surface in WPGraphQL
- Faust.js - WP Engine's React framework for headless WordPress, provides routing, authentication, and preview mode abstractions (active but slower-moving as of 2025-2026)
- Gutenberg block editor - familiar, widely-understood editing interface; block-based content can be mapped to frontend components
- Role-based access control - five built-in roles, extensible via plugins for more granular permissions
- Massive plugin ecosystem - 59,000+ plugins for SEO (Yoast), forms, e-commerce, multilingual, and more
- Managed hosting options - WP Engine, Kinsta, Pressable, and WordPress VIP provide production-grade infrastructure for the backend
Pricing
WordPress.org (self-hosted): The software is free and open source. You provide the hosting - a production-ready setup on managed WordPress hosting (WP Engine, Kinsta, Pressable) runs $30-$200/month depending on traffic. Add ACF Pro at $59/yr, WPML for multilingual at $99-$199/yr, and a premium caching plugin at $49-$99/yr, and your annual plugin bill easily reaches $300-$500 before any custom development.
WordPress.com: Hosted plans range from $8/month (Explorer) to $45/month (Entrepreneur) billed annually. These are primarily aimed at standard website publishing - headless WordPress on WordPress.com is possible but limited by what the platform exposes. The free tier exists but is not suitable for production work.
WordPress VIP: The enterprise platform starts at $25,000/year and scales with traffic. This is the tier that powers CNN, TechCrunch, and The Wall Street Journal. It includes dedicated infrastructure, enterprise-grade security, SLA guarantees, and professional services. Pricing is customised per engagement.
Total cost reality: The free-software pitch can be misleading for headless projects. When you factor in managed hosting, premium plugins, development time for content modeling, preview configuration, and ongoing maintenance, the real cost of a headless WordPress setup is comparable to - or higher than - a managed headless CMS subscription that bundles all of that infrastructure.
Our Experience
Lucky Media used WordPress extensively in our earlier years, and we understand why teams reach for it. The editorial experience is genuinely good, the plugin ecosystem solves real problems fast, and clients often arrive already knowing it. But as we moved toward more sophisticated web and app projects, headless WordPress consistently created more friction than it resolved.
The core issue is that WordPress was designed as a publishing platform, not a content API. Every headless project required plugin stacking to get a reasonable content model (WPGraphQL plus ACF plus Flexible Content), custom engineering to implement preview, and ongoing management of the full WordPress security surface - regardless of whether any of that complexity benefited the client. We were essentially building a content API on top of a system that wanted to be a website.
We now reach for purpose-built headless platforms - primarily Contentful, Sanity and Statamic - when clients need a structured headless CMS. The content modeling is schema-first rather than retrofitted. Preview works out of the box. The API is designed for the job. And we are not managing MySQL databases and PHP security patches on clients' behalf. For teams already invested in WordPress with no appetite for migration, headless WordPress is a valid path. For net-new projects, we do not recommend it.
When Lucky Media Recommends WordPress Headless
We do not recommend WP as a Headless solution.
faq
Can I use WordPress as a headless CMS without changing my existing site?
Yes, in principle. Both the REST API and WPGraphQL work alongside a traditional WordPress theme - you can start consuming content via API without dismantling anything. However, making your content model work well for a headless frontend usually requires restructuring post types and custom fields, which does touch existing content architecture.
Is headless WordPress free?
The WordPress software (wordpress.org) is free and open source. But running it headless is not free in practice. You need managed hosting ($30-200/mo on WP Engine or Kinsta for a production backend), plus ACF Pro ($59/yr) for structured content modeling and WPGraphQL (free plugin, but requires developer setup time). If you need multilingual, WPML adds $99-199/yr. The frontend is a separate hosting cost on top. The total cost of ownership is comparable to a paid headless CMS subscription once developer time is factored in.
What is WPGraphQL and why do most headless setups use it instead of the REST API?
WPGraphQL is a free plugin that exposes your WordPress content as a GraphQL API. Most headless teams prefer it over the REST API because it lets you query exactly the fields you need in a single request, eliminating over-fetching. It also surfaces ACF custom fields in the schema, which the REST API requires extra configuration to expose. WPGraphQL v2 added persisted queries and CDN caching support, making it more production-ready.
How does headless WordPress compare in cost to a platform like Sanity or Contentful?
wordpress.org software is free, but the total cost of ownership is not. You need managed hosting ($30-$200/mo for a production-grade setup on WP Engine or Kinsta), premium plugins like ACF Pro ($59/yr) and WPML ($99-$199/yr if needed), and ongoing developer time to maintain the stack. A dedicated headless CMS often has a predictable subscription cost that bundles hosting, CDN, and API delivery - which can be comparable or cheaper when developer time is factored in.
What are the disadvantages of headless WordPress?
The main disadvantages are maintenance burden, content modeling friction, and preview complexity. You still run a full PHP/MySQL WordPress backend - core updates, plugin security patches, and database management continue even though the frontend is decoupled. Content modeling requires plugin stacking (ACF plus WPGraphQL plus Flexible Content) rather than a schema-first approach. Preview requires custom development on every project. Real-time collaboration is absent. Localization needs third-party plugins. For teams starting fresh, purpose-built headless platforms like Sanity or Contentful remove most of this overhead.
Our verdict
| Content Modeling | |
|---|---|
| How flexible is the content modelling system?Can you define complex, nested, and relational content types without workarounds? | ●●●●●2/5 WordPress custom post types and ACF (Advanced Custom Fields) give you significant flexibility, but content modeling requires plugin stacking rather than being native to the platform. Complex relational content and deeply nested structures need WPGraphQL plus ACF Plus plus Flexible Content layouts, workable, but fragile compared to schema-first headless platforms. |
| How well does the platform support reusable content blocks?Blocks that map directly to design system components. | ●●●●●2/5 Reusable content blocks exist via ACF Flexible Content or the block-based Gutenberg editor, but mapping them cleanly to design system components requires careful plugin configuration and custom development. There is no native concept of component-level reusability, you are adapting a publishing model into a component model. |
| Does the platform enforce content validation rules natively?Required fields, character limits, regex, custom validators. | ●●●●●2/5 Field-level validation is available through ACF and custom plugin code, but it is not enforced at the API layer. A determined editor can bypass most constraints. Native WordPress offers required fields but no character limits, regex validators, or custom validation rules without additional development. |
| Editor Experience | |
| How intuitive is the editing interface for a non-technical editor?Could a new editor publish their first piece of content within one hour, without help? | ●●●●●4/5 This is where WordPress earns its reputation. Millions of content editors already know the WP admin interface. Onboarding for an existing WP user is near-instant. For net-new editors, the Gutenberg block editor is reasonably intuitive and the learning curve is gentle compared to structured headless platforms. |
| Does the platform offer live or visual preview of content?As it will appear on the frontend, without developer configuration. | ●●●●●2/5 Live preview in a headless setup requires bespoke development. WordPress's built-in preview targets the traditional theme layer, not a decoupled frontend. Faust.js provides a preview mode, but configuring it correctly requires meaningful engineering effort and breaks if the frontend stack changes. |
| How well does the platform handle the full editorial workflow?Drafts, scheduling, approval chains, role-based permissions. | ●●●●●3/5 Drafts, scheduled publishing, and basic role-based permissions are built in. Multi-step approval workflows require plugins (PublishPress, Nelio Content) that add maintenance overhead. Compared to platforms with native editorial workflow tooling, WordPress gets the basics right but requires plugins for anything beyond simple draft/publish. |
| How effective is the media and asset management?Upload, organisation, image transforms, search at scale. | ●●●●●3/5 The WordPress Media Library is functional and familiar. It handles uploads, basic organisation, and image cropping. At scale it becomes unwieldy, no tagging, no advanced search, folders require plugins. For a headless setup, images still need to be served from WordPress or offloaded to a CDN integration, adding configuration overhead. |
| Collaboration | |
| Does the platform support real-time collaboration?Simultaneous editing, presence indicators, inline comments. | ●●●●●2/5 WordPress has no native real-time collaboration. Two editors working on the same post will overwrite each other without warning in most configurations. The Gutenberg editor has basic collaborative editing in development as of 2026, but it is not production-ready for simultaneous authoring at the level competitors provide. |
| How granular and practical are user roles and permissions?By content type, locale, or specific fields, not just admin/editor. | ●●●●●3/5 WordPress ships with five default roles (admin, editor, author, contributor, subscriber) and these cover most small team needs. Fine-grained permissions, by content type, taxonomy, or specific fields - require plugins like Members or User Role Editor. It is workable but not elegant. |
| Localisation | |
| Is multi-locale content management native?Field-level localisation, not page duplication or plugin workarounds. | ●●●●●2/5 Multi-language in WordPress requires third-party plugins (WPML, Polylang, or TranslatePress). None of these are native, all add database complexity, and none offer true field-level localisation in a structured headless sense. For serious multilingual projects this is a significant limitation. |
| Can editors manage locale fallback logic natively?e.g. show English if French translation is missing. | ●●●●●1/5 Locale fallback logic is not a native WordPress concept. WPML and Polylang have partial support, but managing fallback behaviour programmatically via the API requires custom development. This is one of the clearest gaps vs. purpose-built headless platforms. |
| Developer Experience | |
| How well-documented and developer-friendly is the delivery API?REST, GraphQL, typed SDKs, TypeScript support. | ●●●●●3/5 The WP REST API is well-documented and stable. WPGraphQL has strong documentation and an active community, with the v2 release in 2025-2026 adding persisted queries and federation support. TypeScript type generation works via GraphQL Code Generator. The gap vs. native headless platforms is the complexity of the underlying data model, posts, meta fields, and custom post types create a schema that reflects decades of WordPress architecture decisions rather than clean content modeling. |
| How fast and friction-free is integration with modern frontend frameworks?Next.js, Astro, Nuxt, Remix, official examples or starter kits available. | ●●●●●3/5 Vercel maintains an official Next.js + WordPress starter. WP Engine's Faust.js provides a more opinionated React framework for headless WordPress, though its development pace slowed in 2025-2026 as WP Engine refocused resources. Astro and Nuxt integrations exist via community packages. The ecosystem is real, but most integrations require more configuration than native headless CMS SDKs. |
| Does the platform provide a Management API for programmatic content operations?Bulk import, AI pipelines, scripting. | ●●●●●2/5 The WP REST API supports create, read, update, and delete operations, but it is optimised for traditional editorial use - not bulk content operations, AI ingestion pipelines, or programmatic schema management. There is no concept of environment-scoped content operations or transactional batch writes native to the platform. |
| Does the platform support environment branching or staging environments?For safe content and schema testing before promoting to production. | ●●●●●2/5 WordPress has no native staging or environment branching. Most teams solve this with separate WordPress installs, WP Migrate DB for database syncing, or managed hosting environments (WP Engine, Kinsta) that provide staging slots. Schema changes cannot be previewed or rolled back in any structured way, a core limitation for iterative development. |
| Performance | |
| Does the platform deliver content via a global CDN?And how does this affect real-world API response times for your frontend? | ●●●●●2/5 WordPress itself does not deliver content via a CDN, that depends entirely on your hosting provider and caching plugins (WP Rocket, W3 Total Cache). In a headless setup, API responses come from a PHP application server, not a globally distributed edge network. Latency is highly dependent on infrastructure choices and requires deliberate engineering to optimise. |
| How straightforward is hosting and deployment?Does the platform reduce or add infrastructure complexity? | ●●●●●2/5 Deploying and maintaining WordPress headless requires running two systems: the WordPress backend (PHP, MySQL, web server) and the decoupled frontend (Node.js, CDN, build pipeline). This is significantly more infrastructure than a managed headless CMS. WordPress.com and WP Engine simplify the WordPress side, but the overall system complexity is real. |
| Ecosystem & Longevity | |
| How mature and practically useful is the integration ecosystem?Not just quantity, are the integrations your clients actually need available and well-maintained? | ●●●●●4/5 With over 59,000 plugins and 20+ years of community development, the WordPress ecosystem is unmatched in breadth. ACF, WooCommerce, Yoast, and hundreds of other well-maintained plugins solve real problems quickly. For headless specifically, WPGraphQL, Faust.js, and official hosting integrations with WP Engine and Kinsta make the setup viable. The caveat: plugin quality is highly variable, and in a headless context you only use a fraction of this ecosystem. |
| How active and meaningful is platform development?Community health, release cadence, direction of travel. | ●●●●●4/5 WordPress's community is the largest in the CMS world, 40% of the web runs on it, and WordCamp events run globally. WPGraphQL and the headless ecosystem specifically have an active community and regular releases. However, the overall direction of WordPress is toward the full-site editing and block editor experience, not headless-first architecture, so community energy for headless specifically is a subset of the whole. |
Final verdict The verdict score is a weighted average of the criteria above. | 2.5/5 |