Platform Guide
Headless vs WordPress: a head-to-head.
Both are CMSes. Both let you own your content. Both have been used to build great sites. The real differences matter, but they are rarely as one-sided as the loudest voice in the room makes them sound. Here is how the two stack up.
A note on bias.
We build on both. Our default for new projects is headless, and you will feel that lean throughout this page. We will flag where headless has real trade-offs and where WordPress is the smarter call. Read this with the right calibration: a balanced comparison, not a sales pitch dressed as one.
Looking at site builders too (Wix, Squarespace, Shopify)? Start with our broader four-platform overview.
How each architecture works.
The fundamental difference is where the pieces live and how your content gets to a visitor.
WordPress
Content, code, plugins, and database all live on the same server. Every page is generated on request from the database. Everything has one address: your site's URL.
Headless
Content lives in a dedicated CMS. Code lives in a separate repo. A build step turns both into pre-built HTML that gets served from a CDN. Three jobs, three tools, joined by an API.
A static site (no CMS, just hand-written HTML) is a third option that comes up in this conversation. We covered it in our broader platform overview because it solves a different problem than either of these.
Side-by-side comparison.
Same job, two different stacks. Where each lands on the things people care about.
| WordPress | Headless | |
|---|---|---|
| Performance | Good with caching and good hosting. Slow without. | Near-static speeds out of the box. |
| Security surface | Largest of any CMS - public login, DB on every page request, plugin variability. | Smaller - no public login on the site itself, no DB attached to the public pages. |
| Content editing | Visual editor with drag-and-drop layout (with a page builder like Bricks). | Form-based editor in Sanity Studio. See the editing workflow → |
| Plugin / package ecosystem | 60,000+ WordPress plugins. Mature ecosystem for niche needs. | npm (100k+ packages) plus the Astro and Sanity ecosystems. |
| Code transparency | Many commercial plugins are closed-source or obfuscated. Core and ecosystem are open. | Every line in your repo is yours to read and audit. Dependencies are open source by default. |
| Hosting cost | $20-100+/mo for managed WordPress hosting. | Free to low (static hosting on Vercel + Sanity free tier covers most sites). |
| Editor seat cost | Unlimited editors at no platform cost. | Free up to 3 users on Sanity, then ~$15/user/month. Adds up at scale. |
| 3-year total cost | Higher recurring (hosting, plugins, retainer) but lower initial build. | Lower recurring (hosting often free) but higher initial build. See the full TCO breakdown → |
| Scaling under traffic | Requires server upgrades or aggressive caching layers. | CDN handles traffic spikes natively. |
| SEO | Strong with the right plugins (Yoast, RankMath) and good hosting. | Strong by default - clean HTML, fast pages, structured data baked in. |
| Talent pool | Enormous. Easy to find a developer anywhere in the world. | Smaller but growing. Modern JS frameworks are common in mid-to-senior pools. |
| Initial build cost | Lower for standard needs - WordPress handles a lot out of the box. | Higher upfront - schemas, components, and front-end are all custom. |
| Best fit | Content-heavy sites with non-technical editors who want visual layout control, or projects that need a specific WP plugin. | Performance-critical or compliance-heavy sites, complex content models, projects building for the long term. |
Coupled vs decoupled: an architectural difference.
The biggest structural difference between the two is whether the parts of your site live together or apart. There are real arguments on both sides.
WordPress: everything is together
Content, code, plugins, and database all live on the same server. One login. One backup. One vendor. For a team that wants a single dashboard for the entire site, that is genuinely simpler to administer.
The trade is that a vulnerability in any one piece (a plugin, a theme, the login page) can affect the whole site. Plugin updates can break the theme. PHP version bumps can break plugins. The pieces are coupled, so they have to move together.
Headless: everything is separated
Content lives in Sanity. Code lives in your repo. The public site is pre-built HTML on a CDN with no DB attached. Each piece does one job, has its own update cycle, and has its own security model. A breach in one does not expose the others.
The trade is more pieces to keep track of. You have a CMS account, a repo, a build pipeline, and a host - four bills, four logins, four sets of credentials. We hide most of that from clients, but the architecture is genuinely more distributed than a WordPress install.
Where WordPress is genuinely the right call.
It is the most-used CMS in the world for reasons. Here is where it wins and we will tell a client to stay on it.
Visual layout editing
WordPress with a page builder gives non-technical users a true drag-and-drop editing experience. If your team needs to make complex layout changes without a developer in the loop, WordPress is hard to beat. Sanity gives you form-based editing with pre-approved layouts, which is structured by design - powerful, but a different mental model.
Plugin marketplace depth
Booking systems, LMS, ecommerce, membership management, niche directories. WordPress has a mature plugin for almost every common business need. For specialized functionality, the cost of using a battle-tested plugin is usually far less than building from scratch on a headless stack.
Lower initial build cost
Because WordPress handles user management, media library, routing, and admin UI out of the box, the initial build is typically less expensive than a comparable headless project. For straightforward sites with standard needs, the price difference is real and worth weighing.
Massive talent pool
If you ever need to switch developers, finding someone who knows WordPress is trivial. The ecosystem is enormous. With headless, you need someone who understands modern JavaScript frameworks - a smaller talent pool, though it is growing fast.
Single source of truth
WordPress lets a team own the entire site infrastructure in one place. One dashboard, one login, one host, one bill. For a team that values administrative simplicity (small admin pool, no dedicated dev contact, no appetite for managing multiple vendors), the cognitive overhead of a single platform is a real benefit. Headless distributes those responsibilities across a CMS account, a code repo, a build pipeline, and a host.
No per-seat editor pricing
WordPress lets you add unlimited editors and contributors at no platform cost. Sanity (our default headless CMS) is free up to three users on the standard plan, then $15 per editor seat per month after that. For a department with twenty content editors across teams, the seat math meaningfully favors WordPress over time. We will run the numbers with you if scale is a question.
Where headless is genuinely the right call.
Same treatment, the other direction. Where the architectural choice pays for itself.
Performance ceiling
Pre-built HTML on a CDN is the fastest a website can serve. There is no PHP roundtrip, no database query, no plugin chain on every request. For sites where Core Web Vitals are an SEO factor or where global load time affects conversion, the ceiling is meaningfully higher than well-tuned WordPress.
Smaller security surface
The public side of a headless site has no login, no admin panel, no database. There is nothing on it to hack. The CMS is hosted by a vendor whose entire job is keeping it secure (Sanity, in our case). For organizations with compliance requirements, this is a genuine advantage.
Code transparency and ownership
Every line of code that runs your site lives in your repository. You can read it, audit it, fork it, or hand it to any developer in the world. There are no obfuscated commercial plugins running on your server. Dependencies come from npm and are open by default.
AI-friendly architecture
A clean codebase reads, refactors, and extends well with AI assistance. A page builder's state lives half in a database and half in a GUI - much harder for AI to reason about. As AI-assisted development becomes the norm, code-first architectures are where the productivity gains compound.
How to choose.
Skip the marketing language. Answer these honestly and one will be obviously right.
Choose WordPress if…
- Your team needs true visual drag-and-drop editing across complex layouts
- You need ecommerce, LMS, membership, or another major plugin out of the box
- Your budget is moderate and your needs are standard
- Finding replacement developers anywhere is a top priority
- You publish content constantly and your writers know the WP editor flow already
- You have a large editor headcount and per-seat CMS pricing would compound over time
- You value administrative simplicity - one dashboard, one login, one bill
Choose headless if…
- Performance and Core Web Vitals are critical to your business
- Security or compliance review is part of your operating reality
- You have complex content relationships (directories, taxonomies, cross-references)
- You want full code ownership and no plugin lock-in
- You are building for the long term and expect the site to grow into more than a brochure
- Your team values structured editing with pre-approved layouts over free-form drag-and-drop
Our default and when we deviate.
We build on both. Our default for new projects is headless because most of our clients prioritize performance, ownership, and a clean codebase that scales with their team over time.
We deviate when WordPress is the better fit. That happens when an existing plugin solves a hard business problem that would take months to rebuild custom (LMS platforms, membership systems, certain ecommerce flavors). It happens when a team has deep WordPress muscle memory and the cost of retraining outweighs the gains. It happens when the project is publication-heavy and the visual editing flow matters more than the architectural ceiling.
We are not religious about either one. We are religious about the project being right for the business, which sometimes means telling a client to stay on the platform they already have rather than rebuild for the sake of it.
For a deeper look at how content actually gets edited on a headless build (the part most prospects worry about), see our content editing workflow.