Headless CMS vs. Traditional: Choosing a Stack for Marketing Sites
"Should we use a headless CMS?" is the single most common architectural question I get from marketing and product teams. The honest answer is: probably, but maybe not. Headless is a fantastic developer experience and a terrible editor experience if you get the setup wrong. Traditional CMSes like WordPress are the opposite — great for editors on day one, painful for developers by year two.
This post is the decision framework I actually use with clients. No brand loyalty, no Jamstack evangelism — just the questions that determine which side of the fence you should be on.
The four questions that decide it
Before comparing products, answer these four questions honestly. They predict the outcome better than any feature matrix:
- How often does content change? Daily blog posts and campaign pages are different from quarterly hero copy updates.
- Who edits the content? A dedicated content team with technical comfort is different from a single non-technical marketer who touches the site twice a month.
- How complex is the content model? A blog with posts and authors is simple. A multi-region marketing site with localized pricing, feature flags, and nested components is not.
- Is there a dev on staff? Headless requires ongoing developer involvement. Traditional CMSes often don't.
Headless vs traditional at a glance
| Axis | Headless (Sanity, Payload) | Traditional (WordPress) |
|---|---|---|
| Editor UX on day one | Requires setup and training | Familiar to most marketers |
| Developer experience | Excellent — typed schemas, Git workflow | Painful — PHP, plugin sprawl |
| Performance | Excellent — static or ISR | Variable — depends on hosting and plugins |
| Time to first deploy | 2–4 weeks | 1–2 weeks |
| Yearly hosting cost | $0–$500 | $200–$2000 |
| Plugin ecosystem | Limited but curated | Vast — and a security liability |
| Content flexibility | Whatever you model | Constrained by existing plugins |
When headless is actually worth it
- You have a marketing site that needs to feed content into multiple frontends — web, mobile app, kiosk
- You want a structured content model with strict typing, so every editor change is validated at the schema level
- Performance is non-negotiable — you need sub-second LCP globally and static generation is the cleanest path
- You have at least one developer maintaining the site long-term
- You're building something with a lot of custom components and reusable content blocks
When WordPress is still the right answer
- A single non-technical editor needs full control without a learning curve
- You need standard features — blog, contact form, newsletter, SEO — and have no appetite for custom development
- Budget is tight and the site is unlikely to scale beyond a few thousand visitors a day
- The content model is generic: pages, posts, categories, tags. Nothing fancy.
- You want a plugin ecosystem that handles 90% of what you need out of the box
“The worst CMS decision is the one made for the developer's convenience at the expense of the person who actually has to update content every week.”
My default recommendation in 2026
For clients with a developer on staff and a content model more complex than a plain blog: Payload CMS on the same Next.js deployment. You get typed schemas, a great editor experience, self-hosted data, and zero vendor lock-in. For clients without a developer, who just need a site they can update themselves: still WordPress, but with a curated theme and a maintenance contract. Don't pretend otherwise.
If you are in the middle of this decision and want a second opinion before committing — reach out. I have implemented both sides and can tell you within a 30-minute call which fits your situation.
Need help with your project?
Let’s talk about your technical requirements. I offer a free discovery call where we’ll discuss architecture, tech stack, and timeline.
View my services
