Choosing a CMS: What a Marketing Team Should Ask First

The Question Behind the Question

Most CMS evaluations start with a comparison table and end with a system nobody enjoys using. The table is not wrong, it is just measuring the wrong thing. Feature parity is easy to achieve and easy to compare; workflow fit is hard to compare and is what determines whether your site gets updated or slowly goes stale.

So begin somewhere else. Who will publish? How often? And what do they need to change without asking a developer? Answer those three honestly and most of the shortlist eliminates itself.

Who Publishes, and What Can They Break?

There is a spectrum here and both ends are painful. At one extreme the CMS gives editors a blank canvas and full layout control, and within a year the site has eleven variations of the same page type, four button styles and no consistency. At the other extreme every change requires a developer, so the marketing team stops asking and the site freezes.

The healthy middle is guardrails: editors can change anything that should change — copy, images, ordering, publishing state — and cannot change the things that should stay consistent, like spacing, type scale and component structure. That is the same principle behind a working design system, and it should be visible in the CMS itself rather than enforced by asking people to be careful.

Roles and Approvals

Ask what happens between a draft and a live page. If two people need to approve regulated claims, the system needs to model that, not rely on a message thread. If a junior team member should be able to prepare a post but not publish it, that has to be a permission rather than a convention. Workflow that lives only in people’s heads breaks the first time someone is on holiday.

Structured Content or Free-Form Pages?

This is the most consequential decision and the one most often made by accident. Free-form pages let you build anything, once. Structured content — where a case study is a set of defined fields rather than a canvas — lets you build a hundred of something and change them all at once.

If you publish repeatable things, structure them. Blog posts, services, locations, team members, case studies and products all belong in collections with defined fields, because that is what makes them consistent, filterable, translatable and cheap to redesign later. Keep free-form pages for the handful of genuinely bespoke pages, like a campaign landing page or an annual report.

The Redesign Test

Here is a quick way to judge a system. Imagine you change the design of your case study page in two years. In a structured system you change one template and every case study updates. In a free-form system somebody opens ninety pages by hand. That difference is the entire argument, and it is why the choice matters far beyond the first launch — the same reason a coherent information architecture pays off over time.

Media, and the Mess It Becomes

Ask how the system handles images, because this is where sites quietly get slow and untidy. Does it generate the sizes each breakpoint needs, or does it serve one large file everywhere? Can an editor set alt text at the point of upload rather than remembering later? Is there any structure to the library, or will it hold four thousand files named after camera output within two years?

These sound like small questions and they are not. Media is usually the heaviest thing on a page and the least governed, so a CMS that handles it well removes an entire category of ongoing maintenance work.

Localisation Is Not an Add-On

If you sell in more than one language, ask how the system models that before anything else. There is a large practical difference between a CMS where a translation is a first-class version of the same item and one where it is a separate page you have to remember to update. The second option always drifts, and the drift is invisible until a customer reads a page that is a year out of date.

Check how it handles partial translation, what a visitor sees when a page has not been translated yet, and whether URLs stay parallel across languages. Those details decide whether running two languages is a routine or a permanent tax, as we set out in our guide to international SEO.

One more localisation question that gets skipped: who is allowed to publish in each language? If your Turkish pages are approved by someone in the local market and your English pages by someone at head office, that is two approval paths, and a system that only models one of them will quietly force the team to work around it in a spreadsheet.

Performance, Export and What Happens If You Leave

A CMS is also a performance decision. Systems that assemble pages at request time behave differently from systems that publish static output, and the difference shows up directly in the metrics discussed in our Core Web Vitals guide. Plugin-heavy platforms tend to accumulate weight quietly, one convenience at a time.

Then ask the uncomfortable question: how do you get your content out? A system that can export structured content in a usable format is a system you are choosing rather than being held by. You may never use it, but the fact that you could changes the balance of the relationship — and it takes ten minutes to check before you commit.

Who Maintains It After Launch

Every platform choice is also a staffing choice. Some systems need routine updates, dependency management and security patching; others move that burden to the vendor. Neither is automatically better, but choosing the first without allocating anyone to do the work is how sites end up compromised or stranded on an old version nobody dares to upgrade.

Be honest about your appetite for that work before you sign. If nobody on the team wants to own infrastructure, choose a system where you do not have to, and spend the saved attention on publishing instead — a trade-off we cover in what actually needs doing after launch.

Total Cost Includes the Slow Days

Licence fees are the visible cost and rarely the largest one. The real cost is the marketing manager who waits four days for a paragraph change, the developer time spent on tasks the CMS should have handled, and the campaign that shipped late because the landing page needed a release. Multiply those by a year and the cheap platform is frequently the expensive one.

Judge the candidates by having your actual editors do a real task in each: publish a post with an image and an internal link, then change the order of three sections. Whichever system makes that boring is the right answer. If you want that assessment done against your team’s real workflow rather than a demo, our web team runs the evaluation as part of the build brief and will say plainly when your current platform is the constraint.