Choosing a CMS for a Public Sector Website

The Wrong Selection Criteria

CMS selection tends to be driven by a feature matrix built from vendor material. Everything on the list is present in every product, so the exercise resolves on price or familiarity, and the decision is effectively random.

The features that actually determine whether the site is good in three years are rarely on the matrix, because they are properties of daily use rather than capabilities. The question is not whether the platform can do something. It is what happens by default when an ordinary editor, under time pressure, does the obvious thing.

Optimize for the Editor

Public sector sites are maintained by people whose job is not web publishing. They are communications officers, program staff and subject specialists who edit a page occasionally, usually urgently.

That user profile should dominate the decision. Two questions get you most of the way:

• How long does it take to publish a routine update? Not a new template, but a paragraph change and a new PDF. If it takes more than a couple of minutes, editors will route around the CMS, and content will drift to places nobody governs.
• What does the editor see when they get it wrong? A good system prevents the mistake or explains it in plain language. A bad one accepts it silently and publishes it.

Run this as a real test during evaluation. Give an actual editor an actual task on each shortlisted platform and watch without helping. It is more informative than any demonstration, because a demonstration shows you the path the vendor chose.

Accessibility Has to Survive the Editing Interface

A platform can render accessible markup and still produce an inaccessible site, because most accessibility failures on content-managed sites are introduced by editors rather than by templates. Images published without alternative text. Headings chosen for size. Link text reading "click here". Tables used for layout. Color used as the only signal.

The platform decides how easy each of those is to do accidentally. The differences are significant and almost never appear in a feature comparison:

• Does the image dialogue require alternative text, or offer a considered "decorative" option, or simply allow empty?
• Does the heading control offer document structure, or font sizes dressed up as structure?
• Can an editor paste styled markup from a word processor straight into the page?
• Are there automated checks at the point of publishing, while the author is still there to fix it?

A platform that makes the accessible path the easy path will outperform a more capable one that leaves it to training, because training decays and defaults do not. This is the same argument we make in the case for building around how people actually work, and it applies with particular force to content. The standards themselves are covered in our accessibility practice.

Workflow and Permissions Are the Real Feature Set

Every CMS claims workflow. The differences show up under conditions that are easy to describe and rarely tested during evaluation.

What happens when the approver is on leave? Can a department publish within its own section without being able to touch another department's? Can you schedule a change for a date, and does the scheduling survive a subsequent edit? Is there an audit trail showing who changed what, and does it survive a rollback? Can you roll back a single page without restoring the whole site?

These questions matter because they are the ones asked during an incident, when something incorrect has gone live and the person who can fix it is unavailable. A platform that answers them well converts a crisis into a two-minute revert.

Structured Content Outlives Pages

Content modeled as pages of formatted text can only ever be shown as pages. Content modeled as structured records (a service with eligibility criteria, a location with opening hours, a notice with an effective date) can be published as a page, surfaced in search, exposed through an API, syndicated to another site, and reformatted when the design changes.

Public sector content is unusually well suited to this because so much of it is genuinely repetitive in shape. The effort is in the modeling rather than the platform, and it pays off at every subsequent redesign, when structured content migrates and page content has to be rewritten.

It also enables a separation between content and presentation that lets the front end evolve independently, which is the architecture behind headless frontend applications.

Know How You Would Leave

Ask every shortlisted vendor to produce a complete export of a realistic site: content, media, metadata, redirects, and the relationships between them. Not a report. The actual data, in a documented format, in a form another system could ingest.

Some vendors will do it readily. Some will offer a report and call it an export. That response is itself the answer, and it is worth more than the rest of the evaluation, because the average public sector site outlives the average CMS contract and the migration is coming whether or not you plan for it. If you want help running a selection or a migration, that is work we do.