DEV Community: Draftbase

Headless CMS vs traditional CMS — the honest version, including where WordPress still wins

Samer Alsayegh — Fri, 14 Aug 2026 14:00:00 +0000

Most "headless vs traditional" posts are written by headless vendors, so the scoreboard comes out 10–0. Here's the version with the losses included.

Where traditional actually wins

Turnkey SEO. Yoast and Rank Math bolt onto the rendering layer. Meta tags, sitemaps, schema, redirects — a settings panel, no code. A headless CMS ships none of that. You model metaTitle and metaDescription on the content type yourself, then render them into <head> from your app.

The editing loop. Change a heading, see it render, publish. No developer in the middle. Headless breaks that by design — content lives in a database, not on a rendered page, so "preview" means asking a frontend to fetch a draft and render it separately.

Setup cost. Someone builds a frontend. Someone picks SSR vs SSG vs ISR. Someone maintains a deploy pipeline. For a five-page site with one editor, that's more machinery than the job needs.

WordPress runs 41.9% of all websites (W3Techs). That number isn't an accident.

Where headless wins

Control, and channels. URL structure, schema markup, and redirect logic live in your code instead of a plugin's defaults. One entry feeds a website, a mobile app, and an email — each pulling only the fields it needs. Adding a second channel to WordPress usually means duplicating content or bolting on a REST layer the platform wasn't built to expose.

And "run WordPress headless" mostly inherits the worst of both: full hosting cost, minus the plugin ecosystem that justified WordPress in the first place.

The framing nobody uses

It stopped being a two-way choice. The MACH Alliance folded headless into a four-part standard — Microservices, API-first, Cloud-native, Headless.

So the real question isn't headless or not. It's how much of MACH do you actually need. One React site talking to one content API needs the API-first piece and the headless piece. Not microservices. Not a cloud-native commerce engine.

Full post covers the SEO tradeoff in detail, the React fit, and the cost math:

Headless CMS vs Traditional CMS: React, SEO, and When Each Wins →

We build Draftbase for exactly that slice — MDX over REST and GraphQL, links and media resolved inline, drafts readable through the same API. Hobby free, Startup $49/mo.

A static Astro site + a headless CMS is three moving parts (and one thing every tutorial skips)

Samer Alsayegh — Wed, 12 Aug 2026 14:00:00 +0000

Fetch at build. One route per entry. Webhook that rebuilds on publish. That's the whole integration — Astro does the first two natively, so most of the work is wiring.

The fetch goes in the frontmatter script, which runs on the server at build time:

---
const res = await fetch('https://api.draftbase.co/delivery/entries?templateId=blogPost', {
  headers: { Authorization: `Bearer ${import.meta.env.DRAFTBASE_KEY}` },
});
const { items } = await res.json();
---

No key in the bundle. No API call from the browser. No loading spinner.

A page per entry is src/pages/blog/[slug].astro plus getStaticPaths, returning params for the URL and props so the page doesn't fetch the same entry twice.

The part every tutorial skips

Delivery APIs serve published content only. Your build literally cannot see a draft. So editors have no preview, and you find that out the day after launch.

Two workable fixes:

On-demand preview route. Add an adapter, set export const prerender = false on one route, read drafts from the management API with a server-side token. The rest of the site stays static.
Preview deploy. A branch that pulls drafts too. Simpler to reason about, costs an extra build.

First one if editors preview constantly. Second one if it's occasional. Either way the management token stays server-side — it can write.

Four things that break in production

Silent truncation. Delivery APIs cap page size. Nobody follows the cursor. Site looks fine at 40 entries, drops posts at 101.
Stale pages after a delete. Webhook fires on publish only, so a removed post keeps its page until some unrelated deploy.
Images served from the CMS origin. Undoes the whole CDN benefit.
A broken build takes the site down. Confirm your host keeps the last good deploy live.

Full guide has the code for each step, the MDX rendering choice (compile at build vs. client island), and Astro-vs-Next.js for CMS-backed sites:

How to Build a Static Astro Site with a Headless CMS →

Samples use Draftbase — our headless CMS. Rich text is plain MDX, which Astro renders natively, so there's no converter to maintain. Hobby free, Startup $49/mo.

Jamstack didn't die. It won so hard nobody says the word anymore.

Samer Alsayegh — Mon, 10 Aug 2026 14:12:18 +0000

Netlify pulled "Jamstack" off its own homepage in October 2023. The community Discord closed. The State of Jamstack survey, running since 2020, ended.

Easy read: the architecture failed.

Wrong read. Pre-rendering, API-first content, edge delivery, decoupled front ends — those all ship as defaults now in Next.js, Astro, Nuxt, and SvelteKit. Nobody needs a name for the normal thing.

The part that actually changed

The original Jamstack answer to dynamic content was "fetch it in the browser after load." That still works for a view counter. It ages badly everywhere else — client fetches hurt LCP, and crawlers see an empty slot.

So the current shape is three tiers, not two:

Tier	Runs at	Good for
Pre-rendered	Build time	Posts, docs, marketing pages
On-demand render	Request time	Search results, per-user pages
Client fetch	After load	Counters, badges, live widgets

Put each piece of content in the cheapest tier that meets its freshness need. That one rule replaces most 2019-era Jamstack advice.

What it means when you pick tools

Stop filtering on the label. Judge the traits:

Does it pre-render?
Does it serve from an edge?
Does content arrive over an API?

Same test applies to your CMS, and it rules out more of them than you'd expect. A build step can't call a browser-only SDK. Three things to check:

A plain HTTP API with a server-side key
Webhooks on publish, so builds trigger themselves
A portable content format, not a vendor-specific tree

That last one is the expensive one to get wrong. A proprietary rich-text tree means writing a converter, then rewriting it when the front end changes.

The full write-up covers how a page moves through the whole chain, why Netlify moved to "composable," and the arithmetic for deciding if static fits at all:

Static Site Architecture and the Jamstack, Explained →

We build Draftbase, a headless CMS that stores rich text as plain MDX and serves it over cached REST and GraphQL. Hobby is free, and easy to start with our templates.