What Changed in 2025
Three things moved meaningfully. First, the WordPress block editor's REST API surface matured enough that fetching structured block data from a headless frontend is now practical without writing custom endpoints. The Block Bindings API and interactivity API both exposed cleaner contracts for external consumers.
Second, the hosting landscape caught up. Vercel, Netlify, and Cloudflare Pages now all have first-class WordPress backend support in their documentation, and the ISR (Incremental Static Regeneration) patterns that make headless viable for content-heavy sites are well-documented with WordPress-specific examples.
Third, WPGraphQL reached 1.0 stability. For teams that chose GraphQL over the REST API, this removes the "are we building on quicksand" concern that was legitimate in earlier years.
REST API vs. GraphQL
This debate is largely settled in practice: choose based on your frontend team's familiarity, not on theoretical efficiency gains. Both approaches are production-viable in 2025.
REST API is lower friction: no additional plugin, no schema maintenance, works out of the box. The response payloads are verbose but manageable if you use sparse fieldsets properly. GraphQL via WPGraphQL is more expressive for complex content models — particularly useful for sites with deep taxonomies or relational custom post types — but requires the team to maintain a schema and understand resolver behaviour.
Start with the REST API. If you hit three separate instances where GraphQL's query flexibility would have meaningfully simplified your data fetching, switch. Do not switch speculatively.
What Stayed the Same
The WordPress admin is still monolithic and coupled to the PHP rendering layer. Custom post type registration, ACF field groups, and plugin configuration all happen in the WordPress dashboard, and none of that has a clean headless equivalent. You are still running a full WordPress installation — you have just moved the frontend.
Authentication for protected content remains awkward. JWT-based auth works, but maintaining tokens across ISR cache boundaries requires careful architecture. Membership sites and paywalled content continue to be the hardest headless WordPress use case.
Where It Still Falls Short
Preview mode for editors is still the biggest operational pain point. A content editor expecting live preview while drafting a post on a headless site needs your frontend to support draft-mode rendering. This works but requires non-trivial setup — and it breaks every time your caching or auth setup changes.
- Plugin ecosystem: 90% of the WordPress plugin catalogue assumes traditional rendering. Form plugins, e-commerce extensions, and page builders are partially or fully incompatible with a headless approach.
- Real TTFB: Despite the CDN narrative, poorly-implemented ISR on headless WordPress consistently produces higher median TTFB than a well-optimised traditional WordPress setup with full-page caching.
- Operational overhead: Two deployable systems, two CI pipelines, two sets of logs, and two teams of stakeholders who need to understand where their problem lives.
When It's Worth Deploying
Headless WordPress earns its complexity in a narrow set of scenarios. If all of the following are true, it is worth serious evaluation. If even one is absent, the overhead is likely unjustifiable.
- You have a dedicated frontend team already working in React, Next.js, or a similar framework — not a WordPress developer who will learn React for this project.
- The content model is complex enough that the block editor's output limitations actively constrain your UI requirements.
- You need a non-WordPress frontend experience (native mobile app, interactive data product) consuming the same content.
- You have the operational capacity to run, monitor, and debug two distinct systems in production.
Honest Verdict
Headless WordPress is a real, production-viable approach in 2025. It is not a default-good decision. For most agency WordPress projects — marketing sites, WooCommerce stores, content portals — optimised traditional WordPress with a capable caching layer will outperform headless on every metric that matters to the client: cost, TTFB, editorial experience, and plugin compatibility.
Deploy headless when your product genuinely requires it. Treat it as a deliberate architectural choice, not a modernity signal.