JekCMS vs Headless CMS: An Honest Decision Framework

Let me put my bias on the table first: I wrote jekcms, and I run my own network of 14 content sites on it. Everything below comes from that seat. Discount accordingly — but in return, I'll tell you exactly where I would not recommend my own product, which is more than most CMS comparison posts are willing to do.

Where headless genuinely wins

Two scenarios, and both are real.

First: multi-channel content. If the same article has to appear on your website, inside a native mobile app, on in-store screens, and in a partner's product via API, then "content as an API" is not a fashion statement — it's the correct architecture. A coupled CMS renders HTML; asking it to also feed an iOS app is possible but ugly. Headless was invented for exactly this, and it does it well.

Second: a real frontend team. If you employ several engineers whose entire job is a React or Vue application — their own release cadence, their own tests, their own component library — forcing them through server-rendered PHP templates wastes the very skill you're paying for. Treat content as a data source and let them build the frontend they're good at. At that scale, the operational cost of running two systems is absorbed by the fact that you have a team to run them.

If you recognized your situation in either paragraph, stop reading and go pick a headless CMS. The rest of this post is not for you, and I'd rather lose you honestly here than win you over with a rigged checklist.

What most publishing actually looks like

Here's the part conference talks skip: the bulk of content operations is one or two people publishing HTML pages to the open web. A blog. A documentation site. A company site with a news section. There is no iOS app. There is no frontend team — there's you, and maybe a colleague.

I'm an extreme version of that case: 14 live sites, over 5,500 posts across the fleet, the largest single site above 2,300 posts. One person. The whole thing runs on shared LiteSpeed hosting behind Cloudflare. That constraint — one operator, ordinary hosting — is precisely where the coupled monolith stops being "legacy architecture" and starts being a competitive advantage.

It helps that the rendering layer is part of the product. jekcms ships with 13 finished themes plus a starter skeleton and serves TR and EN from a single codebase, so my hours go into posts, not into rebuilding a frontend. On a headless stack, that layer is yours to build — and yours to maintain forever.

Publishing without a build pipeline

On a headless-plus-static stack, "publish" means: save in the CMS, hope the webhook fires, wait for the build or revalidation, wait for the CDN. When it works, that's a couple of minutes of latency and one more system that can fail silently. When it doesn't — the webhook didn't fire, the build broke on an unrelated commit — your editor is staring at stale content with no idea which of four dashboards to open.

In jekcms, publish means the row is in the database and the next request renders it. The page cache in front has a 300-second TTL and gets purged on publish anyway. Scheduled posts don't even need cron: the scheduler piggybacks on normal traffic, runs after the response has already been delivered to the visitor, and is deterministic — the post goes live at its timestamp, not "whenever the next build happens to run." I wrote up how that works internally.

When you publish across 14 sites, this difference is not academic. It's the difference between publishing being a background action and publishing being a deployment event.

The hosting bill

My entire fleet lives on shared hosting. Not a Kubernetes cluster, not even a VPS — shared LiteSpeed hosting, with Cloudflare doing the edge work for free. The headless equivalent of the same fleet means a hosted CMS subscription (per seat, per space, per record — pick your pricing axis), plus a frontend host per site, plus the glue between them. I won't quote competitor prices because they change; the structural point doesn't: a monolith has one bill, and it's the cheap kind.

Who fixes it at 2 a.m.?

Every system I add is a system I personally debug, because there is nobody else. With a coupled CMS the failure surface is PHP, MySQL, and the host. That's it. I know all three.

Let me be fair, though — monoliths have their own sharp edges, and I've hit them. My code deploys go out through GitHub Actions and rsync, and at one point Hostinger started banning my IP because parallel rsync jobs were hammering SSH auth; the fix was SSH ControlMaster, so every transfer shares a single authenticated socket. Deployment pain exists everywhere. The difference is that in a coupled setup, that pain applies to code deploys only. Content never touches that pipeline.

SEO lives in one codebase — or in two

Here's an argument I rarely see in headless debates: technical SEO is code, and that code has to live somewhere. Two bugs from my own fleet make the point.

For a while, when a post wasn't found, the 404 status was being set after the header template had already flushed output — headers were gone, so Google received a 200 with an effectively empty page. A textbook soft 404, and it quietly erodes crawler trust. The fix was moving the status (plus a noindex header) before any output. Separately, all 87 docs pages on jekcms.com once declared the same hreflang pair — /docs and /tr/dokumantasyon — with no page self-referencing its own URL, which invalidates the entire cluster in Google's eyes. The fix: generate the pair from the actual request path.

Both bugs were embarrassing. Both were also closed with one commit each, in one codebase, shipped through one pipeline. Now replay them on a headless stack: is the wrong hreflang coming from the CMS's locale metadata, from the frontend's head component, or from the CDN rewriting paths? Three systems, three dashboards, one crawler silently downgrading you while everyone figures out whose ticket it is. When you alone answer for rankings across 14 sites, "the fix is in one place" is not a detail. It's the job.

Four questions that actually decide it

1. Do you have a second delivery surface today? Not "we might build an app someday." Today. Speculative channels are how teams end up maintaining an API layer with exactly one consumer — the website a coupled CMS would have rendered for free.
2. Is there a frontend team, or a frontend person? A team can carry a separate frontend application for years. A person carries it until they change jobs — and that departure is one of the most common triggers for headless-to-coupled migrations.
3. How fast does editorial need to be live? If a few minutes of build latency is fine, headless is fine. If "publish" has to mean "live now" — news, corrections, fast iteration — the database-to-page path wins outright.
4. Who operates this in year three? Architectures are chosen by the people excited about them and maintained by whoever is left. Choose for the maintainer.

Score it however you like. My honest reading: two or more headless-shaped answers, and you should go headless without guilt. Zero or one, and you're buying complexity as a fashion accessory.

What jekcms won't give you

Symmetry demands this section. jekcms's API surface is built for pushing content in, not for querying it out: the webhook API accepts publish, schedule, draft, update, delete, media upload and bulk-import calls, authenticated with a Bearer API key or an HMAC-SHA256 signature over the raw request body. That's excellent for automation — the docs cover every endpoint — but it is not a GraphQL content graph your mobile app can query. If you need that, I refer you back to the first section of this post.

Migration honesty, too. The first-class import path targets WordPress: a SQL-to-CSV export you upload through the admin, an official jekcms-migrator plugin currently in wp.org review, and a migration wizard. I moved thousands of posts from my own WordPress sites that way. There is no Contentful or Strapi importer. Leaving a headless platform means exporting through their API and scripting the load into the bulk-import endpoint yourself. Budget for that effort before you commit to a timeline.

The rule I'd give a friend

If content is a product feature consumed by multiple applications, go headless. If content is the product and the website is where people read it, run a monolith and spend the saved complexity budget on writing. I've had fourteen chances to regret that advice. So far, none taken.

Still weighing options against the other big monolith? Here's how jekcms compares to WordPress.