Choosing a CMS: Twelve Questions That Separate the Shortlist

Three demos are booked, a spreadsheet of features exists, and every column in it says yes. That spreadsheet will not decide anything, because vendors have been reading each other’s feature lists for a decade and have converged. The differences that will matter to you in year two are not on the list, and none of them come up unless somebody asks a question the demo was not built to answer.

So most advice on how to choose a CMS is aimed at the wrong target. Do not compile capabilities. Compile disqualifiers: the twelve answers that should make you close the tab. Every question below has one, and they are ordered by how expensive the mistake is to unwind later. Question one is first because it is the only one that gets harder to ask the longer you leave it.

This assumes you have already settled the shape of the thing, which is a separate argument covered in headless CMS or traditional. What follows works either way, because these questions are about ownership, permissions and modelling rather than architecture.

Why every feature matrix agrees

A feature can be true and useless at the same time. "Supports localisation" covers both a system that models a translation as a first-class variant of an entry and a system where you duplicate the page and hope somebody remembers to update both. "Role-based permissions" covers real per-section scoping and also two roles called admin and editor. "Version history" covers a permanent diff and also the last handful of saves, held for a fortnight, on a plan above yours.

The vendor is not lying. The word is doing work the word cannot carry. Every question in this article is written to defeat that: it asks what happens, not whether something is supported, and it names the answer that should end the meeting.

The twelve, and what should disqualify a vendor

Questions 1 and 2: leaving, before you arrive

Ask about the exit first, while you are still a prospect and the answer costs the vendor something to fudge. Asked in year three, the same question is a negotiation you have already lost.

What the export actually contains

Do not read the documentation. Run one during the trial, on content you created, and open the file. Look for every field you defined, the relationships between entries, the draft states, and whether rich text comes back as structured content or as a wall of markup. An export that returns rendered HTML is technically an export and practically a hostage situation, which is the argument in why you should stop storing content as HTML.

The alternative model avoids the question entirely. A structured workspace such as Acrosite generates the required files, commits them to GitHub and triggers the configured deployment, so the content was never anywhere you would need to retrieve it from. Whether that suits you is a storage decision rather than a features decision, and we have set out both sides in Git-backed or API-backed.

Who owns the media

Media is where lock-in hides. Ask whether you receive the original uploads rather than transformed derivatives, whether alternative text and captions travel with them, and whether the URLs in your content point at the vendor’s domain. If every image on your site resolves through their infrastructure, cancelling the contract breaks every page you have ever published, and that is a fact you want to know in week one rather than during a renewal call.

Questions 3 to 5: the content model decides everything after it

One big field is not a model

Take one real page type from your site, the fiddliest one, and model it in each system during the trial. A service page is usually a title, an intro, a set of feature blocks, a price band, three proof points, a set of frequently asked questions and a call to action. If the only way to build that is to paste everything into a single body field, the system has quietly transferred the design to whoever types fastest, and every future redesign becomes manual reformatting rather than re-rendering.

This is also where search work lives or dies. Fields you can address individually are fields you can render into structured data, canonical tags and consistent headings. A single free-text blob is not addressable, so every technical SEO fix becomes a manual pass over hundreds of pages.

References, and fields that are genuinely required

Content refers to other content constantly: an article has an author, a service belongs to a pillar, a case study points at an industry. If those relationships are pasted URLs rather than real references, nothing can be validated, nothing updates when a slug changes, and every listing page becomes hand-maintained. Ask what the API returns for a reference, because a system that gives you an identifier and nothing else pushes a second request into every render.

Then ask what "required" means. A field marked required in the interface but not enforced at publish is a suggestion. The distinction matters most for the fields nobody enjoys filling in: meta description, alternative text, canonical intent. If the system cannot refuse a publish, your content operation will spend its life chasing them after the fact.

Questions 6 to 8: who can do what, and what is remembered

Every organisation eventually needs one person who can edit the pricing page and twelve who cannot. If the permission model cannot express that, you will express it socially instead, with a rule everybody knows and nobody enforces, until the afternoon somebody publishes a draft to the live site.

A gate that can actually say no

Workflow states are decoration unless a named person can refuse, and unless that refusal stops the change reaching production. Ask to see it happen in the demo: put an entry in review, decline it, and watch what the deployment does. Our parent company sets out how draft states and gates fit together in where drafts live and what stops them, which is worth reading before you sit through the workflow section of a demo.

History is the same question pointed backwards. On a legally sensitive page, "who approved this wording, and when" has to have an answer that survives the person leaving. Version history that keeps a handful of saves for a fortnight cannot produce it, and neither can a plan you are not on. The retention matters more than the interface.

Every question here is the same question in different clothes: what happens on the day you and the vendor disagree?

Questions 9 to 11: the editor’s ordinary day

Preview is the adoption question

A system nobody wants to use is a system that gets bypassed, and the fastest route to that outcome is preview that does not resemble the site. An editing panel with grey boxes is not preview. Preview means an unpublished change rendered through the real templates, at a URL a colleague can open, without a developer running anything locally.

• Real templates, real breakpoints. If the editor cannot check the change at a phone width, the mobile layout will be discovered by customers.
• Shareable, and access-controlled. Approval happens in whatever tool your reviewers already open. A preview nobody else can see is a private rehearsal.
• No developer in the loop. If seeing a draft requires someone to run a command, drafts will stop being previewed by the second month.
• Honest about what is not final. Scheduled entries, unresolved references and missing translations should be visible as gaps rather than silently rendered empty.

Localisation decided late is expensive

If a second language is even a possibility, model it now. The question is whether a translation is a variant of one entry, carrying the same identifier and structure, or a duplicate page with its own life. Duplicates drift within a quarter. Ask specifically what happens when the source language is updated and one translation is behind: does the site fall back to the source, show a stale version, or render a hole?

The limits nobody mentions

Hosted systems have ceilings: requests per minute, entries returned per call, payload size, number of environments, webhook frequency, how deeply references resolve in one query. None of these appear in a demo because a demo has ten entries. Ask what each limit is, and then ask the more useful second question: what happens when we cross it? A queue is an inconvenience. A hard failure during a build is an outage with your name on it.

Question 12: draw the price curve, not the price

The quoted price is for the shape you are today. Ask the vendor to price the shape you expect in three years: more entries, more editors, another language, a second environment, a partner who needs read access. Then ask which of those steps changes the plan tier rather than the line item, because tier changes are where the surprises live.

Watch for pricing that meters something you cannot control. Charging per editor is predictable, because you decide how many editors exist. Charging per API request is not, because a traffic spike, a crawler or a badly cached page can generate it. When a supplier bills on a number your own marketing success increases, the incentives are pointed away from you.

How to run this in a fortnight

The questions are cheap. Running them badly is not, so keep the sequence tight and put the same real work through every candidate.

1. Model your hardest page type first, on paper. Fields, relationships, what is required. An hour of this eliminates half a shortlist before any trial starts.
2. Send questions 1, 5, 7, 11 and 12 in writing. Written answers behave differently from spoken ones, and they survive the salesperson changing role.
3. Build that page type in the two strongest trials. Not a blog post. The awkward one, with the repeating blocks and the references.
4. Put a real editor in front of it, unaccompanied. Ask them to publish a change and revert it. Watch without helping. This is the most informative twenty minutes of the whole exercise.
5. Run the export and open the file. Every field, every relationship, the media, the alternative text. Reading about the export is not the same as having it.
6. Decide, and write down what would make you wrong. One paragraph, filed where the next team can find it. Most CMS regret is really a decision nobody recorded the reasoning for.

One concession, because this article has been strict throughout. If you run a small brochure site, edited by one person, changing a few times a year, most of this is overhead you do not need. Pick something ordinary and well supported, make sure you can get your content back, and spend the saved effort on the site itself. The twelve questions earn their keep when several people publish, when the content model is not trivial, and when the site is expected to outlive the team that built it.

Whatever you choose, the day after launch is when the real assessment begins, and we have written about what a workspace has to keep doing from then on in what a content workspace should do the day after launch. If you are stuck between two finalists, tell us what you are comparing and which of the twelve answers you did not like.