/handbook/headless-wordpress/rtcamps-philosophy/
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? rtCamp’s philosophy & principles
Topics
On this page
- When to go Headless?
- rtCamp’s philosophy & principles
- How to run a Headless discovery
- Key concepts & terms
Why do (so many) Headless WordPress projects fail?
How are we different?
Core Principles
1. Use Headless with purpose
2. Define clear sources of truths and responsibilities
3. Document everything
4. Be strict about Code Quality
5. Be consistent(ly opinionated) about standards and formatting
6. Automate your tooling and workflows
7. Reduce, reuse, recycle
8. Build strong feedback loops
SnapWP – “Headless WordPress” as a progressive enhancement
Last updated on Apr 1, 2026
rtCamp’s Philosophy & Principles
Headless WordPress is tough to get right.
In the right hands, it’s a powerful solution that can unlock user experiences, achieve business goals, and improve ROI in ways that surpass what can be achieved with traditional WordPress – and therefore the client’s competitors. Yet all too often, Headless WordPress projects end up the opposite: fragile codebases that are more expensive to run, develop, and maintain; lack the essential WordPress functionality; and likely don’t even adequately deliver on whatever business goals “justified” going headless in the first place.
This article provides an overview of rtCamp’s approach to Headless WordPress, covering both the “why”s and “how”s that allow us to consistently deliver successful headless projects while so many others struggle and fail.
Why do (so many) Headless WordPress projects fail?
The key to success at anything is the ability to learn from prior failures. By understanding where others have failed, we can avoid those pitfalls in our own work.
Below are common causes of failed headless WordPress projects:
- When the technology benefits aren’t aligned with specific client goals.
The most common reason for a failed headless project is that the project shouldn’t have adopted headless to begin with . As an expensive-to-implement, actively-evolving ecosystem, you should be able to explicitly justify how Headless WordPress provides is both a sustainable solution for a real-world problem and a better solution versus alternatives.
- When the project’s needs (and costs) are not accurately estimated.
While accurate scoping is important for all projects, the negative impacts of mis-estimation or poor planning are greater for Headless WordPress since solutions can be costly and complex. Hacky workarounds or short-sighted implementation are more likely to compound as tech debt and damage the long-term ROI of a headless project. These are easily exacerbated by external pressures like changing deadlines, missing resources, scope creep, cost overrun, or other project considerations that overincentivise cutting corners.
- When long-term maintenance/maintainability is not factored into the ROI
While similar to the previous point, this deserves a special call-out. The costs and complexities of maintaining Headless WordPress are not the same as traditional WordPress, and must be accounted for.
As during the initial development phase, we don’t want to eat into the budget of projects we maintain because we need to pay the price of a shallow spec or short-sighted engineering decisions. However, since a clear understanding of maintenance requirements factors directly into determining whether Headless is a good project fit, it’s just as important for the sites we hand-off entirely as those we will be maintaining.
- When the team(s) don’t have the adequate knowledge or skills.
It doesn’t matter how clarifying our discovery process is nor how good a match Headless WordPress is for a particular project if the people available to work on a project don’t have the skills to deliver on or maintain them.
- When the team(s) don’t standardize or iterate.
In the current Headless WordPress ecosystem, the hardest and most expensive part of any task is establishing and implementing the pattern the first time. The second hardest and most expensive part is attempting to fix that pattern when something upstream breaks compatibility.
Without a way to reuse our work, capture feedback, or iterate centrally, every part of every project remains high risk, high cost, and high barrier to entry.
How are we different?
rtCamp is uniquely positioned to address the above risks by recognizing and capitalizing on these strengths:
- Good People
We have access to the largest number of highly-skilled WordPress professionals in the ecosystem.
When faced with even the most complex of client problems, there’s usually at least one person at rtCamp who knows how to solve it. Even if there is only one rtCamper with the necessary skills, they only need to solve the problem once for the solution to be captured effectively for reuse.
- Good Work
We have experience with a diverse group of enterprise clients.
With clients working with us on both traditional and headless projects, we don’t need to blindly build solutions in search of a problem. Plus, we can leverage that work experience – ideas, research, and of course actual code- to scale and improve our deliverables on both new and existing projects.
Taken together, we have the ability to break ground and adopt new ecosystem patterns more quickly and efficiently than most teams, and can offset the costs by building for composability and reusability across all different kinds of projects.
By embracing these strengths, we’re uniquely positioned to be at the forefront of the Headless WordPress ecosystem and overcome the challenges that most others struggle with.
Core Principles
To ensure success on all our Headless WordPress projects, we adhere to a set of core principles derived from our collective experiences across numerous enterprise projects and teams. These principles are a mix of axiomatic truths and how we apply our specific strengths in response to them.
1. Use Headless with purpose
Given the current state of the ecosystem, Headless is never the “default” choice. It offers a way to achieve strategic UX/DX goals. However, those opportunities should be concrete and user-aligned.
Therefore, Discovery is the most important part of any potential Headless project. Only with a clear and thorough evaluation can we ensure that Headless WordPress is not just a good solution for a particular project, but the best solution from all possible options.
2. Define clear sources of truths and responsibilities
Headless is premised on the concept of “separation of concerns”, yet some headless sites can be just as – if not more- “coupled” as Traditional WordPress, albeit across potentially different sources of responsibility. We must be equipped to define and understand the various client and technological concerns, so we can make and implement ways to differentiate and manage them independently.
This is just as true when mapping out the site data and repository structures/ deployment strategies, as it is when mapping out the project teams themselves.
3. Document everything
You cannot remember what you’ve never learned. With so many new and unique patterns in Headless WordPress, we’re not just documenting for our future selves, we’re writing for developers, project managers, quality engineers, and others to make sure we continue to evolve, update and institutionalize our knowledge with every project.
There’s no L&D module for Headless WordPress (yet), there’s no official external guides or standardized playbook. There’s this Handbook, the project documentation you generate, and learnings we can glean and extract from those to fuel our feedback loops.
PS: Documentation isn’t just helpful for humans. Context and memory continue to offer the highest ROI on improving the output of current-gen AI models – and no amount of contextual prompting can compete with well-written, project-specific documentation.
ℹ️ Note
AI doesn’t just benefit from documentation – it makes it quick and easy to document code and summarize discussions and decisions. Clarity and conciseness are more important than creativity, so lean into tools like GitHub Copilot for doc-blocks and PR summaries, Google Meet autotranscripts for meeting notes, etc., – just make sure to validate the output of whatever is generated.
4. Be strict about Code Quality
Code Quality is important for all enterprise work, with linters providing guardrails to help ensure your developers – and with growing frequency LLM agents – are shipping quality code, while freeing up seniors to focus on reviewing the things that actually matter.
This is even more important in Headless WordPress – in particular type safety validation, as the ability to maintain separation of concerns rests on the ability to ensure the API contract between WordPress and the frontend remains intact. Typescript and PHPStan are essential tools here, as they can obviate the need for many types of testing and prevent problematic code from ever making it into the codebase.
While projects can start with lax rules and become stricter over time, it usually pays dividends to be as strict as possible from the outset, in terms of maintenance, upkeep, and bug resolution. The ROI here is usually immediately demonstrable during the internal/client-side QA in the form of a reduced number of edge cases or hard-to-replicate bugs, and especially stands out when new developers are introduced to (and need to maintain parts of) the codebase at any point of the project lifecycle.
ℹ️ Note
Here too, AI both benefits immensely and immediately from the improved context, and is very efficient at implementing those same code quality improvements. Whereas in the past the benefit of strict code quality was outweighed by the effort to implement on client projects, modern tooling, AI chatboxes, and autonomous agents make it easy to explain, implement and document, and fix usage violations around the strictest of types.
5. Be consistent(ly opinionated) about standards and formatting
While there are numerous benefits for adopting consistent coding standards on enterprise projects, when it comes to Headless WordPress there’s one reason that matters more than all of the others: It gives developers one less thing they need to adjust to.
When the same set of standards is used across projects it,
- Makes it easier for developers to navigate any codebase.
- Makes it faster for developers to write compliant code for a specific project.
- Makes it faster and easier for code to be reused across projects, and maintained even after long periods of time.
Broadly, rtCamp follows an opinionated adaption of WordPress Coding Standards geared for scalable enterprise projects. However, depending on the team developing or maintaining the project, it may make sense to adjust the the standards and formatting used, guided by the following principles:
- Reuse shared standards. By standardizing around – and then adhering to – patterns that those working on the project are familiar with, you reduce the time of onboarding new developers and the ease in reusing code across projects.
- Be opinionated about autofixable rules. Autofixable rules allow you to spend more time focusing on things that matter. Set these up once and run them on precommit, so developers don’t need to think about it.
- Be strategic about manual rules. While AI makes it easier to understand and remediate rules that cannot be autofixed, code guidelines should exist to aid the developer (or autonomous agent), not generate busywork.
ℹ️ Note
Standards don’t just apply to code, but should be adopted across other parts of the project. Spreadsheets following the same template, documentation living in the same location, GitHub Projects and Issues using the same fields and labels – are all ways to reduce friction and increase portability and ROI.
For more information on applying rtCamp’s recommended Coding Standards to your Headless WordPress projects, see 3.4 Development > Best Practices.
6. Automate your tooling and workflows
Tooling is what frees our minds – and our budgets – to focus on the important parts of a Headless WordPress, and automating that tooling is what frees our calendars.
ℹ️ Note
As of July 2025, rtCamp is still working to create reusable automated workflows, which may limit the options available depending on the host or deployment strategy chosen.
However, most automation scripts are reusable, so investment here can be captured to recoup the costs over future work.
Beyond enabling PR checking and pre-commit hooks to autocheck and fix the aforementioned Code Quality, Code Standard and formatting concerns, we also recommend implementing tooling and automated workflows for:
- Build and deployment for both the frontend and backend.
- API Schema testing against the latest version of environment dependencies (WordPress, PHP, Node, Plugin X, etc) alerts you of potential breaks before they ship to production.
- Visual regression testing is easy to scale and test, and offers the highest level of assurance, for common frontend routes.
- Performance-related reporting such as Lighthouse Scores and Bundle sizes, may help junior developers (or autonomous agents) work better on important enterprise projects that need to “scale”. However, depending on deployment strategy chosen and team composition this may not justify the CI/CD runtime costs.
- Outdated dependency notifications help keep tech-debt from piling up although caution should be taken before implementing auto-updating, as WordPress core and many plugins do not follow Semantic Versioning.
ℹ️ Note
The more tooling (automated or otherwise) used in a project, the safer it becomes to automate other tasks. This is as true for “traditional workflows” like auto-updating dependencies, as it is for AI where tools help ensure the autogenerated code is of higher quality.
7. Reduce, reuse, recycle
While engineers often talk about the benefits of DRY (Don’t Repeat Yourself) and SOLID in terms of development practices, the principles of isolated reusability are critical to all parts of a Headless WordPress project, and are what allow us to scale costs, push innovation, and lower barriers to entry.
- Adopt Composeable Architecture to help enforce your separation of concerns. By limiting the “contact points” between various parts of your code, tech stack, and workflows, you can maintain and fix, and even fully replace something isolated from everything else.
- Reuse rtCamp code libraries, skeletons, and reference other projects as prior art. Better yet, design your own projects to be reusable by other rtCampers, even if that’s just keeping your changes publicly documented in a way that makes it easier for others to backport those changes for you.
- Standardize across tech stacks. Unless there’s a clear and strong benefit to the client from deviating from various internal and external tech choices (plugins, libraries, 3rd-party APIs), choose solutions that we’ve previously used – ideally for Headless WordPress. That improves onboarding time for developers and makes it easy to scale the costs of development and maintenance across projects.
8. Build strong feedback loops
Literally nothing else in this document matters if we’re not explicitly feeding the work we do on individual projects back into the Headless WordPress vertical that we’re scaling. This means ensuring we take the time to:
- Backport code to the skeletons and libraries for reuse.
- File internal issues when we run into trouble, and update the documentation when we figure it out.
- Gather feedback from our teams, developers, and clients on what works and what needs fixing. Retrospectives with various stakeholders are a powerful tool, but informal feedback may be easier to gather, especially when working with conflict-averse clients and coworkers.
- Share your work – before, during, and after you work on it. This allows for potential code reuse and effort deduplication.
ℹ️ Note
On an ideal project, time should be allocated as part of every single task to consolidate learnings and contribute to the feedback loop. In reality when costs and resources are limited, smaller steps can be taken to capture value.
Even a quick message in #x-headless or short internal GitHub issue saying “We did X with Y over on Project Z” provides immeasurable value – at best it allows others to distill and backport that work, and at worst provides an important breadcrumb to help whoever is assigned to the next time-crunched project.
SnapWP – “Headless WordPress” as a progressive enhancement
SnapWP is a prescriptive and applied approach to the above core principles, distilling feedback from across our projects and ecosystem into a composable and reusable library following rtCamp’s best practices for Headless WordPress development.
More specifically, it uses WordPress’s Site Editor as the default source of truth for both data and design. This creates a form of “turn-key” headless WordPress, where a Block-theme powered website looks and behaves identically on traditional and headless WordPress with a minimal amount of boilerplate, and the only custom “headless” development needed are the isolated, project-specific UX/UI needs that justify choosing Headless in the first place.
ℹ️ Note
SnapWP is in early development, and will continue to mature as features are first implemented in client projects. In its current state, it serves as a great boilerplate for building out scalable and maintainable Headless WordPress projects and features, and contains helpful libraries that can be used individually, together, or as prior art for other experimentations.
To learn more about the motivations behind SnapWP, read the announcement post.
How to run a Headless discovery
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