/handbook/headless-wordpress/
What We Do
Digital Platform MigrationsKey SolutionsManaged ServicesStaffing SolutionsIndustriesProducts
Discovery
Strategic consultancy & project roadmap
Growth Services
On demand development & consultation
Site Maintenance
Annual maintenance. Done for you
QE Services
Testing across SDLC for assured quality
Hosting Migration
Move to a performant hosting with zero downtime
WooCommerce
Enterprise commerce delivered without lock-in
AI
Unlock real use cases and integrations
All Services
A suite of services for any need
Technology STACK
eCommerce
Scale your e-commerce with WooCommerce, integrations, and custom extensions for growth.
EasyEngine
Server management tool that makes using WordPress on Nginx easy.
Web Auditor
Performance Audit & Insights for your Website.
rtMedia
A complete media management plugin for WordPress.
Resources
About Us
CLEAR
Resources When to go Headless?
Topics
On this page
- When to go Headless?
- rtCamp’s philosophy & principles
- How to run a Headless discovery
- Key concepts & terms
Traditional WordPress
Decoupled WordPress
Headless WordPress
Additional Considerations
Performance
Security
Futureproofing / Feature-proofing
Clarifying questions
Common Scenarios
Web-apps
User Dashboard / Account “Areas"
E-Commerce
Publishing Sites
LMS
Learn more
Last updated on Apr 1, 2026
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 developersCons
1. Poor DX versus “modern” alternatives
2. Limited UX opportunities
3. Relies on (WordPress flavored) PHP for both backend and frontend logicWhen 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 UXWhen 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 debtWhen 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 ROIWhen 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://e71a1d5d-e22b-4c34-a1b4-1f6cae4bcd26.atarimworker.io/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)
Learn more
rtCamp’s philosophy & principles
NEXT
Credits
David Levine
Author
David Levine
Author
David Levine is a Senior WordPress Engineer and Product Lead at rtCamp with a background that few engineers in the WordPress space can claim. A WordPress Core Contributor across multiple releas…
Good Work. Good People.
Industry partnerships
Compliance certifications
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Company
Solutions
Subscribe to our newsletter and get a few email updates every month.
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Cookie Consent
We value your privacy
We use cookies to give you the best possible experience. By clicking “Accept,” you consent to our use of cookies to improve site functionality, analyze usage, and personalize content and communications. Your privacy matters to us, and we are committed to handling your data responsibly and transparently. Please check our Privacy Policy for more details.
Manage PreferencesDon’t AllowAllow All
Why do we use cookies?
×
By clicking "Accept" or "Decline All" at the bottom, you consent to the use of cookies and other tools as described in our Cookie Policy in accordance with your settings and accept our Terms of Service.
Toggle EssentialEssential
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Geolocation Config
This cookie is used to store the consent settings based on the visitor's location.
30 days
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
Toggle CloudFlareCloudFlare
CloudFlare provides web performance and security solutions, enhancing site speed and protecting against threats.
Service URL: developers.cloudflare.com (opens in a new window)
Name
Description
Duration
cf_clearance
Whether a CAPTCHA or Javascript challenge has been solved.
session
Toggle CommentsComments
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author
Used to track the user across multiple sessions.
Session
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author_url
Used to track the user across multiple sessions.
Session
Toggle GodamGodam
GoDAM" is primarily a specialized WordPress plugin and media management service designed to enhance video hosting, marketing, and asset management directly within the WordPress dashboard.
Service URL: godam.io (opens in a new window)
Name
Description
Duration
user_image
Temporarily stores the path to the user's avatar or profile picture for quick rendering in the website header.
session
user_id
Stores the numerical ID of the logged-in user to maintain session continuity and basic site operations.
session
full_name
Stores the logged-in user's display name to personalize the site interface without needing database queries.
session
system_user
First-party cookie used to store basic application state identifying the current system user role.
session
sid
A generic session ID cookie used to maintain user state and functionality as the visitor navigates through the site.
session
Toggle Google reCAPTCHAGoogle reCAPTCHA
Google reCAPTCHA helps protect websites from spam and abuse by verifying user interactions through challenges.
Name
Description
Duration
_GRECAPTCHA
Google reCAPTCHA sets a necessary cookie (_GRECAPTCHA) when executed for the purpose of providing its risk analysis.
179 days
Toggle Google Tag ManagerGoogle Tag Manager
Google Tag Manager simplifies the management of marketing tags on your website without code changes.
Name
Description
Duration
cookiePreferences
Registers cookie preferences of a user
2 years
td
Registers statistical data on users' behaviour on the website. Used for internal analytics by the website operator.
session
Toggle StatisticsStatistics
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Toggle Factors AIFactors AI
Factors.ai is a B2B account intelligence and marketing analytics platform that helps Go-To-Market (GTM) teams identify anonymous website visitors, track buyer journeys, and measure the ROI of marketing campaigns.
Service URL: www.factors.ai (opens in a new window)
Name
Description
Duration
_fuid
It is sent to capture session details and track user behavior across your website to provide behavioral data and intent signals.
1 Year
Toggle Google AnalyticsGoogle Analytics
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Service URL: policies.google.com (opens in a new window)
Name
Description
Duration
FPGSID
Stores a session or user identifier to track how visitors interact with a website. This helps Google Analytics measure website performance, user engagement, and usage patterns.
Session
FPLC
Used by Google Analytics to link visitor interactions and sessions across multiple related domains.
20 hours
FPID
A server-side Google Analytics cookie used as an alternative user identifier when third-party cookies are restricted.
2 years
_ga
ID used to identify users
2 years
_ga_
ID used to identify users
2 years
Toggle Jetpack StatsJetpack Stats
Jetpack's built-in visitor analytics. It records page views, referring sites, search terms, and outbound link clicks, and also carries the shared visitor-tracking library used by Jetpack Instant Search and WooCommerce Analytics.
Service URL: automattic.com (opens in a new window)
Name
Description
Duration
tk_aip
Stores a list of anonymous visitor IDs so they can be merged into one identity once a visitor is recognized.
Up to 5 years
tk_tc
Used once per page load to work out which cookie domain the Tracks library should use, then removed as soon as it's read back.
Session (deleted immediately after use)
tk_qs
Queues analytics events for Jetpack's Tracks library so none are lost if the page closes before they can be sent.
30 minutes
tk_ai
Stores a randomly-generated anonymous visitor ID so Jetpack's Tracks analytics library can link tracking events to the same visitor.
Session in wp-admin; up to 5 years on the frontend
Toggle Microsoft ClarityMicrosoft Clarity
Clarity is a web analytics service that tracks and reports website traffic.
Service URL: clarity.microsoft.com (opens in a new window)
Name
Description
Duration
CLID
Identifies the first-time Clarity saw this user on any site using Clarity.
12 months
ANONCHK
Indicates whether MUID is transferred to ANID, a cookie used for advertising. Clarity doesn't use ANID and so this is always set to 0.
Session
_clck
Persists the Clarity User ID and preferences, unique to that site is attributed to the same user ID.
12 months
_clsk
Connects multiple page views by a user into a single Clarity session recording.
12 months
Toggle Parse.lyParse.ly
Parse.ly is a content analytics platform that helps publishers optimize audience engagement and content performance.
Name
Description
Duration
cookies.js_dtest
This cookie determines whether the browser accepts cookies.
session
_parsely_session
JSON document storing information identifying a browsing session according to Parsely’s proprietary definition
30 minutes
_parsely_visitor
JSON document uniquely identifying a browser and counting its sessions
13 months
Toggle SalespanelSalespanel
Salespanel is a B2B marketing and sales software that identifies, tracks, and qualifies website visitors and leads in real-time using first-party data. It helps businesses monitor customer journeys, score leads based on behavior, and syncs this data with CRMs (like Pipedrive or HubSpot) to improve conversion rates.
Service URL: salespanel.io (opens in a new window)
Name
Description
Duration
track_uid
Identify and tracking a lead
12 moths
Toggle MarketingMarketing
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
Toggle Bing / MicrosoftBing / Microsoft
Bing, powered by Microsoft, is a search engine providing web, image, video, and map search capabilities.
Name
Description
Duration
MR
Used to collect information for analytics purposes.
6 months
ANONCHK
Used to store session ID for a users session to ensure that clicks from adverts on the Bing search engine are verified for reporting purposes and for personalisation
10 minutes
SM
Used by Microsoft in synchronizing the MUID across multiple Microsoft domains to track users for advertising.
session
MUID
Identifies unique web browsers visiting Microsoft sites. These cookies are used for advertising, site analytics, and other operational purposes.
1 year
Toggle DoubleClick/Google MarketingDoubleClick/Google Marketing
A comprehensive digital advertising platform for managing campaigns, optimizing performance, and analyzing audience data.
Name
Description
Duration
IDE
This cookie is used for targeting, analyzing and optimisation of ad campaigns in DoubleClick/Google Marketing Suite
2 years
ar_debug
Store and track conversions
Persistent
Toggle LinkedInLinkedIn
LinkedIn is a professional networking platform for job seekers, employers, and industry connections.
Name
Description
Duration
bscookie
Used by LinkedIn to track the use of embedded services.
1 year
AnalyticsSyncHistory
Used to store information about the time a sync with the lms_analytics cookie took place for users in the Designated Countries
30 days
bcookie
Used by LinkedIn to track the use of embedded services.
1 year
li_sugr
Used to make a probabilistic match of a user's identity outside the Designated Countries
90 days
lidc
Used by the social networking service, LinkedIn, for tracking the use of embedded services.
1 day
UserMatchHistory
Used by LinkedIn Ads to synchronize and match user IDs across different ad networks and data providers.
30 days
Toggle LinkedIn InsightLinkedIn Insight
LinkedIn Insight is a web analytics service that tracks and reports website traffic.
Service URL: www.linkedin.com (opens in a new window)
Name
Description
Duration
li_sugr
Used to make a probabilistic match of a user's identity.
90 days
lidc
Used for routing and session management.
24 hours
Toggle LiveIntentLiveIntent
LiveIntent provides a platform for email advertising and identity-driven marketing solutions.
Name
Description
Duration
_lc2_fpi_js
Companion cookie to _lc2_fpi used by JavaScript to facilitate cross-domain ad tracking and user identification.
1 year
_lc2_fpi
First-party tracking cookie usually associated with LiveRamp to identify users across devices for targeted advertising.
1 Year
_li_ss
Sets a unique ID for the visitor, that allows third party advertisers to target the visitor with relevant advertisement. This pairing service is provided by third party advertisement hubs, which facilitates real-time bidding for advertisers.
1 month
lidid
Collects data on visitors' behaviour and interaction - This is used to make advertisement on the website more relevant. The cookie also allows the website to detect any referrals from other websites.
2 years
Toggle Cookie PolicyCookie Policy
You can find more information in our Privacy Policy.
Allow AllDecline All
Accept