The question “which CMS should I choose” is asked backwards nine times out of ten. It is about technology when it should be about people: who will write, how often, and with what level of technical comfort.
A powerful CMS handed to someone who will never touch it is a recurring cost with no return. A frozen site handed to someone publishing three times a week is a bottleneck.
The question to ask before any other
How many times a month will the content change, and by whom? The answer determines almost everything else.
A ten-page site edited twice a year needs no CMS at all: the maintenance and security cost of a back office far exceeds the convenience it brings. A blog fed three times a week by a non-technical person absolutely needs one.
| Update frequency | Who edits | Suitable solution |
|---|---|---|
| A few times a year | The supplier | Static pages, no back office |
| Once or twice a month | The owner | Light CMS or targeted editable zones |
| Several times a week | A team | Full CMS with roles and drafts |
| Continuously, multi-channel | An editorial team | Headless with an API |
WordPress: what it is good at, and what it costs
WordPress runs a considerable share of the web for good reasons: a familiar interface, a huge ecosystem, a low entry cost, and a deep pool of people able to work on it.
The real cost is not at install, it is over time. Every plugin adds a dependency to maintain and an attack surface. A WordPress site left unupdated for a year is a compromised site waiting to happen.
- Choose it if: several people publish, you want to be able to change supplier, the initial budget is tight.
- Avoid it if: nobody will handle updates, or performance is critical with no optimisation budget.
- Either way: budget maintenance from the start, not after the first incident.
Headless: when it is genuinely justified
The principle is to separate content management from its display: content lives in an API, and one or several front ends consume it.
It is excellent when the same content genuinely feeds several channels — website, mobile app, in-store screens, partners. It is free complexity when there is only one site at the end.
The headless trap
Two systems to maintain instead of one, often poor preview before publishing, and dependence on a third-party service whose pricing can change. Do not choose it because it is modern; choose it because you have several channels.
Custom: less exotic than it sounds
A custom-built site, with no heavy framework, is often the fastest and most durable option for a brochure site or a content site with a stable structure. No abstraction layer, no plugins to update, no inherited attack surface.
Its weakness is real and worth naming: with no back office, every change goes through someone technical. The answer is not to bolt on a full CMS, but to make editable only the zones that actually change.
An often-ignored middle path
Content in structured, version-controlled files, with an editing interface limited to the blocks that move. You keep static speed and the ability to change what matters, with no back office to secure.
The five-year total, not the quote
The advertised price of a site is the price of its first year. Over five years the cost structure shifts towards hosting, maintenance, plugin licences and the fixes that follow major version upgrades. That total is what you should compare, not the opening quote.
A properly maintained WordPress site costs between £500 and £1,500 a year in outsourced maintenance, plus £130 to £500 a year in licences if the site relies on paid plugins — advanced forms, custom fields, internal search, backups. Those licences are not optional: a plugin whose subscription lapses stops receiving security fixes.
| Option | Build | Annual running cost | Five-year total |
|---|---|---|---|
| Online site builder | £0 to £1,250 | £170 to £500 | £850 to £3,800 |
| Custom WordPress | £3,400 to £10,000 | £700 to £2,000 | £6,800 to £20,000 |
| Headless (hosted CMS + front end) | £10,000 to £25,000 | £1,000 to £3,400 | £15,000 to £42,000 |
| Custom with no back office | £2,500 to £8,400 | £130 to £500 | £3,200 to £11,000 |
These ranges overlap, and that is the point: no option is structurally cheaper. The online builder is the least expensive as long as you stay inside its boundaries, and the most expensive the day you leave, because the rebuild starts from nothing. Custom without a back office is low on running cost but bills every change by the day: expect £340 to £600, and check your change rate does not exceed three or four days a year.
One line item is almost always forgotten: major version upgrades. Moving from one major CMS release to the next takes half a day to five days depending on plugin count and whether a customised child theme is in play. Provisioning that spend once every three years avoids the familiar outcome — a site stuck on an obsolete version because the upgrade was never budgeted.
Security: who exactly answers for it
Security is settled by contract as much as by technology. On a WordPress site four parties are involved: the host for the server, the CMS publisher for the core, plugin authors for their code, and the supplier for applying fixes. If nobody has signed up for that last role, it is not covered.
The overwhelming majority of compromises do not exploit a flaw in the WordPress core but an unpatched plugin or a poorly protected administrator account. Timing matters: a publicly disclosed flaw is exploited by automated scanning within days of the fix being released. A contract promising “monthly” updates therefore leaves a three to four week window open.
- The deadline for critical patches: 72 hours is a commitment that can be held; “as soon as possible” is not one.
- Backup frequency and retention, and above all where backups live — a backup on the same server as the site protects against nothing.
- Restore time after an incident, and who is allowed to trigger it.
- What sits outside scope: cleaning a compromised site is billed separately, £420 to £1,700 depending on how far the infection spread.
Custom builds with no database and no back office shrink the attack surface, they do not remove it: the server, the contact form and system dependencies remain. The difference is the volume of third-party code you depend on without knowing it. Fewer dependencies is not invulnerability, it is a monitoring workload divided by five or ten.
Migrating between CMS platforms: the real cost
Changing CMS is not a matter of moving text across. The cost concentrates in three items rarely priced up front: URL mapping, template reconstruction, and recovering content that never existed in structured form.
| Starting point | Content recovery | Estimated effort |
|---|---|---|
| WordPress with structured content | XML export and REST API | 3 to 6 days |
| Proprietary CMS with an export | Partial CSV or JSON | 6 to 12 days |
| Visual page builder | No usable structure | Full rewrite |
| Version-controlled static site | Files already structured | 1 to 3 days |
The most underestimated item is the redirect plan. An 80-page site changing its structure needs 80 permanent redirects checked one by one. Without them the organic traffic loss is immediate and takes six to twelve months to recover. Budget half a day to a day for a site that size, more if the old addresses contain numeric identifiers with no readable logic.
Second item: hand-formatted content. An article whose structure lives in HTML pasted in as it went does not convert automatically. Across fifty articles, manual rework runs to two or four days. This is why a site built with a visual builder is rarely migrated: it is rebuilt.
A useful order of magnitude: migrating a 30 to 60 page brochure site sits between £2,100 and £5,000, redirects and testing included. Below that, some of the work has not been priced — usually the testing and the redirects, which is precisely what protects the rankings you already have.
Page builders: lock-in is the business model
A visual page builder — WordPress plugin or full platform — stores the layout in its own format. The text stays readable, the structure does not. Deactivate the plugin and the page collapses into a block of markup that is unusable as it stands.
This is not a design flaw, it is the model. A tool you can leave easily is a tool you can replace easily. The exit cost is part of the product, and it is rarely mentioned at purchase.
Lock-in has a second, quieter effect: the markup is imposed on you. You choose neither the heading hierarchy, nor the weight of CSS loaded on every page, nor the number of nested containers. On a content site this weighs on Core Web Vitals and on accessibility, two subjects that can only be fixed by leaving the tool.
The test to run before signing
Ask for a page exported exactly as the tool would produce it, and see whether its content is recoverable without the tool. If the answer is “you'd need a plugin for that”, you have just learned the price of leaving.
None of this disqualifies these tools. For a charity putting an event page together in two hours, lock-in is an acceptable cost. It becomes a problem once the site carries organic traffic built over several years: the rebuild is no longer a website project, it is a website project plus a rankings recovery, and the second often outweighs the first.
Accessibility: what the CMS does not solve
Accessibility has stopped being an optional good practice for everyone. In France the reference framework is the RGAA, derived from the WCAG, and it is what auditors work from. It has long applied to public bodies and to companies above a high turnover threshold.
The scope widened with the European accessibility framework, applicable since June 2025 to services such as online retail, banking and passenger transport, with an exemption for micro-enterprises. If you sell online and employ more than ten people, this concerns you directly; otherwise it remains a quality argument rather than an obligation.
The CMS does not make a site accessible, and none makes it inaccessible on its own. What decides is the theme and how content is entered. The most common failures are technology-independent: insufficient contrast, decorative images without an empty alt attribute, form fields with no associated label, headings chosen for their size rather than their level, interactive components unusable from the keyboard.
The economics are clear: building accessibility in from the design stage adds roughly 10 to 15% to the initial budget. Retrofitting it onto an existing brochure site is a £2,500 to £6,700 project, theme rework included, because it usually means touching structure and not just colours.
Overlays promising automatic compliance through JavaScript do not produce compliance. They patch a few attributes at runtime without addressing structure or content quality — and those are exactly the two things an audit examines.
The criterion nobody looks at: getting out
Before choosing, ask how you get your content back if you change your mind. Is there a clean, documented export? In what format? Are images included?
A solution you cannot leave easily eventually dictates its terms. That is a selection criterion at least as important as the feature list.
Key points
- Publishing frequency and editor profile decide, not technology.
- Compare five-year totals, not first-year quotes: the ranges overlap.
- WordPress is a good choice if maintenance is budgeted and contracted from day one.
- Security rests on a written patch deadline, not on a technology.
- Headless is justified by channel count, not by modernity.
- A visual page builder gets rebuilt, not migrated: put that cost in the calculation.
- Accessibility costs 10 to 15% at design time and two to three times more afterwards.
- Always check how you get out before you go in.
FAQ — Choosing a CMS
Is WordPress bad for SEO?
No. Properly configured WordPress ranks very well. What hurts rankings is overloaded themes and plugin accumulation, not the CMS itself.
Can you migrate from one CMS to another later?
Yes, but the cost depends entirely on how the content is stored. Migrating from a system with a clean export takes a few days; from a proprietary page builder it often means rewriting everything.
What budget for each option?
Custom WordPress: £3,200 to £9,500, plus £40 to £120 a month maintenance. Headless: £9,500 to £24,000, plus the service subscription. Custom with no CMS: £2,400 to £8,000, marginal maintenance.
Can an online site builder be enough?
For a simple, temporary presence, yes. The limits show up in performance, markup control and above all portability: you generally cannot take the site elsewhere.
Will another supplier be able to take the site over?
It comes down to three things, all worth checking before you sign: who holds the hosting and domain credentials, whether the code is version-controlled and handed over, and whether the technical decisions are documented. A standard WordPress site is picked up in a few hours; a custom site with no repository and no documentation costs two to five days of reverse engineering before the first change.
Does accessibility compliance require a particular CMS?
No, the CMS barely matters. Compliance is decided by the theme, the heading hierarchy, contrast, form labels and how content is entered. A WordPress site with a restrained theme can be compliant; the same site running a visual page builder rarely is.
Sources
- Google — SEO Starter Guide — what the engine expects
- web.dev — Core Web Vitals — LCP, INP, CLS thresholds
- RGAA — French accessibility framework — criteria and audit method
- Google — Redirects and site moves — what a URL migration requires
Which CMS fits your situation?
Tell me who publishes, how often, and at what technical level. I'll tell you which option holds up over five years — and which will cost you.
Describe my situation