How to choose a CMS for a client site: a 10-question checklist
How to choose a CMS for a client site: ten questions to answer before you pick, covering who edits, who hosts, what breaks and what happens when you leave.
Most agencies don't choose a CMS per project. They chose one years ago, for reasons that made sense at the time, and every project since has inherited it. That's not a mistake in itself. Standardising is how an agency gets fast. But it means the decision is rarely revisited, even when the clients, the team and the tools have all changed underneath it.
If you're working out how to choose a CMS, for one client or as your agency's default, the feature grid on a vendor's homepage won't help much. Every product has a rich-text editor and an image library. The differences that matter show up later: in month three, at site twenty, on the day a client leaves. These ten questions are built to surface them.
The ten questions
Who edits, and how often? A marketing team publishing three times a week needs a different tool from a dentist who changes the opening hours twice a year. Frequent editors need speed and drafts. Rare editors need an interface they can work out again from scratch, because they will have forgotten it. Picture the actual person, not "the client".
Can the editor break the design? Ask it literally: can someone with editing access change a font size, move a column, or delete a section that something else depends on? If the answer is "yes, but we'd tell them not to", you've found where your support hours go. The best answer is that the option isn't there at all. We argue this one at length in content control, not design control.
Who hosts it, and who patches it? Someone has to keep the software current, renew the certificate, watch the uptime and deal with the security notice. If it's you, price it. If it's the vendor, check what that actually covers. "Managed" means very different things on different platforms.
What does it cost at twenty sites? Pricing that looks fine for one site can be painful at twenty, and the reverse. Work out the monthly cost for your realistic portfolio, including seats for every client editor. Per-seat pricing quietly punishes the agency that invites clients in properly.
How do clients get their content out? One day a client will leave, or you'll want to move them. Can the content be exported in a structured form, through an API or a file, without scraping your own site? A client who knows they can leave easily is usually more relaxed about staying.
Is there a staging step? Can a change be checked somewhere private before it reaches the live site? This matters for content as much as for code: a half-finished page, a bulk edit, a new section. If every save goes straight to the public, every mistake is public too. More on this in staging vs production.
How are roles split? Can you separate "change the content" from "change how the site is built"? Can you let someone draft without publishing? Can you limit a person to one type of content? Fine-grained roles are what let you give a client real access without giving them everything. See CMS user roles and permissions.
What does a migration in cost? Most new projects start with an old site. Which importers exist, what do they actually carry across, and what's left to do by hand? A good importer saves days. A vague one costs them, because you find the gaps after launch.
Can an agent work in it? Agencies increasingly use AI agents for the repetitive parts of a build: seeding content, bulk edits, scaffolding. Does the CMS expose a documented API an agent can drive, with permissions you can narrow? Or does the agent have to click through the admin like a person? This matters more each year.
What happens if the vendor disappears? Acquisition, a pivot, a price rise you won't accept. Is the content in a portable format? Is the front end tied to the vendor's runtime? Open source isn't automatically the answer, since an abandoned open-source project is its own problem, but you should know your exit before you need it.
How to use the answers
Not every question carries equal weight for every agency. If your clients rarely edit, question one matters less. If you never host, question three is someone else's. Before scoring, pick the three questions that matter most to the way you work, and make them the tiebreakers.
Then be honest about questions two and six. They're the ones vendors are least keen to answer directly, and they're where most of the cost of running a client site turns out to be.
How Contentive answers them
For completeness, here's our own scorecard, including the parts where the answer is no.
The client's editor is generated from the content model, so it contains their content and no layout controls (question 2). We host every site, so there's nothing for you to patch (3), but that's also a "no" if you need to self-host: the platform isn't something you can run on your own servers. Pricing is £39 a month for the Agency plan including three live sites, then £10.99 a month per additional live site, with unlimited seats, so client editors cost nothing (4). As illustrative arithmetic only, twenty live sites comes to about £226 a month. Workspaces that aren't live don't count.
Content is reachable through a generated GraphQL API (5). Publishing lands in staging, and going live is a separate promote step (6). Roles separate structure from content and can be scoped per content type (7). There are importers for WordPress and for any public site, by cloning it or scraping it, and every import lands in staging (8). An MCP server gives an agent the same operations the Studio uses, and a connection can be narrowed to read-only or to content only (9).
The honest "no" beyond self-hosting is breadth. Our app catalogue covers what most agency sites need, but it is nowhere near the size of WordPress's plugin directory. If a project depends on a specific plugin, Contentive vs WordPress is the fairer comparison to read first.
What this list won't tell you
It won't tell you whether your team will enjoy working in the tool. A CMS that scores well and that your developers dislike will be worked around, and the workarounds become the system. Run a small real project on a shortlisted tool before you standardise on it.
It also won't tell you about the client. Some clients want a website builder they can redesign themselves, and no checklist should talk you out of giving them one if that's the job.
Before your next pitch
Score the CMS you use today against these ten questions. Be as hard on it as you would be on a newcomer. If it fails two or more of the questions you picked as tiebreakers, that's the conversation to have before you sign the next client onto it, rather than after.