Choosing a CMS in 2026: the questions that matter
The ten questions that decide which content management approach fits a business, and the answers that point to files, a headless CMS or a platform.
The short answer
Choosing a content management system in 2026 is less about comparing products than about answering ten questions honestly. The first group is about people and rhythm: who edits, how often, with what approvals and in how many channels. The second is about ownership: where the content lives, whether you can export it and what happens when you leave. The third is about the site: a CMS must not decide the site’s speed, security or structure, which is why we keep editing separate from rendering, so the site stays static and fast whatever edits it. Feature lists come last. A business uses a fraction of any CMS’s features and pays for the rest in complexity, cost and maintenance. The answers point to one of three approaches: structured files in the repository, a headless CMS, or, for a narrower set of cases, a traditional platform.
The ten questions
| Question | Points to files | Points to headless CMS | Points to a platform |
|---|---|---|---|
| How many people edit? | One or two | Several, with roles | Several, invested in one admin |
| How often is content published? | A few times a month | Weekly to daily | Daily, editorial operation |
| Are approvals or scheduling needed? | Rarely | Yes | Yes |
| Does content feed more than the website? | No | Yes: apps, partners, channels | Rarely |
| How technical is the team or how close the partner? | Comfortable, or partner-mediated | Non-technical editors | Non-technical editors |
| Must content be exportable in an open format? | Inherently | Check the export | Often awkward |
| Where must content be stored? | Your repository | The vendor’s region; check residency | Your hosting’s database |
| May the CMS affect site speed and security? | It cannot | It does not, if rendering is separate | It does, heavily |
| What is the budget for content tooling? | Nothing | A subscription | Hosting plus maintenance |
| What happens when you change partner or CMS? | Nothing; files move | Export and remap | Rebuild |
Reaching a decision
- Answer the ten questions in writing, with the people who will actually edit.
- Count the answers in each column; the majority column is the starting point.
- Check the non-negotiables: export, previews, structured fields, accounts in your name, separated rendering.
- Trial the editing experience with a real page and a real editor, not a demo.
- Price three years of the tooling, including the time the team spends in it.
- Decide, and build the site so that the decision can change.
Our default and its exceptions
For a small business site we default to structured files in the repository with previews, because the editing team is small, the rhythm is monthly, ownership is total and the cost is nothing. We recommend a headless CMS when the team is larger, the rhythm is frequent or the content feeds several channels. We use a traditional platform as a whole site only when a business genuinely depends on its ecosystem and has an owner for its maintenance, which is rare.
What this means for you
Choose a CMS by answering who edits, how often, with what workflow and in how many channels, then by ownership and export, then by whether the CMS can affect the site’s speed and security. Keep editing separate from rendering so the choice is reversible. Files for small teams with a monthly rhythm, a headless CMS for larger or busier ones, a traditional platform only when the ecosystem is genuinely needed. The feature list is the last page to read, not the first.
Frequently asked questions
Is WordPress still a reasonable CMS choice?
For editing, its interface is familiar and its ecosystem is large. As a site platform, it brings a database, plugins, a security surface and maintenance that a business site does not need. Some businesses use it purely as a headless editing tool with the site rendered separately, which keeps the interface and drops most of the platform problems. As the whole site, it is the right choice for fewer businesses than use it.
Can we change CMS later without rebuilding the site?
If the site was built with editing separated from rendering, yes: the content is exported, the model is mapped, and the site fetches from the new source. If the site is the CMS, as with traditional platforms and page builders, changing CMS is a rebuild. That difference is the strongest argument for keeping the two separate from the start.
What should we insist on whatever we choose?
Content you can export in a structured, open format; previews of every change on the real site; structured fields rather than free-form layouts; accounts in your name; and a site whose speed and security do not depend on the CMS. Those five hold for files, headless and traditional platforms alike, and they are what makes a change possible later.