Jan Mikoláš
Glossary
CMS
A content management system separates day-to-day editorial work from website development. It manages the content model, media, roles, and publishing, but it is neither a framework nor a universal foundation for every application.
Short definition
Content is created in an admin interface and published through a controlled process.
A CMS stores pages, articles, images, files, categories, and SEO metadata as managed records. Editors work in an administration interface, fill in predefined fields, and, depending on their permissions, save a draft, submit it for approval, or publish it. The rendered page combines this content with a template instead of relying on hand-edited HTML for every page.
A traditional CMS manages content and renders the resulting website. A headless CMS focuses on content administration and storage, exposing published data through an API to a separate frontend, mobile application, or another channel. Neither approach guarantees a sound data model, good performance, or security on its own.
What it solves
Frequently changing content can be managed without modifying code every time
The editorial team can keep content up to date while developers maintain the structure, templates, integrations, and production environment. Well-designed permissions also control who may prepare, approve, and publish a change.
- a company website with service pages, a blog, contact details, and SEO metadata
- a publication with authors, sections, tags, scheduled publishing, and an archive
- a documentation portal with multiple content types, languages, and search
- content delivered from a headless CMS to websites, mobile applications, and other channels via an API
- campaign and landing-page management within a defined set of components and templates
Practical example
A company website with editors and an approval workflow
A company manages three content types: Page, Article, and Case Study. Each record has a title, URL slug, structured blocks, an image, an author, a category, and SEO metadata. Media records include alternative text and usage information, so an editor does not have to provide an entire finished HTML document.
An author prepares a draft and an editor reviews it. Roles and permissions allow the author to edit content while reserving publication for the editor. Once approved, the published version is stored and the relevant page cache can be invalidated. Revision history provides a concise record of the previous state and who made the change, but it does not replace a backup of the complete database and media library.
With a traditional CMS, the active template renders the page immediately. With a headless setup, a separate frontend retrieves the content through a delivery API. A preview endpoint can expose a draft only to an authorised editor, while the public API returns only the genuinely published version.
How it works
Editor → CMS → content → website or API
This text diagram shows the shared editorial workflow and two possible publishing paths. The headless path is an alternative, not another mandatory layer in every CMS.
- An editor opens the administration interface After signing in, they see only the content types and operations allowed by their role.
- They enter structured content Text, media, categories, relationships, and metadata are validated against the content model.
- They save a draft and follow the workflow Content can be reviewed, returned to its author, scheduled, or approved for publication.
- A traditional CMS renders the website It inserts published data into a template and produces a response for the visitor.
- Alternative: a headless CMS exposes an API A separate frontend retrieves the published content and controls the final presentation.
- The change reaches the relevant channels Publishing updates caches, previews, search indexes, or other consumers as required by the implementation.
Key components and principles
The content model, workflow, and presentation have distinct responsibilities.
A CMS is more than a rich-text editor. It must preserve the meaning of content, permissions, and publication state as the website evolves.
Pages, articles, and fields
A content type defines required fields and relationships. A structured date, author, or category reference is more useful than putting every piece of information into a single free-form HTML field.
Media and taxonomy
A media library manages files and their metadata. Categories and tags organise content; they should not be pressed into service as a substitute for every domain relationship.
Users, roles, and workflow
The administration interface needs authentication and server-side authorisation. A workflow distinguishes a work-in-progress draft, content awaiting review, and the published version.
Templates
A template turns content into a particular presentation. In a traditional CMS, it is part of website rendering; in a headless solution, it is generally owned by a separate frontend.
Plugins and modules
These add features such as forms, search, or integrations. Every extension also adds code, expands the attack surface, and brings its own dependencies, updates, and compatibility risks.
Revisions and publishing
Revision history helps compare and undo content changes. Publication state must clearly determine what an ordinary visitor may receive and what belongs in preview only.
Benefits, limitations, and common mistakes
A faster editorial workflow depends on a well-maintained system with sensible constraints.
Practical benefits
- editors can change content without deploying source code for every article
- the content model standardises required data, relationships, and metadata
- workflows and roles separate creation, review, and publication
- templates make it possible to change presentation without manually rewriting every record
- a headless setup can serve multiple clients from one managed source of content
Limitations and mistakes
- an outdated core, plugin, or module can expose a known vulnerability
- too many extensions complicate performance, compatibility, debugging, and upgrades
- an overly permissive editor produces inconsistent structure and makes redesigns difficult
- using a CMS as the foundation of a highly specialised business application simply because it comes with an admin interface
- building a custom CMS without a clear reason and taking responsibility for security, editing, media, roles, and migrations
When it makes sense
Choose a content system around the editorial workflow and publishing model.
A CMS designed for web content is a web application with a ready-made administration interface and content features. A framework gives developers general building blocks and an application lifecycle, but does not usually provide editorial workflows, content types, or publishing out of the box. A CMS may be built on a framework; that does not make the terms synonymous.
An e-commerce store needs a catalogue, prices, a basket, checkout, orders, payments, and inventory. A CMS can manage its articles and landing pages or gain commerce features through a module, but content management alone does not create the sales process. A static-site generator assembles files at build time and may read content from a repository or CMS. A headless CMS differs from a traditional one by separating presentation, yet it must still provide administration, a content model, roles, and publishing.
A CMS is a good fit where content changes regularly and is managed by people outside the development team. Static content may be simpler for a small, rarely changing website. Specialised accounting, manufacturing, or logistics processes are usually better served by a purpose-built application, optionally connected to a CMS for public-facing content.
What to consider
Safe publishing requires maintenance, least-privilege access, and recoverable data.
A CMS is a publicly accessible and often extensible application, so operating it involves more than installing it and choosing a theme.
- regularly update the core, modules, plugins, and themes, and remove unused extensions
- limit roles to genuine responsibilities and secure access to the administration interface
- keep draft previews separate from public responses and test cache invalidation
- back up both the database and media and verify that they can be restored together
- design structured content around meaning and accessibility, not just the current visual design
Common questions
CMS in practice
Is a CMS a framework?
No. A CMS is a ready-made system for managing and publishing content. A framework is a general foundation for building an application; a particular CMS may be built on one.
Is a CMS only for blogs?
No. It can manage company websites, documentation, publications, portals, and content for multiple digital channels. Its suitability depends on the content model and workflow.
What is the difference between a traditional and a headless CMS?
A traditional CMS manages content and generally renders the website as well. A headless CMS exposes content through an API, while a separate frontend creates the final presentation.
Is a CMS the same as an e-commerce store?
No. A CMS primarily deals with content. A store also needs pricing, a basket, an ordering process, payments, inventory, and integrations; the CMS may be only one part of it.
Is a custom CMS safer and simpler?
Not automatically. A custom solution means maintaining the editor, roles, media, publishing, migrations, and security. It is justified only when existing products cannot reasonably meet the requirements.
Experience with web systems
I connect content to a maintainable backend and reliable operation.
When designing web applications, I separate editorial needs, application rules, and integrations so that each part has a clear responsibility.