Every CMS comparison starts in the wrong place. It lines up three products, scores them on features, and hands you a winner that has nothing to do with your team. Two years later the site is untouched because the one person who knew how to edit it left. The platform did not fail. The fit did. This is the set of questions that predicts whether a CMS will still be working for you in year three, regardless of which logo ends up on the invoice.
Choosing a CMS is a team decision before it is a technology decision. Map who edits content after launch, how often you publish, whether your content is structured or page shaped, and what developer access you have. The right category follows from those answers, and the specific product follows from the category.
Why do CMS decisions go wrong so often?
The usual failure is not picking a bad product. It is picking a product suited to a team you do not have. Agencies and internal champions choose for the build, which lasts three months, rather than for the operating period, which lasts years. During the build there is a developer on hand, momentum, and enthusiasm for learning something new. Afterwards there is a marketing coordinator with forty minutes to change a price.
The second failure is scoring features you will never use. Every platform demo shows workflow approvals, personalisation and multi language. If you are a twelve person company publishing two pages a month, those features are cost, not capability. They add configuration, training and the sort of complexity that quietly stops people from making small updates.
So start with the operating reality. Six questions do most of the work, and none of them mention a product name.
Who edits content after launch?
This is the question that decides more than the rest combined. Be specific. Not the department, the person. What is their job title, how comfortable are they with software, and how much of their week is available for the site?
If the answer is a non technical marketer who touches the site occasionally, you need a platform where editing is visual, mistakes are hard to make, and nothing breaks when someone drags an image into the wrong place. If the answer is a content team of four with an editor who owns standards, you can afford structure and an admin interface with a learning curve. If the answer is a developer, almost anything works and you should optimise for something else.
The honest version of this question is uncomfortable: is there anyone at all? Plenty of small businesses have no internal owner, and the right answer for them is a simple platform plus a retainer, not a powerful one they will never open. There is no shame in that, but pretending otherwise produces a stale site.
How much do you actually publish?
Publishing volume changes what matters. At two updates a month, editor speed is irrelevant and you should optimise for how easy it is to remember how things work after four weeks away. At twenty posts a month, small friction compounds. Bulk actions, drafts, scheduling, media handling and preview become the things that decide whether the team hits its calendar.
Be realistic about volume rather than aspirational. Most teams plan for the publishing cadence they wish they had. If the last twelve months produced nine pieces, choose for nine, and revisit when the content operation actually grows. Buying capacity you do not use is the most common overspend in this category.
We ask to watch the actual editor make a real change in their current system before recommending anything. Ten minutes of watching tells you more than any requirements document, and it usually kills at least one option on the shortlist.
Is your content structured or page shaped?
Page shaped content is what most brochure sites have. Each page is a one off arrangement of headings, text and images. Nothing repeats in a predictable pattern, and the editor thinks in terms of pages.
Structured content is different. Products, properties, staff profiles, events, case studies, locations and menu items are records with fields, and they get displayed in several places: a listing, a detail page, a filtered view, sometimes a feed to another system. If you have this, you want a platform with real content modelling, where a case study is a defined type with defined fields rather than a page someone formatted by hand.
Get this wrong in the structured direction and you end up with sixty pages that all look slightly different, no way to filter them, and a redesign that means touching every one. Get it wrong in the other direction and you have built a database for content that would have been fine as pages.
What developer access do you really have?
Three honest answers exist: none, occasional, and dedicated. Each rules out a different set of options.
With no developer access, anything requiring a build step, a deployment pipeline or dependency updates is a trap. It will work on launch day and rot afterwards. With occasional access, through an agency retainer or a contractor, you can run a traditional CMS provided the setup is conventional and documented. With a dedicated developer or team, headless and custom become viable, and the flexibility usually pays for itself.
Add a related question: who patches it? Self hosted platforms need updates, backups and security attention. If nobody owns that, choose something hosted where the vendor owns it. An unpatched CMS is a liability, and the cheapest hosting bill in the world does not cover the cost of a compromised site.
What does it cost over three years?
Licence fees are the smallest part. Build the number properly.
- Initial build, including design, development and content migration.
- Licence, hosting and plugin or app subscriptions, multiplied by thirty six months.
- Maintenance: updates, backups, monitoring and the occasional break fix.
- Training and the productivity lost while the team learns the system.
- Change cost: what a new template or content type costs once, multiplied by how often you expect to need one.
- Exit cost: what it takes to get your content out and into something else.
That last line is the one people skip, and it is where lock in lives. A platform with cheap monthly fees and no export path is expensive. So is one where every layout change needs a developer at agency rates. Run the arithmetic across three years and cheap options frequently stop looking cheap around month eighteen.
Which CMS category fits which team?
Once the six answers are on paper, the category is usually obvious. Pick the category first, then compare products within it. Comparing across categories is how people end up choosing a headless system for a five page site.
| Team shape | Content needs | Publishing volume | Category to shortlist |
|---|---|---|---|
| No developer, one occasional editor | Page shaped, under 30 pages | Low | Site builder |
| No developer, small marketing team | Pages plus a simple blog | Low to medium | Site builder |
| Agency retainer, marketing owns content | Pages, blog, a few structured types | Medium | Traditional CMS |
| Agency retainer, content team of two or more | Structured types with listings and filters | Medium to high | Traditional CMS with strong modelling |
| In house developer, content team | Structured content reused across web and app | High | Headless CMS |
| Development team, product mindset | Content tied to application logic or complex integrations | Any | Headless CMS or custom |
| Development team, unusual requirements | Regulated, offline, or heavily bespoke workflows | Any | Custom, with a documented exit plan |
Two notes on reading this. Site builders are not a downgrade. For a business with no internal developer and modest content, they are the option most likely to still be maintained in three years, which matters more than theoretical ceiling. And headless is the easiest category to choose for the wrong reasons: it is genuinely good when you have multiple front ends or a development team, and genuinely painful when a marketer wants to move a section and there is no visual editor to do it with.
How do you reduce migration risk?
Assume you will move eventually. Most sites change platform every four to seven years, and the decisions that make that survivable are made at the start.
Keep content and presentation separate wherever you can. Content stored in structured fields moves cleanly. Content baked into visual page builder markup does not, and that markup is the single biggest reason migrations blow their budget. Check the export path before you commit: can you get everything out in a usable format, including media and metadata, without paying for a tool or a consultant?
Keep the URL structure sane and stable, because redirects are where acquisition performance gets lost during a replatform. Document what has been customised, so the next team is not reverse engineering decisions. And prefer conventional setups over clever ones. Clever configurations look efficient until the person who built them stops answering emails.
Before any build, we write down the content types and their fields on one page and confirm the editor can describe their weekly workflow. If that page is short and the workflow is simple, we recommend the simpler platform, even when the client expected us to sell the bigger one.
None of this needs a spreadsheet with weighted scores. Answer the six questions truthfully, pick the category the answers point at, and then compare two or three products inside it on the details that matter to your editors. The platform argument is nearly always a proxy for a team conversation nobody wanted to have, and having it early is what makes the build hold up.
Frequently asked questions
What is the difference between a traditional and a headless CMS?
A traditional CMS stores your content and renders the site itself, so templates and content live together in one system. A headless CMS stores structured content and serves it through an API, leaving the front end to be built separately. Headless gives you flexibility and reuse across web, app and other channels, but changing anything visual generally needs a developer rather than an editor.
Is a site builder a bad choice for a real business?
No. For a business with no internal developer, a modest number of pages and page shaped content, a site builder is frequently the choice most likely to still be maintained and updated in three years. That matters more than a higher theoretical ceiling. The limits show up when you need structured content types, filtering, deep integrations or unusual approval workflows, which is when another category earns its cost.
How do I know if my content is structured?
Ask whether the same kind of item repeats with the same set of fields. Products, properties, staff profiles, events, locations and case studies almost always do. If those items also need to appear in a listing, a filtered view or a feed to another system, that is structured content, and you want a platform with genuine content modelling rather than pages someone formats by hand each time.
What is CMS lock in and how bad is it?
Lock in is simply the cost of leaving: content held in proprietary formats, layouts baked into page builder markup, no usable export for media and metadata, or custom work nobody documented. How bad it gets depends more on how a site was built than on which platform was chosen. Keeping content in structured fields, checking the export path before committing, and avoiding clever configurations keeps it manageable.
How often should we expect to change CMS?
Plan for something in the range of four to seven years. Platforms rarely get replaced because they broke; they get replaced when the business model changes, the team shape changes, or maintenance costs outgrow the value the site delivers. Rather than trying to pick something you will never leave, make leaving cheap: structured content, stable URLs, documented customisation and a verified export path.
Should the agency building the site pick the CMS?
They should recommend rather than decide alone, and they should show the reasoning. Ask which options were considered, why the others were ruled out for your specific team, and exactly what your staff can change after launch without calling them. An agency that proposes the same platform for every client is describing its own comfort zone, not your requirements. Get the answers in writing before the build starts.
The takeaway
The best CMS is the one your team will still be using well in year three. That is a question about people, publishing rhythm and content shape, not about feature lists. Answer the six questions honestly, choose the category they point at, then compare products inside that category on the details your editors will feel every week. Do that and the platform argument mostly resolves itself.