Start with the work, not the software
A content management system, or CMS, is the place where your team creates and updates website pages. Choosing one often starts with a feature comparison, but a more useful first step is to list what the website must do and who will keep it current. A small organization that updates service information every week has different needs from one that publishes an occasional article and rarely changes its core pages.
Write down your common publishing tasks: changing opening hours, adding a staff profile, posting an event, replacing a document and correcting an old page. For each task, note who requests the change, who edits it, who approves it and how quickly it needs to go live. If a routine correction depends on one outside developer, the system may be difficult for your team to maintain even if it looks impressive in a demonstration.
Test the editing experience with real tasks
Ask for a trial or demonstration using your own sample content rather than a polished example page. Have a likely editor create a page, revise a heading, add an image with descriptive alternative text, set a clear page title and save a draft for review. Watch where they hesitate. Can they tell what the published page will look like? Can they undo a mistake? Can another person review the work without sharing a login?
Look for a sensible balance between flexibility and guardrails. Editors should be able to present useful information without having to design every page from scratch. Reusable page templates and content fields can help keep headings, contact details and calls to action consistent. Too many rigid fields, however, can make an ordinary update awkward. For example, a community group might need a standard event layout but still need room to explain accessibility arrangements or a change of venue.
Plan for accessibility and useful content
A CMS cannot make a site accessible on its own, but it can make good practices easier or harder. Check whether editors can use meaningful headings, write descriptive link text, add image descriptions where needed and publish readable content without working around the template. Test the pages people actually use, including forms and mobile layouts, rather than judging only the homepage. If an essential task is confusing in the test site, ask how it would be fixed and who would do that work.
Consider how content stays useful after launch. Does the system show when a page was last reviewed or let someone assign an owner? Can editors find pages that need updating? A simple workflow might give each service page an owner and a regular review reminder outside the CMS. That may be enough for a small team. The goal is not to automate every decision; it is to make accurate information easier to maintain.
Count the ongoing work and costs
Compare more than the initial build price. List the likely costs of hosting, support, software updates, paid extensions, training and future changes. Ask who applies updates, checks that the site still works afterward, handles backups and restores the site if something goes wrong. If these jobs belong to a supplier, clarify what their agreement covers. If they belong to your team, make sure someone has the time and instructions to do them.
Keep the setup as simple as your requirements allow. Each extra extension or custom feature may create another thing to update or troubleshoot. Check whether editors have individual accounts and appropriate permissions, whether unused accounts can be removed easily and whether backups can be tested. These are everyday maintenance questions, not just technical details. A system your team can operate safely is usually a better fit than one that offers features nobody has the capacity to manage.
Make a decision your team can explain
Create a short comparison sheet for the options you are considering. Score each against a few priorities your team agreed on beforehand, such as ease of routine editing, accessibility of the finished pages, required support, total ongoing effort and ability to move your content later. Record important trade-offs in plain language. For example: “This option is easy for staff to edit, but we will need supplier help to change page layouts.”
Before committing, run one complete workflow from request to publication. Ask an editor to update a real example page, have someone else review it, check it on a phone and confirm that you can tell whether people reach its main action using your chosen measurement approach. This small test reveals more than a long feature list. Choose the CMS that supports the work your organization will actually do, then document the few steps people need to repeat.
