How to Choose the Right CMS for Your Website

Start with the work, not the platform

The wrong CMS is often selected through a feature comparison before anyone models the content or watches an editor publish it.

Begin with three questions:

1. What kinds of information does the organisation manage?
2. What recurring tasks must editors complete safely?
3. Which systems, controls, and delivery channels must the content support?

A platform becomes a candidate only after those answers exist.

First decide whether you need a CMS

A CMS is useful when non-developers publish or update structured content regularly. A tiny site that changes twice a year may be simpler as version-controlled files maintained by the delivery team.

You probably need a CMS when:

• editors publish without code deployments;
• the site contains recurring content types;
• several people contribute or approve content;
• scheduled publishing matters;
• languages or regions vary;
• content feeds more than one channel;
• permissions and audit history matter.

Do not add a CMS merely because websites usually have one. It creates software, security, training, and maintenance obligations.

Model representative content before comparing tools

Choose three difficult examples: perhaps a service with related case studies, a multilingual report with authors and downloads, and a location with regional contacts and opening times.

Describe them as fields and relationships, not screenshots.

For a case study:

• title and summary;
• client or anonymisation status;
• services and sectors;
• problem, approach, and result;
• evidence and media;
• related work;
• publication and review dates;
• author and approval state.

Then test whether each CMS represents the content cleanly. If everything becomes a rich-text field or page-builder canvas, the system may look flexible while making reuse, search, migration, and consistency harder.

Evaluate the editorial workflow

Ask real editors to perform real tasks in a trial environment:

• create a new article from approved copy;
• replace an image and write appropriate alternative text;
• preview desktop and mobile presentation;
• schedule publication;
• relate a case study to two services;
• update shared information once;
• create a regional variant;
• submit work for approval;
• restore an earlier version;
• find content due for review.

Measure confusion, workarounds, and the risk of damaging layout—not just task speed during a guided demo.

Structured fields versus visual freedom

Editors need enough flexibility to communicate; the brand needs enough constraint to remain coherent.

Use structured fields for information with meaning or repeated use: prices, dates, authors, locations, product specifications, relationships, summaries, and calls to action.

Use controlled layout options for genuine editorial variation: a small set of tested sections, emphasis patterns, and media treatments.

Unlimited page builders transfer design-system decisions to every editor on every page. Fully rigid templates transfer ordinary publishing requests to developers. The right boundary depends on the organisation's content and governance.

Traditional, headless, or hosted builder?

Traditional CMS

Content management and page rendering live in one platform. This often suits marketing sites that need mature plugins, familiar workflows, and straightforward hosting.

Headless CMS

The CMS provides content through an API while a separate front end renders the website. It is useful when structured content serves several channels, the interface needs an independent technology stack, or the organisation requires a clear separation of content and presentation.

It also creates more systems to build and operate. Troiana's guide to adding a headless CMS without the bloat covers that trade-off.

Hosted visual builder

Editing, design, hosting, and deployment are bundled. This can be efficient for standard marketing sites and smaller teams, provided the platform's structure, performance, portability, and integration limits fit.

Architecture labels do not decide quality. Choose the simplest model that satisfies the important requirements.

Permissions, governance, and audit

List roles based on real responsibilities:

• contributor;
• editor;
• publisher;
• regional owner;
• administrator;
• developer or integration service.

Check whether permissions apply at the necessary level: content type, locale, region, workflow stage, or individual record.

For regulated or high-risk publishing, evaluate approval records, version history, scheduled changes, audit logs, and the ability to correct or withdraw content quickly.

Preview must reflect reality

Preview is not a cosmetic feature. Editors need confidence about line length, media crops, missing fields, related content, mobile layout, and scheduled changes before publication.

For a decoupled front end, confirm how draft and scheduled content reaches preview securely. A CMS demo may show its own generic preview while the production website behaves differently.

Localization is more than translation fields

Ask:

• Does every locale share the same structure?
• Can a region omit or add content?
• What happens when the source changes after translation?
• Who can publish each locale?
• How are fallback and untranslated states handled?
• Can URLs, metadata, media, and structured data vary correctly?

Test with an actual regional page. Localization claims become clearer when editors encounter an incomplete translation, not when a sales deck shows flags.

Integrations and content delivery

Document systems that read from or write to the CMS: website front ends, apps, search indexes, ecommerce, CRM, translation, DAM, personalization, email, or internal tools.

Evaluate:

• API completeness and documentation;
• webhooks and event reliability;
• rate and usage limits;
• development and staging environments;
• migration and bulk operations;
• search and filtering capabilities;
• failure monitoring;
• vendor support for breaking changes.

Do not make the CMS the source of truth for data already governed elsewhere merely because it is easy to add a field.

Performance and security boundaries

A CMS influences performance through API speed, caching, image delivery, generated markup, plugins, and editorial choices. It does not determine performance alone.

Understand who owns updates, backups, access reviews, incident response, plugin approval, and vulnerability monitoring. A managed platform transfers some responsibility to a vendor; it does not remove the organisation's responsibility for users, permissions, integrations, and content.

Portability and exit cost

Before importing content, prove that it can leave in a useful form.

Check export of:

• structured fields;
• relationships;
• assets and metadata;
• authors and dates;
• locales;
• redirects and slugs;
• revision history if required.

Proprietary layout data may be difficult to reuse elsewhere. That can be an acceptable trade-off, but price the future migration before the current convenience makes it invisible.

Compare total ownership cost

Include more than the subscription:

• implementation and migration;
• hosting and delivery services;
• user, locale, API, bandwidth, or asset charges;
• plugins and extensions;
• development and staging environments;
• maintenance and security work;
• editor training and support;
• custom integration work;
• exit and migration risk.

A free CMS can be expensive to operate. An expensive managed platform can be economical when it removes work the team would otherwise perform.

The final decision scorecard

Weight these categories for the organisation before scoring vendors:

Run a small proof with representative content before signing a long contract. The difficult example is more informative than the polished demo.

Common questions