If you need to choose a CMS for content production and you are weighing a traditional system against a headless one, the short version is this: the architecture decides who owns delivery, and the workflow decides whether your team can keep publishing. A traditional CMS is usually the simpler fit for a website-first team on established templates with limited developer help. A headless CMS becomes more attractive when the same structured content has to feed several front ends and you have people who can support preview and delivery. Either way, the system has to prove that your writers, editors, and reviewers can move approved changes to the live page at the volume you are planning for.
That last part is where most evaluations go wrong. Feature lists describe a demo with one short entry and one administrator. They rarely show what happens when five contributors and two editors work at once and a campaign launch is waiting on a batch of related pages.
This article defines the two architectures, then compares them on the axes that decide whether a CMS for content teams holds up under load: permissions and review, concurrent edits and versions, scheduling and releases, the path from publish to live, and the plan you would actually buy. It does not rank products. Named systems appear only where their documentation shows a specific mechanism or limit worth knowing about.
The short comparison
| Decision axis | Traditional architecture | Headless architecture | What actually decides the fit |
|---|---|---|---|
| Presentation ownership | Generally integrated with content management | Separate front ends own rendering | How many destinations exist and who maintains them |
| Website editing and preview | Often a shorter integrated path | Needs an implemented connection between drafts and the front end | Whether editors can preview on their own and see it accurately |
| Content reuse | Depends on the content model and APIs provided | API delivery is central to the architecture | Whether reusable structured content is a real requirement |
| Roles and approvals | Can be basic or sophisticated | Can be basic or sophisticated | Actual permissions, transitions, and plan entitlements |
| Concurrent work | Has to be tested in the chosen editor | Has to be tested in the chosen editor | Locking, conflict handling, and recovery behavior |
| Scheduling | Depends on the implementation's scheduler | Depends on CMS scheduling and downstream delivery | Successful execution and reader-visible timing |
| Operating effort | May sit in one application and its extensions | Includes the CMS plus separate preview and delivery pieces | Your support capacity and measured publishing effort |
The two architecture columns look alike in the middle rows on purpose. Neither one guarantees approvals, safe collaboration, reliable scheduling, or low cost, and the rest of this article is about how to check those things yourself.
What is a traditional CMS?
In a traditional, or coupled, CMS, content management and the website presentation layer belong to the same system. You write, preview, and publish pages in one place, and the system renders the site your readers see.
The appeal is a fairly direct path from editing to a published page. If most of your output uses established templates, fewer separately operated pieces can make ownership simpler.
"Traditional" does not mean weak governance or no API. Drupal's documented moderation and Workspaces features show that an integrated CMS can hold pending revisions and coordinate grouped publishing. Integration can cut coordination work, but it does not prove the workflow is governed well enough for a team publishing at volume.
What is a headless CMS?
A headless CMS manages content separately from how it is displayed and delivers it through APIs. Separate front ends fetch the content and render it for a website, an app, or any other destination.
The appeal is reuse. Structured content can serve several experiences without the CMS being responsible for every presentation layer. The added responsibility is that someone has to own the whole path to the reader: how draft preview works, what happens after someone clicks publish, and who supports the front ends and integrations when something fails. Editors do not necessarily have to ask a developer to change a sentence. How much autonomy they have depends on the implementation.
Hybrid setups blur the line further, so when you compare headless CMS vs traditional options, you are really comparing the specific implementation on the table. Ask which capabilities come with the product, which have been configured, and which still need development.
Start with what production volume means for you
A CMS can store a huge number of articles and still be awkward for a busy team, because storage, reader traffic, and production throughput are different things. A useful working definition is the number of approved content changes that reach their live destinations in a set period, counting updates to existing articles as well as new ones.
Authoring, coordination, publishing, and delivery each put a different load on the system. An article is also often several objects in the CMS, such as an entry, an author record, images, and related entries, so 100 articles do not necessarily mean 100 scheduled actions.
Before you look at a product, write down your new articles and updates per month, the most authors and reviewers working at once, your largest launch, and who can support preview and integrations. No reviewed documentation offers a universal article-count threshold for switching architectures, so your own numbers are the only ones that count.
Review and publishing time deserves attention too. As a constructed example, not a benchmark, 60 articles a month at 30 minutes of review and 15 minutes of CMS preparation each is 45 hours a month, and at 120 articles it is 90. Faster drafting does not remove that downstream work.
Can your authors move content through an enforced review process?
The first axis is the CMS multi-author workflow itself: who can do what, and whether the review steps are actually enforced. A role label is not an approval process, and a workflow state is not a permission boundary.
At volume, check whether the system separates creating content from publishing it, editing a draft from changing a published version, reviewing from approving, and approving from scheduling. A freelancer should be able to contribute without administrator access, and a reviewer should be able to move an item along without unrelated configuration privileges.
WordPress shows why names are not enough. Its documentation describes a Contributor role that can write and manage its own posts but cannot publish them, an Author role that can publish its own posts, and an Editor role that can publish and manage other people's posts. If you give a freelancer the Author role, you have not created an editor-approval gate, because publishing is part of that role. Its REST endpoints also check capabilities, so integration access should be tested separately from the browser.
Next come states and transitions. A state says where content is, and a transition is a permitted move between states. For each one, find out who can perform it, what must be finished first, who owns the next action, whether the earlier decision is recorded, whether a material edit after approval triggers a new review, and whether someone can skip the step by publishing directly.
Drupal's content moderation shows a useful pattern. Its default Editorial workflow has Draft, Published, and Archived states, you can add your own such as Review, and it can keep a published version live while a separate working copy is reviewed. Preparing a change does not immediately alter the public page. Strapi 5 documents Review Workflows as an Enterprise-plan feature, with four default stages (To do, In progress, Ready to review, and Reviewed) and roles that control who moves content in or out of a stage. That is useful, but the documentation alone does not show that every publishing route respects an unskippable approval, so ask for a demonstration of publishing permissions and integration behavior, not just a change of stage labels.
A good outcome is a writer submitting work, an editor returning it with clear feedback, and only the intended role approving or publishing, with the same limits holding through integrations. A bad one is a status field used as a reminder while contributors keep direct publishing access.
Can people edit and update content without losing work?
Several user accounts do not prove that people can work safely on the same article, and a revision history does not prove conflicting edits get prevented. These are different mechanisms, and each covers a different risk.
- Autosave keeps recent work but says nothing about approval or safe simultaneous editing.
- Revision history records earlier versions but may not cover every field and asset.
- Edit locking restricts simultaneous changes but is not real-time co-authoring.
- Optimistic concurrency control checks that a write is based on the expected version but does not merge conflicts.
- Release-specific versions keep planned changes apart from ordinary drafts but are not a full backup.
Documentation makes these differences concrete. WordPress keeps at most one autosave per user per post, and each new one replaces the last. Revision retention is configurable, so a site can keep every revision, a set number, or none, which means a Revisions screen does not tell you the history you want is still there. By default only title, author, content, and excerpt are tracked, so a restore should not be assumed to bring back media or custom fields. Contentful's management API documents optimistic locking, so it is worth testing what happens when an integration writes with a stale version after a person has edited. That is an API behavior and not evidence of real-time co-authoring. Sanity allows at most one ordinary draft per document, with a separate version in each release the document belongs to, and those release versions are locked while the release is scheduled.
When you evaluate, ask what happens when two contributors touch the same field, when an integration writes while an editor is working, and whether a restore changes the draft or the live page. Retention periods and audit coverage were not established for every platform, so confirm them yourself and do not treat history as a complete backup.
Will scheduled content and coordinated launches actually go live?
Scheduling has to be judged as a process that runs, not a date field. There are four separate events: a desired publication date, a queued and validated scheduling action, successful publication inside the CMS, and the intended content appearing at its destinations. The last one is what your reader sees.
For single items, check time-zone and daylight-saving behavior, who is allowed to schedule, whether the job publishes a frozen approved version or the latest draft, what happens if content changes after scheduling, and how failures are reported. These behaviors differ between products. WordPress uses WP-Cron for scheduled posts, and its documentation explains that WP-Cron checks for due tasks when a page loads rather than running continuously. Its documented example is a task set for 2:00 PM that does not fire until a page load at 5:00 PM, which is a timing mechanism and not a claim that every site is late. The lesson is to ask how scheduling runs on your actual hosting.
Coordinated releases are a different need. A release groups related changes, such as an article, a campaign page, related entries, and assets, so they are prepared and published together, which is not the same as publishing several unrelated articles one after another. Drupal Workspaces documents publishing several new items together for a campaign, so grouped publishing is not exclusive to headless systems. Sanity's release guide warns that setting a release time does not by itself schedule the release, because the scheduling action has to be performed too.
Grouped also does not always mean atomic. Sanity documents that releases publish documents in batches, with possible small delays between documents in larger releases. So do not assume every page becomes visible at the same instant, and test a partially valid release, a missing asset, and a failed downstream update to see whether you end up in a state you can recover from.
What happens between publish and the live page?
Publishing is not finished until the right version is visible where it should be. A traditional CMS often gives an integrated website preview, while a headless setup needs draft data connected to the front end. Implementations vary, so ask to see the real experience rather than assuming headless never supports visual preview.
Ask whether editors can preview without a developer and whether the preview shows the draft instead of the published version. Then look at the publishing path. A change might trigger a build, a cache refresh, an API fetch, or another delivery step, and you should know who owns the publication events, the credentials, the failure alerts, and the retries. A success message in the CMS does not prove the website updated.
Contentful's webhook documentation is a good counterexample to the idea that a connected webhook heals itself. Its default retry policy retries failures that return a 429 or 5xx response, giving three delivery attempts over a one-minute window, and requests that time out after 30 seconds are treated as failed and are not retried. Your own acceptance criteria should include safe handling of duplicate deliveries, visible failures, and a way to recover.
Does the plan fit your workload and support capacity?
Evaluate the configuration you would actually buy, not the top tier or a sales demo. Four kinds of restriction are worth separating. A feature entitlement is whether the plan includes workflow, release, or permission functionality. A commercial allowance covers seats, projects, and usage. A technical limit is a maximum batch size or scheduling rate. Implementation capacity is what your front end, hosting, and integrations can sustain.
Workflow features are often gated by plan. As noted above, Strapi lists Review Workflows as Enterprise. Sanity documents Content Releases as available on certain Enterprise plans and scheduled drafts on the Growth plan. These are plan restrictions and not price quotes, so check current prices and seat definitions directly.
Technical limits can be just as specific. Contentful's technical-limits page lists 200 items per bulk action, 200 entities or assets per release, and two release actions per minute. Each one counts items or actions, so 200 items per bulk action does not mean 200 articles, and an article with images and related entries uses several. The size of the pending queue and the rate of execution are separate constraints, and a generous delivery allowance says nothing about how fast your editors can publish.
Finally, count operating cost and not only the subscription: seats, hosting, extensions, integration maintenance, developer support, editorial administration, and rework. If your workflow relies on extensions, ask who maintains them, and if you run a separate front end, ask who maintains preview and publishing.
How to test with a real workload
Run a small pilot with a realistic load and not an empty demo. An illustrative one might include five contributors, two editors, one publishing role, 30 new drafts, ten updates to published articles, and one coordinated campaign with dependent entries and assets. Replace these suggested values with your normal load and your largest burst. Check that required approvals hold through integrations, that a proposed change does not alter the live page while it is reviewed, that a scheduled action reaches its destination, and that another authorized person can take over the queue when someone is out.
Record approved changes reaching live destinations per week, time from submission to publication, and time waiting at each review stage. Keep working time and waiting time separate, since faster writing can sit alongside a growing review queue.
When should you choose traditional or headless?
A traditional architecture is the stronger candidate when most content goes to one website through stable templates, editors want straightforward in-context preview, and you have limited capacity to maintain a separate front end. It also has to enforce your review model and run scheduling reliably on your hosting. A traditional system with a suitable workflow can be a better operational choice than a headless one whose publishing integration depends on a busy developer.
A headless architecture is the stronger candidate when the same structured content really does need to serve several front ends, and separating content from presentation supports your delivery model. Editors need a working draft and release preview, someone has to own delivery and recovery, and the plan has to include the workflow features you need. Headless is a delivery architecture, not an automatic upgrade to editorial capacity.
Sometimes neither change helps. If review depends on one overloaded person or most of the delay happens before content enters the CMS, the process may need attention before the platform does.
When you choose a CMS for content production, the headless CMS vs traditional question comes down to delivery needs and support capacity, and then you require proof of the editorial workflow at your own volume, all the way to the live page. A good next step is to take one real publishing batch, with real authors, real review stages, and an update to a live article, and run it through your shortlist before you commit.
