Search for "four components of a CMS" and you'll land on Acquia's page listing an editor, a repository, workflow and publishing. The next result, Tech Monitor, lists indexing, format management, revision control and publishing. A third, built around Sitecore's architecture, counts back end, front end, database, templates, APIs and security. Three sources, three lists, and not one of them is wrong.
This article gives you the straight answer to What are the 4 components of CMS?, explains why those lists differ, and shows you how to use the model when you're actually choosing or running a system. We'll also clear up the one case where "CMS" means something else entirely.
What are the 4 components of CMS? The short answer
The most useful four-part model is: content editor, content repository, workflow and governance engine, and publishing layer. Acquia's 2026 overview of content management systems describes these as the core pieces, and I think it's the cleanest way to explain a CMS because each part maps to a job a real person does.
| Component | What it does | Who touches it |
|---|---|---|
| Content editor | Where authors write and format content | Writers, marketers |
| Content repository | Stores text, images, video, metadata | Mostly the system itself, admins |
| Workflow and governance engine | Drafts, reviews, approvals, permissions | Editors, managers, legal |
| Publishing layer | Delivers approved content to the site or API | Developers, the system |
That's it. Everything else in the CMS world is a variation on these four jobs: make it, keep it, control it, ship it.
Component 1: the content editor
The editor is the screen your team actually lives in. It's where someone types a headline, drops in an image, sets a meta description and hits save. In WordPress that's the block editor. In Webflow it's the visual canvas. In a headless system like Contentful or Sanity, it's a structured form with fields instead of a page.
A good editor does three things well: it keeps formatting consistent, it doesn't let non-technical people break the layout, and it saves drafts without drama. A bad one is the reason your marketing team emails Word documents around instead.
Here's my position: the editor is the most overrated buying criterion of the four, and I'll defend that. Picture a vendor demo where the sales rep drags a hero banner around for ten minutes and everyone nods. Six months later, nobody's complaining about the banner. They're complaining that legal can't approve a page without emailing screenshots, and that a deploy broke the product feed. Editors are easy to compare in a trial. The other three components are where the pain actually lands, so weight them more heavily.
Component 2: the content repository
The repository is the database layer that stores everything: pages, posts, media files, authors, categories and the metadata that ties them together. Acquia lists it as the place where content and media live, separate from how that content looks.
That separation matters. Because content sits in a repository rather than inside a finished page, you can reuse one product description on a website, an app and a newsletter. Edit it once, it updates everywhere.
What to check in a repository:
- Structure: can you define content types (blog post, product, event) with their own fields?
- Media handling: does it resize images and store versions, or is it a folder of mystery files?
- Search and retrieval: can you find a page from 2021 in under 10 seconds?
- Portability: can you export everything if you switch systems?
That last one gets ignored until it's too late. Moving a 5,000-page site from a heavily customised Drupal 7 install to Drupal 10 or WordPress, which plenty of organisations had to do as Drupal 7 reached end of life, routinely runs into five or six figures in agency fees. Much of that cost is untangling how the old repository stored content, not building the new site.
Component 3: the workflow and governance engine
This is the part that separates a toy from a business tool. The workflow engine manages drafts, reviews, approvals and permissions, according to Acquia. It answers boring but expensive questions: who can publish? Who has to sign off on legal copy? Can an intern accidentally delete the pricing page?
On a solo blog, you barely notice it. On a team of 15 writers across three regions, it's everything.
What good governance looks like
Simple roles come first: author, editor, admin. Then approval steps, so a draft can't go live until someone with authority clicks yes. Then revision history, so when somebody overwrites a page you can roll back in two clicks. Scheduled publishing and audit logs round it out.
If more than one person can publish, you need a workflow engine. If only one person can, you still need revision history.
Some explanations fold revision control into its own category. Tech Monitor, for instance, summarizes a CMS through four functions: indexing, format management, revision control and publishing. Same ideas, sliced differently.
Component 4: the publishing layer
Publishing takes approved content and delivers it to wherever people read it. In a traditional CMS like WordPress or Drupal, the system renders pages itself using templates and themes. In a headless setup, it exposes content through APIs so a separate front end (a React site, a mobile app, a smart display) can pull it in. Sitecore's explanation of headless CMS draws exactly that line.
| Approach | How content reaches users | Good fit |
|---|---|---|
| Traditional (coupled) | CMS renders pages with templates | Blogs, small business sites |
| Headless | APIs feed separate front ends | Multi-channel brands, custom apps |
| Hybrid | Both, depending on the channel | Larger teams in transition |
For most small sites, traditional is the right call. Headless is great, but it adds developer cost you may not need. Don't let a vendor talk you into it because it sounds modern.
Why you'll see other "four component" lists
There's no single official taxonomy. Different vendors slice the same machine differently. Sitecore's architecture overview, for example, breaks a CMS into back end, front end, database, templates and themes, APIs, and security and user management. That's six, not four, and it's describing technical layers rather than jobs.
The Wikipedia entry on content management systems takes yet another angle, splitting things into a content management application (CMA) and a content delivery application (CDA). Two parts, still the same system.
So if an exam or a textbook gives you a different list, write the one your instructor or interviewer uses. For real decisions, use the editor, repository, workflow, publishing model. It's the one that maps to jobs, and jobs are what you're buying.
What if CMS means Medicare?
If you landed here from a healthcare context, CMS likely means the Centers for Medicare & Medicaid Services, and the "four parts" are Medicare's. Those are Part A (hospital), Part B (medical), Part C (Medicare Advantage) and Part D (outpatient prescription drugs).
For current enrollment figures, such as the share of beneficiaries in Medicare Advantage or covered for prescription drugs, check the latest Congressional Research Service or CMS data directly, since the percentages shift every year.
How to use the four components when choosing a CMS
Score any platform against the four components before you look at price. Here's a quick process.
- Write down your team shape. How many authors, how many approvers, how many channels?
- Test the editor with a real author. Not a developer. Give them 20 minutes and a task.
- Inspect the repository. Try an export. If it's painful in the trial, it'll be worse later.
- Map your approval chain. Can the tool model it without a plugin hack?
- Decide on publishing. One website means traditional. Website plus app plus kiosks means look at headless.
My recommendation: for a typical small business or content-led site, pick a traditional CMS with solid roles and revision history, and spend your effort on what you publish, not on architecture.
The component most people forget: what goes into the system
A CMS stores and ships content. It doesn't decide what's worth writing. You can have flawless workflow and still publish pages nobody searches for. If organic traffic is the goal, the real bottleneck is picking topics you can actually rank for, which is what a winnable keyword approach is about. And if you're newer, this breakdown of which Google queries a new site can rank for is a good starting point.
You can also read our shorter take on the question, What are the 4 components of CMS? in its web-versus-regulatory split, if that's the angle you need.
The Umbraco knowledge base on CMS is also a decent plain-language primer if you want a vendor's view of the basics.
And when you test that export in step 3, run it on your 50 oldest pages, not your newest. Old pages are where broken media links and orphaned metadata show up.
Spook handles the part a CMS doesn't: it finds winnable Google and ChatGPT queries, writes SEO-optimized articles in your brand's voice, and publishes them to your site. It's built for website owners and small teams who want organic traffic without running a content operation by hand.