When does Headless WordPress make sense?
The most important part of any potential Headless WordPress project is the evaluation phase – aka Discovery.
During this phase we aim to determine what the ideal stack is, taking into account both the technical requirements to reach client goals and the needs and limitations of all stakeholders.
A thorough evaluation should answer:
- Whether a headless build solves the client’s needs (better than alternatives).
- Whether we have the resources to deliver the headless build (on time and of quality)
- Whether the client has the resources to maintain the build once it is delivered.
- Whether there are additional implications, integrations, and considerations that are important to the client
The following rubric provides guidelines and prompts to help you evaluate what flavor of WordPress makes the most sense for a given project.
ℹ️ Note
Currently, the costs and barriers to entry for adopting headless WordPress limit its viability to specific use cases. However, these continue to diminish at a fast pace. Make sure to review this document and re-check your assumptions on each new project.
Traditional WordPress
This is the WordPress stack we use for the majority of our client projects. In a “traditional” environment, WordPress is responsible for both the CMS management (“backend”) and the user-facing website (“frontend”).
| Pros 1. It’s “tried and true” 2. Least amount of tech debt (relative) 3. Plugin ecosystems “just work” 4. Large pool of readily available WordPress developers | Cons 1. Poor DX versus “modern” alternatives 2. Limited UX opportunities 3. Relies on (WordPress flavored) PHP for both backend and frontend logic |
| When to use 1. For “standard” websites with basic interactivity needs. 2. When the development/maintenance team already knows traditional WordPress 3. When on a (relative) budget 4. When relying on 3rd-party plugins for frontend UX | When to avoid 1. When trying to build highly interactive, app-like experiences 2. When more control over the DX and tech stack is needed. 3. When you want to use the same data to power multiple platforms. |
Decoupled WordPress
This is a pattern used to consume and manipulate WordPress data using APIs. This can be used to additively enhance the UX/UI on a Traditional WordPress frontend, or use WordPress data in multiple contexts and even across multiple and inside 3rd-party applications.
ℹ️ Note
The Gutenberg Editor is a real-world example of a “decoupled” WordPress application, as are many of the modern @wordpress/* React and Javascript libraries, including the Interactivity API and the upcoming admin Data Views rewrite.
| Pros 1. Enables easy syndication of data from one or many WordPress sites. 2. Enables consumption of data from non-WordPress sources without needing WordPress. 3. Allows for limited app-like interactivity. 4. Frontend and backend can work independently – to a degree. 5. Existing WordPress developers may already be familiar with many decoupled concepts (see note just above this table) | Cons 1. Limited interactivity compared to Headless or fully modern SPAs. 2. Still dependent on WordPress’s core and PHP environment. 3. Potential for plugin conflicts and limitations when significantly extending functionality. 4.Maintaining strict API contracts is necessary to prevent unexpected issues. |
| When to use 1. For additive or isolated enhancements to traditional WordPress. 2. If you primarily need access to WordPress data, not design. 3. If you want to integrate data from other API’s in a friendlier DX. | When to avoid 1. When building highly interactive, app-like experiences. 2. When more control over the DX and tech stack is needed. 3. When you care about more than just WordPress data. |
Headless WordPress
This is where we use Decoupled patterns to ditch WordPress’s frontend entirely, in favor of a custom frontend, on a custom tech stack, on a custom server.
This provides the most flexibility to use WordPress as the backend CMS powering a specific client solution, but you still need to assess for yourself whether WordPress in this form is a better solution than other Headless CMSes for the particular project. See Clarifying questions & Common Scenarios.
| Pros 1. Use (and reuse) any frontend tech stack you like 2. Maximum flexibility and scalability 3. Modern development tools and workflows 4. Frontend and backend teams can work independently of each other 5. WordPress is a limited, isolated dependency most devs won’t need to know. | Cons 1. Higher initial investment and upkeep 2. Requires the skills and resources to manage separate backend and frontend tech stacks 3. Plugins and new WordPress features don’t always “just work” 4. API layer represents another level of tech debt |
| When to use 1. For complex interactivity, you can’t do in traditional WordPress 2. When the same content needs to be served across various platforms and devices 3. When your team prefers to work with modern frontend technologies. 4. When code longevity and reusability is part of the project’s ROI | When to avoid 1. If it’s a simple, content-focused website. 2. When the budget or timetable are limited 3. When the team doesn’t have the front-end experience to either develop or maintain it. 4. If relying on lots of 3rd-party plugins. |
ℹ️ Note:
While traditional and even decoupled architectures are generally well understood and have established patterns, best patterns around purely headless approaches are still emerging.
At rtCamp, we recommend taking an additive and composable approach to Headless WordPress by using WordPress as the default source of truth for frontend behavior. We’ve found that this approach mitigates many of the shortcomings with other approaches to Headless WordPress, and are solidifying these findings into the SnapWP framework:
> SnapWP treats WordPress as the full source of truth for all default site behavior. It does so by leveraging the modern Editor and Block Theme features to ensure that your WordPress-configured designs, global styles, Interactive Blocks, template hierarchy, and routing work right out of the box.
https://rtcamp.com/blog/snapwp-is-now-public/
Additional Considerations
There are numerous additional factors that will determine if Headless WordPress is a good fit for a project, and even influence how the project should be managed or what the deliverable should look like. The following are a few common considerations from projects.
Performance
Performance (on its own) is not a good justification for Headless. While the flexibility headless offers gives you more ways to address performance, in 2025 we are just as capable of building a fast and performant frontend on a traditional WordPress stack.
Security
A headless site is not inherently more secure, although here too it gives you the tech flexibility needed to implement custom strategies, and the separation of concerns provided by the API contract makes it straightforward to audit and prevent data leakage.
However, security through obscurity is never a valid strategy in its own right, and the unaudited frontend code is not likely to be more free from vulnerability than what sits in WordPress’s GitHub repo.
Additionally, securing headless applications and APIs require specific knowledge to do correctly – not harder but still different from what Traditional WP projects require and what available engineers may be familiar with.
Futureproofing / Feature-proofing
The ability to choose a frontend stack allows you to work around shortcomings in the existing WordPress codebase, as well as adapt and respond to changes – both technological and otherwise.
For example:
- The stack flexibility and separation of concerns allow developers to experiment with and ship features in their language of preference – i.e. faster and more reliably.
- This is particularly helpful to mitigate the risk and “instability factor” as user acquisition, behaviors, and monetization strategies shift in response to AI adoption and other new technologies.
- It also allows developers and teams to take advantage of whatever new and “disruptive” tooling to increase their productivity, before waiting for it to trickle down into first the PHP and then WordPress ecosystems.
- AI is a great illustration of this. It’s no secret that AI prefers strongly-typed languages, and non-(WordPress-flavored) PHP currently and will likely continue to provide a better experience and tooling ecosystem for developers for the foreseeable future.
- Additionally, isolated stacks (and the skills required to maintain them) can be swapped out with minimal conflicts, allowing organizations to avoid and reduce the risks of lock-in and swiftly adapt to changing business priorities.
- Even in the event of a full migration away from WordPress, the decoupled architecture increases the chances of being able to salvage and reuse those parts of the frontend, reducing project risk and increasing longevity / ROI.
- Further, decoupling frontend behavior doesn’t just allow us to solve existing gaps in functionality in core WordPress, it mitigates the risk of that “technical debt” growing over time. This strategy provides a path for risk-adverse clients or enterprises with legal requirements to use WordPress without worrying about changes to the Block Editor (Gutenberg), the Customizer, or other mission critical parts of the core software.
Clarifying questions
The following questions can be used to help steer the conversation and evaluate whether headless is a good fit for a particular client project.
- What specific features / UX/UI are needed beyond the traditional website?
- Who will be maintaining the site after initial delivery? What skills do they have?
- What WordPress plugins are essential from a CMS perspective?
- Is there an AI strategy?
- Are there any external data sources that need to be integrated with CMS data?
- What is the expected lifespan of the project deliverable?
- What other business applications does the client use (and their tech stacks).?
- What future plans are there for the project after it’s delivered.
- Are there any DX or deployment considerations?
- How are content managers expected to interact with the site (e.g. FSE?)
Common Scenarios
Based on the current state of the ecosystem, the following is a list of common scenarios when Headless is likely to be a good candidate.
ℹ️ Note
As rtCamp’s headless vertical continues to grow, this section will be updated to include links to real case studies, instead of hypothetical ones.
Web-apps
- Use Traditional with a basic “static converter” or PWA plugin, if you just want to take a basic blog “offline”.
- Use Decoupled if the app is restricted in scope and you primarily care about accessing (varying amounts of) WordPress data.
- Use Headless if the app is a full replacement for WordPress’s frontend, including routes and templates for posts, pages, taxonomy terms, etc.
User Dashboard / Account “Areas”
- Use Traditional if relying on basic functionality or a specific plugin solution.
- Use Decoupled to enhance traditional behavior with custom interactivity, or to integrate data from non-WordPress sources.
- Use Headless to provide a fully-customized experience (ideally supported by a “User need” or “brand goal”).
E-Commerce
- Use Traditional if relying on basic functionality that can be cached/scaled efficiently with traditional WordPress methods.
- Use Decoupled for improved interactivity such as autocomplete, advanced search/filtering, and to create “isolated” app-like experiences within traditional WordPress (cart, checkout, account management)
- Use Headless if more than just a “few” areas need to be Decoupled, or if you have a complex/fragile feature list or plugin stack that you need to be able to maintain without interfering with your frontend UX/UI.
Publishing Sites
- Use Traditional for basic “blogs” or “magazines” and other single-network sources, with low-complexity features and limited user-locked areas.
- Use Decoupled for creating isolated islands of interactivity, user-level cacheability, or when integrating external data into the UX/UI while bypassing WordPress, such as polls, graphs, carousels, live feeds, algorithmic recommendations, etc.
- Use Headless to experiment with highly custom and modern UX/UI while still using WordPress for your content managers, to unify codebases or brand identities across multiple (sub-)apps, to integrate multiple data sources (e.g. multisite/multitenancy) into a single app-like experience, or if you have a complex/fragile feature list or plugin stack that you need to be able to maintain without interfering with your frontend UX/UI
LMS
- Use Traditional for basic implementations that adhere to the standard features of the particular plugin stack.
- Use Decoupled to add basic interactivity sparingly and within the confines of the plugin’s limitations, or for isolated data use outside of the LMS.
- Use Headless if you want full or isolated control of the LMS’s UX/UI, while still making use of non-LMS WordPress data (either as as data or as the default design source of truth)
