Choosing a CMS for a content-led website
Why we default clients to headless CMS platforms over hard-coded marketing pages.
April 21, 2026 · Zovelum Team
When a client asks us to build a content-led website — a marketing site, a blog, a documentation hub — one of the first decisions we make together is where the content lives. The answer shapes the editor experience, the developer experience, and the long-term maintenance burden. We almost always recommend a headless CMS over hard-coded content or a traditional monolithic CMS.
What "headless" actually means
A traditional CMS (WordPress, Drupal) bundles content storage, editing UI, and rendering into a single system. The CMS decides how your content looks on the page. A headless CMS separates the content repository from the presentation layer. Your content is stored and edited in the CMS; a separate frontend (Next.js, Astro, whatever you choose) fetches it via API and renders it exactly as you design.
"A headless CMS lets your editors own the content and your engineers own the presentation. Neither has to compromise."
The practical implication: the design is not constrained by CMS templates, the frontend stack is not locked to PHP, and the content can be reused across web, mobile, and any other channel that can make an API call.
When we recommend headless
Headless is the right default when any of these are true:
- The site is built on a modern framework (Next.js, Remix, Astro, SvelteKit)
- Non-technical editors need to update content without a developer deploy
- The same content needs to appear across web and mobile (or other channels)
- The design is custom — not a theme purchased from a marketplace
- You expect significant traffic and want to serve a statically generated site from a CDN
- The team plans to grow content volume significantly over the next 12 months
Platform comparison
We have built with most of the major headless CMS platforms. Here is our honest assessment of the main contenders as of 2026:
| Platform | Best for | Pricing model | Self-hosted? | Dev experience |
|---|---|---|---|---|
| Sanity | Marketing sites, structured content with complex relationships | Free tier; paid per project + seat | No (cloud-hosted studio + API) | Excellent — GROQ, typed schemas, real-time |
| Contentful | Enterprise teams needing strong governance and workflows | Free tier; enterprise contracts from ~$500/mo | No | Good — mature REST + GraphQL APIs |
| Strapi | Teams that want full control and self-hosting | Open-source (self-host free); cloud plans available | Yes | Good — requires more configuration |
| WordPress (headless) | Teams with existing WP investment or non-technical editors | Free (self-host) or managed WP hosting | Yes | Adequate — REST API and WPGraphQL work, but legacy overhead |
Our current default is Sanity. The typed schema system, real-time collaborative editing, GROQ query language, and generous free tier make it the best fit for the kinds of sites we build most often. For clients with strong self-hosting requirements or existing WordPress infrastructure, we adjust accordingly.
The decision framework
How to choose
Non-technical editors + custom design: Sanity or Contentful.
Full data ownership + self-hosting required: Strapi or headless WordPress.
Existing WordPress investment: Add WPGraphQL and build a Next.js frontend on top.
Simple blog, one developer: MDX files in the repo — no CMS at all.
When NOT to use a headless CMS
Headless is not always the right answer. Skip it when:
- The site is genuinely simple — a brochure with five pages that change twice a year
- The team has no developer capacity and needs an all-in-one solution
- Budget is very tight — a managed WordPress installation is cheaper to run than a headless stack
- The content model is just blog posts with no relationships — MDX files in a Git repo are simpler and free
Headless CMS introduces real operational complexity: you manage two systems (CMS + frontend), two deployments, and two cost centres. That overhead is worth it at scale and is genuinely unnecessary for a three-page site.
Questions we get asked
Can non-technical editors really use Sanity?+
Yes, reliably. We invest in a short onboarding session (usually 45 minutes) and a simple internal reference card. The Sanity Studio UI is clean enough that most editors are comfortable within a day. The key is designing your content schema to match how editors think about their content, not how developers think about data.
What happens to our content if we want to switch CMS later?+
All the major headless platforms offer JSON export. The migration work is in transforming your content to the new schema — not in extracting it. We document content models thoroughly during the build so that migration is a manageable exercise rather than archaeology.
Do you recommend Sanity for every project?+
No. Sanity is our current default because it fits the majority of the projects we work on. For a client with an established Contentful account and trained editors, switching would create unnecessary friction. For a project requiring on-premise data storage, Strapi is the right call. We evaluate each project on its constraints.