Many times, “Go headless” becomes the default advice for almost any WordPress project, while other times it gets dismissed outright as unnecessary complexity. Neither instinct is reliable on its own. This session gives you an honest, practical framework for making the call either way, based on what your specific project actually needs.
We’ll break down what actually changes when you strip WordPress down to a content API and hand the frontend to a separate framework, and look at real scenarios on both sides: where headless genuinely solves a problem traditional WordPress can’t, like omnichannel content, high-performance frontends, or teams already working in React or Vue, and where traditional WordPress remains the stronger, simpler choice. Along the way, we’ll cover the layer most headless builds get wrong: authentication, and how the choice between Application Passwords, JWT, and OAuth changes what your project can and can’t do.
This isn’t a talk about which architecture is “better.” It’s about learning to diagnose a project correctly before you commit to one, because that decision ripples into everything downstream: what a client can edit themselves, what an SEO strategy needs to account for, what a plugin ecosystem can or can’t do for you, and what a build actually costs to maintain long after launch.
Key takeaways
- A clear, two-sided framework for deciding when headless WordPress is worth the trade-off, and when traditional WordPress is still the better call.
- A real look at what you gain and what you give up when you decouple WordPress: performance and flexibility on one side, plugin ecosystem dependencies and editorial simplicity on the other.
- A practical comparison of authentication methods (Application Passwords, JWT, OAuth, cookie-based auth) and when to use each.
- The right questions to ask on any project, as a developer, an agency, or a client, before committing to either architecture.