We get this question in some form on nearly every new build. Should this be WordPress, or should it be headless? Usually it arrives already loaded with an assumption, because someone on the client's side read an article, or a competitor relaunched on a newer-looking platform, and now headless sounds like the modern answer and traditional WordPress sounds like the thing you graduate out of.
That framing is wrong on both ends. Headless isn't an upgrade from WordPress. It's a different way of building a website that solves different problems, and it comes with real costs a traditional setup doesn't carry. We've built both extensively, and the honest answer to "which one should we use" is almost always "it depends on what the site actually needs to do," which is a less exciting answer than a trend piece wants but a more useful one.
What "Headless" Actually Means
In a traditional website setup, the system your team publishes content in and the actual page a visitor sees are the same system. A headless setup separates those two things. Content lives in a dedicated content-management platform built specifically for this purpose, and a separately built visitor-facing site pulls that content in rather than displaying it directly.
That's not one specific product. Headless is a category of platforms built around the same idea, manage content in one place, deliver it anywhere, and Contentful is simply one option among several. The point isn't which platform gets chosen. It's that this whole category works fundamentally differently from an all-in-one system like WordPress, where content management and the visitor-facing site are the same thing.
That separation brings real advantages. Developers get much more freedom in how the actual site looks and behaves, since they're no longer boxed in by a theme. The same content can be pushed out to more than one place at once: a marketing site, a mobile app, a kiosk, a partner's website. Static, pre-built pages tend to load faster and hold up better under traffic than a site rendering every page live for every visitor.
None of that comes for free. A split setup like this means two systems to build and keep working together instead of one. It means updates take an extra step to go live, rather than appearing the moment someone hits publish. And it means whoever maintains the site needs ongoing front-end development support, not just a one-time build. Headless trades simplicity for flexibility, and that trade is only worth making when the flexibility is something the business actually needs.
Where WordPress Is the Right Call
Most of the sites we build stay on traditional WordPress, and that's not a default, it's a conclusion. WordPress is the right call when a single website is the only place the content needs to live, and the team managing it wants a straightforward publishing experience without extra technical layers sitting on top of every update. It's the right call when the site needs to keep growing and changing over time without a full rebuild, since WordPress makes it easy to add new functionality as needs shift. And it's the right call when long-term ownership matters, since a WordPress site isn't locked to whichever team happened to build the original setup.
There's a cost to headless that's easy to underestimate going in, too. When the way content is organized changes frequently, every change has to stay in sync on both sides of a headless setup. WordPress handles that kind of change more gracefully because there's only one system to update, not two. For content-heavy sites with publishing needs that keep evolving, that flexibility often matters more than any performance edge headless could theoretically offer.
Where Headless Is the Right Call
Headless makes sense in a narrower set of situations, and we're direct with clients about that because recommending it where it isn't warranted creates an ongoing burden that outlasts the initial excitement of a new build.
It earns its place when the same content needs to show up in more than one place at once. A marketing site, a mobile app, and a partner's site that all need to stay in sync from one source is exactly the situation a traditional website struggles with, and a headless setup built on a platform like Contentful solves cleanly.
It earns its place when performance needs go beyond what a standard website can reliably deliver. Pages built through a headless setup tend to load faster and hold up better under traffic spikes, since there's no plugin code or live server-side logic running on the public-facing site. That matters for security too:Patchstack's 2026 State of WordPress Security research found that the overwhelming majority of new WordPress security issues live in plugins, not in WordPress itself, exactly the kind of exposure a headless setup removes from the public-facing side.
It earns its place when the visitor-facing experience needs a level of design freedom or interactivity that no standard website theme can support cleanly, and there's a team in place with the front-end development skill to sustain that setup over time.
And it earns its place when a business manages a large number of similar properties that all share the same content or structure.
Twenty-Plus Microsites, One Content Source
Magnite, then known as Rubicon Project, came to us needing to manage a series of roughly twenty microsites that shared the same core content across different audiences. The initial assumption, both theirs and ours, was that each microsite would be its own WordPress build. That would have worked, but it also would have meant more than twenty separate WordPress sites, each needing its own updates, plugin management, security monitoring, and manual work every time the shared messaging changed.
Once we looked closer at the actual scope, we recommended a different approach. We built a headless setup that let content be written once and pushed out automatically to every microsite at the same time. What had been a manual, repetitive update process across twenty-plus individual sites became a single, centrally managed one. The result held up on every measure that mattered: more secure, since there were far fewer individual WordPress sites to defend; faster, since the pages were built for speed from the start; and dramatically less ongoing maintenance than running WordPress separately on each site would have demanded.
That project is the clearest version of the headless case we've built. We didn't choose it because headless is more modern. We chose it because the actual need, the same content showing up identically across more than twenty properties, was a problem headless solves well and a WordPress-per-site approach doesn't.
As we've put it internally more than once: when all you have is a hammer, everything looks like a nail. That's as true in building websites as it is anywhere else.
How We Actually Make the Call
The decision doesn't start with a platform preference. It starts with a handful of straightforward questions we walk through with every client before recommending an approach.
How many different places does this content actually need to show up? One website is a very different answer than a website, an app, and a partner's site.
What does the day-to-day publishing experience need to look like for the team managing content, and is there ongoing front-end development support in place to sustain a headless setup after launch, not just to build it?
How often does the way content is organized actually change? A site with a stable structure benefits far more from headless than one where the team is constantly reshaping how things are organized.
What are the real performance and scale needs, based on actual traffic, not assumptions about what "enterprise" is supposed to mean?
And does the business manage a set of similar properties that would benefit from being run off one shared content source, the way Magnite's microsites did?
We answer those questions honestly, even when the answer disappoints someone who came in already leaning toward the more exciting-sounding option. Our job isn't to sell a client on the trend. It's to build what will actually hold up for how their team works and how their content behaves three years from now, not just at launch.
The Bottom Line
WordPress and headless aren't competing on a spectrum from basic to advanced. They're different tools built for different kinds of problems. WordPress is the right call when a site needs a simple, durable publishing setup that can evolve without a rebuild. Headless is the right call when content needs to reach multiple destinations, hold up under real traffic, or stay in sync across a large number of similar properties. Most projects land clearly on one side once we've actually asked the questions. The ones that don't are usually the ones worth a longer conversation before we write any code.
If you're not sure which side your project falls on, that's where we'd start.
