Content management system — who in the company gets to change what

"Which content management system should we choose" is usually asked too early. Before it comes another question almost nobody answers deliberately: who in your company is supposed to be able to change what on the site, and how often. That answer rules out most of the options before anyone opens a feature comparison.

The scale is also smaller than the industry suggests. According to W3Techs, as of 9 September 2026, 30.9% of sites run on no monitored content management system at all — one site in three has no CMS and nobody minds. The other 69.1% run on something, and the market is heavily concentrated.

This article is the way in: what such a system is, what its three families are, and how to choose between them. It does not compare products — that is a separate decision, taken after this one.

What a content management system is — and what it does not solve

A CMS is the layer that separates content from the way it is displayed. In practice: to change a price on the site, somebody in the company logs into a panel and edits a number in a field, instead of asking a supplier to change it in a file.

That sounds trivial until you see the cost of not having the layer. A site without a CMS is not technically worse — it is often faster and safer. It is, however, a site you do not change yourselves, which means that a year later it describes an offer you no longer have, because every correction needed an email, a quote and a wait. You do not stop updating it because you do not want to. You stop because it takes time every time.

Three things a CMS does not do, because they are the commonest source of disappointment after a build:

• It will not make you a designer. Moving blocks around is not the same as laying out a page that sells. A panel gives freedom, not competence — and with too much freedom a site looks glued together within six months.
• It will not write the content. The commonest reason builds stall is not technology — it is the absence of text and photographs.
• It will not replace a decision about who is responsible for what. A system enforces roles only once you have defined them.

Three families of system, not twenty products

Comparisons of CMS platforms usually open with twenty names, and that is a bad start: names change every two years, families do not. There are three, and they differ in one thing — where the content lives and who is responsible for it.

The table sorts the categories, but the difference is physical and easier to see: where the content sits, where the presentation sits, and who holds the key to each.

Concentration is higher than the number of options suggests. W3Techs, 9 September 2026: WordPress — a classic-family system — runs 40.7% of all websites and holds 58.9% of the CMS market. The next entries run 5.3%, 4.2%, 2.5% and 1.1% of all websites — together 13.1%, about a third of WordPress’s 40.7%.

That is the only third-party product name in this article, and it appears because it carries a number; the rest of the choice happens at the level of families. The practical conclusion: the classic family is neither risky nor niche, whatever a supplier with an interest in something else implies. If someone advises against it without a reason specific to your situation, ask for the reason.

The choice between families is not settled on market share, though. It is settled by what comes next.

Who changes what, how often — two axes instead of a feature list

This is the one question you have to settle yourself, because no price list answers it. Two axes: how often the content changes and how much a mistake costs in what gets published.

Rare, low risk. Opening hours, phone number, address. Changed once a quarter, and the worst a mistake produces is a typo. The simplest thing to hand is enough — and this is where people most often overpay, buying for needs they do not have.

Frequent, low risk. Blog, news, photographs from finished jobs. What matters is publishing speed and one person managing alone. Elaborate permissions are pointless here; they slow things down.

Rare, high risk. Price list, registration details, terms, anything you are legally answerable for. Changed a few times a year, but an error can be expensive. Here you need a preview before publication and a version history — the ability to check who changed a number and when. You do not need an elaborate editor.

Frequent, several people, high risk. Offers, campaign landing pages, product pages edited by a small team. This is the only quadrant in which a system genuinely pays for itself — the first point at which you need role permissions, versions and a test environment, and the first at which their absence costs more than a licence.

Practical instruction: write down what changed on your site over the last year, who changed it, and what would have happened if the change had been wrong. Do not plan from what you "will be doing" — check what you did. Most companies land in the first three quadrants and buy for the fourth.

When you do not need a CMS at all

Back to the opening figure, because it has a point: if 30.9% of sites manage without a monitored system, check whether you are in that group before paying for a panel nobody will log into.

Three situations in which a CMS is a cost with nothing behind it:

The site has five pages and changes once a year. An offer, contact details, a few case studies. A panel speeds nothing up, because there is nothing to speed up — and it adds a layer to update and secure. A once-a-year change is cheaper as a piece of work than as a subscription plus care.

The supplier does everything anyway. If, panel or no panel, every change goes by email because that is faster, you are paying for a capability you do not use. Not an argument for changing nothing — an argument for changing the process or stopping the payment.

The content lives somewhere else. Companies whose presence rests on a Google profile, social media or a trade directory update those places and treat the site as a business card. That can be a deliberate and correct decision.

The criterion has nothing to do with company size: in the last twelve months, did anyone here want to change something on the site and not do it because it was too much trouble? If yes, a system will help. If nobody wanted to, the absence of a system is not your problem.

And two things easily confused: not having a CMS is different from having a neglected site. The first can be a choice. The second is a condition, recognisable by the symptoms below.

Four roles that will appear anyway — better to name them

The matrix says that in one quadrant you need role permissions. Worth saying what that means in practice, because "roles and permissions" sounds like a line in a price list and is in fact an organisational decision you make either way — deliberately or by default.

In companies where more than one person touches the site, four usually emerge:

• Someone who writes and places content. They should be able to change text and images on existing pages, and not the layout or global styles — not because they are incapable, but because one button colour changed in the wrong place applies to the whole site.
• Someone who approves. For content you are legally or financially answerable for, writing and publishing should be two actions by two people. That is the whole difference between "somebody made a mistake" and "somebody made a mistake and nobody saw it".
• Someone responsible for the presentation. Templates, global styles, new page types. Usually the supplier, at least at first.
• Someone with access to everything. One person on your side — not only on the supplier's. The role whose absence hurts at the parting.

The rule that sorts this out without reading documentation: by default grant the fewest permissions that will do the job. You can always widen them; withdrawing access after someone has moved something is a conversation, not a setting.

One site, several languages — where simple systems end

This is the commonest reason a company outgrows a system that served it for three years, and the least often anticipated at quotation stage.

While a site is monolingual the content structure is obvious: a page is a page. With the second language comes a question simple systems answer badly: is the foreign-language version a separate site, or a different version of the same content? If separate, a year later you have two sites drifting apart and nobody knows which is current. If the same content in another version, the system has to understand that — and that is not a property you add later with a plugin for free.

We write this from experience: this site runs in four language versions, and it shaped its architecture more than anything else — more than the design, more than performance.

So if the next two years hold a second market, a second language or a separate offer for another country, that is a question to ask before choosing a system. Adding it later is usually a rebuild, not an extension.

Free CMS — what exactly is free

The most popular classic systems are free and that is not a trick. The core genuinely costs nothing and there is no hidden licence fee in it.

The cost sits elsewhere, predictable in kind rather than in amount: the hosting it stands on · add-ons for what the core does not do · someone's time to keep it updated. The first is known in advance, the third usually underestimated, and the second can be bigger than the other two together — broken down on price-list figures in the article on the editor layer over WordPress.

The distinction worth remembering, because confusing it costs the most: "free" in the classic family means "no licence fee", not "no cost". In the closed family it is the other way round — there is a single, visible fee, and what you cannot see is the renewal price and whether you can get out.

How to tell the system is wrong for you

Not by it being old or unfashionable. There is no best CMS in the abstract, only one that fits — and four symptoms that say yours does not, each checkable this week.

Nobody logs into the panel. If nobody has changed anything unaided in six months, the system is not working, however well it reads in the description. Check the date of the last edit.

Every change requires the same person. If everything goes through one human — yours or the supplier's — that is not a content management system — it is a bottleneck with an admin panel.

You are afraid of updates. Putting updates off because "something broke last time" is a symptom, not caution. It has its own article — the commonest reason company websites stop being secure.

Publishing takes courage. With no preview and no way to undo a change, every price-list edit is a small stress, so it happens less often than it should. Same diagnosis as the "rare, high risk" quadrant.

Three of those four are organisational, not technological, and changing the system will not remove them. Establish that before the quote.

What happens when you change systems

A CMS migration is sold as a technical operation, and that is where most of the disappointment comes from, because the part that hurts is not technical.

Content moves, structure does not. Text, images and pages move almost always. What has to be built again is the way the content is organised — what the page types are, what fields they have, what relates to what. The old system imposed one structure, the new one imposes another, and mapping between them is human work, not an export.

Addresses move — if somebody sees to it. The only item here whose neglect costs permanently. Changing systems usually changes page addresses, and an address that stops answering takes with it everything the search engine knew about it. Redirecting address to address is cheap during a migration and expensive a year later.

Habits do not move. Someone who published in the old panel publishes more slowly in the new one for the first few weeks — normal, not a sign of a bad choice. Build it into the timeline rather than explaining later why "it was supposed to be faster".

The order that saves the most: settle the content structure first, then choose the system, then migrate. The reverse produces sites with twenty page types of which four are used.

What it costs and how to run it without losing positions sits under the decision to rebuild. Close it with testing before launch — a migration breaks more things at once than anything else.

When separating content from presentation makes sense, and when it is overkill

The headless CMS family — content in one place, presentation built separately — is sold as the natural next step. It is not. It is a choice that moves the weight from licences onto people.

We write this first-hand, because this site runs on such a system — Payload CMS. It gives a freedom none of the other families offers: the content structure is designed around what we actually publish rather than around what a template author anticipated. It costs exactly what it sounds like: it requires someone on the team who can code. Not "someone technical" — a developer. Without one, headless will be an ordeal rather than a saving.

So it makes sense when content has to reach more than one destination, when the structure is unusual, and when there is someone to maintain it. Further in the article on headless architecture, and the choice between it and the classic family in a separate comparison or a short quiz.