Solutions / CMS & Website Platforms
CMS & Website Platforms
CMS & Website Platform Solutions
The platform your website is built on decides who can change it, what it costs to keep running and how hard it is to leave. Start with what you are working on, see the main paths side by side and, where we list a suitable option, go to the provider when you are ready.
- Start from your situationFour business contexts
- Same criteria throughoutSeven dimensions for every option
- Trade-offs up frontWhat to watch for, stated plainly
Which area are you working on?
Choose the closest match. Each context sets out the questions to ask, the main solution paths and, where we list one, a suitable option.
Building or rebuilding a website
Choosing a platform for a new site, or deciding whether and how to move an existing one.
Publishing and updating content regularly
Making it easy to write, schedule and publish new content.
Managing website content with a team
Several people editing and publishing, with permissions and review.
Using content across multiple sites or channels
One body of content feeding a website and other places.
Find the solution that fits
Work through the context that matches yours. For the full decision, read the CMS & Website Platforms guide.
Building or rebuilding a website
You are starting a website, or weighing a rebuild or a move to another platform. A fresh look alone rarely justifies a rebuild. The real decision is who will run the site afterwards and what it needs to do. A platform that is quick to launch can limit control, tie you to its way of working or make it hard to take your content with you, so weigh maintenance, security and ownership before the first page is built.
More about this context
You are starting a website, or weighing a rebuild or a move to another platform. A fresh look alone rarely justifies a rebuild; the decision is mostly about who will run the site afterwards and what you need it to do.
Choosing only for launch speed can feel sensible at the start and cost you later. A platform that is quick to launch may limit control over structure and design, tie you to its way of working, or make it hard to take your content with you. Maintenance, security and ownership are worth weighing before the first page is built.
How the paths differ
A hosted website builder bundles platform, hosting, editor and templates, which is the quickest route and the least upkeep, with the least control and portability. A traditional CMS, run by you or a partner, gives the widest range of themes, extensions and developers and puts maintenance on whoever runs it. A planned platform move is a different decision again: it is a project with an inventory, a test import, redirects and a staging copy, not just a change of tool.
Supporting detail
Questions to ask yourself. 5 questions to settle first
- Who will run the site after launch?
- How much control do you need over structure, design and custom features?
- How quickly do you need to launch?
- If you already have a site, what is actually wrong with it: upkeep, security, cost or a missing capability?
- What can you export from where you are now?
Why this decision matters. What is at stake
The platform decides who carries updates, security and hosting, how portable your content is and how much you can change later. Choosing only for the launch date can leave you with limits you meet again later.
Four things tend to matter later: control (how far you can change structure, design and features), maintenance (who keeps the platform updated and secure), exportability (what you can take with you, and in what form) and ownership (whose account holds the domain, the hosting and the content).
Before choosing. A short checklist
- Check what you can export: builders are often the least portable option
- Keep your domain and DNS registered in your own account
- Layout tools can store content in their own markup, so test an export and import before you build hundreds of pages
Want the full background? Choose a path: three questions
Choose the path that fits
Select a path to see why it fits and what to watch for.
Hosted website builder
Platform, hosting, editor and templates come as one service.
Best fit
- Small sites
- Nobody technical on the team
Main thing to check
What you can export
A traditional CMS you or a partner manage
A CMS with themes and plugins, run by you, a host or an agency.
Best fit
- Custom features
- Technical help available
Main thing to check
Who handles updates and security
A planned move to another platform
A project with an inventory, a test import, redirects and a staging copy.
Best fit
- A platform that now holds you back
- Content you can inventory
Main thing to check
What exports, and in what format
Selling online is the main goal
An ecommerce platform rather than a general website platform.
Best fit
- Selling online is the main goal
Main thing to check
Who runs checkout and payments
Hosted website builder
Why choose it
- Quickest to launch, with the least upkeep to carry
- The platform handles updates and security
- A predictable set of features
Best when
- There is nobody technical to maintain the site
- Speed of launch matters more than full control
Watch for
- Check what you can export: builders are often the least portable option
- Check what each plan caps: pages, storage, bandwidth and apps
Full decision detail
Why it helps
- Quickest to launch, with the least upkeep to carry
- The platform handles updates and security
- A predictable set of features
Fits when
- There is nobody technical to maintain the site
- Speed of launch matters more than full control
- The site is small and the design can sit within templates
Watch for
- Check what you can export: builders are often the least portable option
- Check what each plan caps: pages, storage, bandwidth and apps
- See how the price changes as you add features
- You work within the platform’s limits on structure and code
The platform, hosting, editor and templates come as one service, so you configure the site instead of running it.
When you may need more. If you need custom features, a specific structure, several editors or an easy way to leave, a traditional CMS or a custom build is more suitable.
A traditional CMS you or a partner manage
Why choose it
- The widest range of themes, extensions and developers
- Full control over structure and design
Best when
- You need custom features or a specific structure
- You can rely on technical help, in-house or from a partner
Watch for
- Updates, security and performance are yours unless you buy them as a managed service
- Plugin sprawl and abandoned extensions are a common risk
Full decision detail
Why it helps
- The widest range of themes, extensions and developers
- Full control over structure and design
Fits when
- You need custom features or a specific structure
- You can rely on technical help, in-house or from a partner
Watch for
- Updates, security and performance are yours unless you buy them as a managed service
- Plugin sprawl and abandoned extensions are a common risk
A content management system with themes and plugins, run by you, a host or an agency, for sites that need flexibility in structure, design or custom features.
A traditional CMS keeps content and presentation in one application, extended with themes and plugins. It gives the most flexibility and the largest pool of developers and extensions. The software may be free, but hosting, extensions and developer time are not, and plugin sprawl and abandoned extensions are a common risk.
When you may need more. If nobody can maintain it, a hosted builder or a managed or agency-run service carries less risk.
A planned move to another platform
Why choose it
- Redirects protect your search visibility
- A test import shows what will not carry over
- A staging copy lets you check everything before launch
Best when
- Maintenance, security, cost or missing capability now outweigh the cost and risk of moving
- You can inventory what you have and decide what to keep, merge or retire
Watch for
- Do not replatform for its own sake
- Check what exports and in what format: pages, media, redirects, form entries and design all move differently
Full decision detail
Why it helps
- Redirects protect your search visibility
- A test import shows what will not carry over
- A staging copy lets you check everything before launch
Fits when
- Maintenance, security, cost or missing capability now outweigh the cost and risk of moving
- You can inventory what you have and decide what to keep, merge or retire
Watch for
- Do not replatform for its own sake
- Check what exports and in what format: pages, media, redirects, form entries and design all move differently
- Keep your domain and DNS registered in your own account
- Layout tools can store content in their own markup, so test an export and import before you build hundreds of pages
Inventory your content and addresses, test an export and import before committing, map every old address to its new one with permanent redirects, build and test on a staging copy, then launch and monitor.
A rebuild or move is worth doing when maintenance effort, security risk, cost or a missing capability now outweigh the cost and risk of moving. Inventory your content and addresses, test an export and import, map every old address to its new one with permanent redirects, build and test on a staging copy, then launch and monitor. Keep your domain and DNS registered in your own account.
Selling online is the main goal
Best when
- Selling online is the main goal of the site
Watch for
- Hosted and self-hosted shop platforms differ in who runs checkout, security and payments
Full decision detail
Fits when
- Selling online is the main goal of the site
Watch for
- Hosted and self-hosted shop platforms differ in who runs checkout, security and payments
An ecommerce platform rather than a general website platform: the choice then also covers payments, tax and fulfilment.
Compare the main paths
Show the comparison. The paths side by side
| What to look at | Hosted website builder | Traditional CMS |
|---|---|---|
| Who runs it | The platform vendor | You, a host or an agency |
| Upkeep | The platform handles updates and security | Yours, unless you buy it as a managed service |
| Best suited to | Small sites within templates | Custom features or a specific structure |
| Control and portability | Within the platform’s limits; export is often limited | Full control over structure and design |
| Main thing to check | What you can export and what each plan caps | Plugin sprawl and abandoned extensions |
See full comparison
| What to look at | Hosted website builder | Traditional CMS |
|---|---|---|
| What it costs | See how the price changes as you add features | Software may be free; hosting, extensions and developer time are not |
No option listed yet
We’re currently reviewing suitable options for this area.
Publishing and updating content regularly
You add pages, articles or updates on a regular schedule, and publishing should not depend on a developer. Occasional edits, such as an opening time or a price, need very little. Regular publishing needs drafts, scheduling, categories, images, several authors and a library that can grow to hundreds of pages. As the volume grows, the editing experience, how content is structured and how easily it can be moved matter more than the feature list.
More about this context
You add pages, articles or updates on a regular schedule, and publishing should not depend on a developer. The editing experience matters as much as the platform’s feature list.
Occasional editing, such as changing opening hours or a price, needs very little. Regular publishing is different: drafts, scheduling, categories, images, several authors and a library that grows into hundreds of pages. The editing experience, how content is structured and how easily it can be moved matter more as the volume grows.
How the paths differ
The editor in a hosted website builder is the simplest: nothing to install, a predictable feature set, and limits on structure and export. The editor in a traditional CMS is more flexible, with roles, scheduling, custom content types and extensions, and with the upkeep that implies. For large libraries, structured content and an editorial workflow save time; for small sites they are more than you need.
Supporting detail
Questions to ask yourself. 4 questions to settle first
- Who publishes, and how technical are they?
- Do you need drafts, previews and scheduling?
- How much control do the pages need over structure and design?
- Will the content grow to hundreds of pages?
Why this decision matters. What is at stake
A clumsy editing workflow makes publishing slower and more error-prone. A large content library can also expose limits in structure, search and performance that a small site never meets.
Four things separate the approaches: how structured the content is (pages versus reusable fields), whether there is an editorial workflow (drafts, review, approval), how dependent you are on a developer for routine changes, and how portable the content is if you change platform later.
Before choosing. A short checklist
- Try the editor with the person who will use it every week
- Check how content is structured and whether it can be exported
- Check previews, scheduling and revision history
Want the full background? The trade-offs side by side
Choose the path that fits
Select a path to see why it fits and what to watch for.
Built-in editor in a hosted website builder
A built-in page and blog editor that comes with the hosted service.
Best fit
- Occasional publishing
- Small sites
Main thing to check
Limits on structure and export
Editor and publishing workflow in a traditional CMS
An editor with roles, scheduling and extensions you can add.
Best fit
- Regular publishing
- Large libraries
Main thing to check
Who keeps the platform updated
Built-in editor in a hosted website builder
Why choose it
- Nothing to install or maintain
- A predictable set of editing features
Best when
- The site is small and you publish occasionally
- The design can sit within templates
Watch for
- Structure, custom content types and export are limited by the platform
Full decision detail
Why it helps
- Nothing to install or maintain
- A predictable set of editing features
Fits when
- The site is small and you publish occasionally
- The design can sit within templates
Watch for
- Structure, custom content types and export are limited by the platform
A built-in page and blog editor that comes with the hosted service.
The editor that comes with a hosted website builder suits a small site where changes are occasional and the design can sit within templates. It is quick to learn and needs no maintenance. Limits appear with custom content types, larger libraries and export.
When you may need more. If you publish often, have several authors, need an approval step or want to keep the content portable, a traditional CMS editor is more suitable.
Editor and publishing workflow in a traditional CMS
Why choose it
- Flexible content structures and extensions
- Suits regular, higher-volume publishing
Best when
- You publish often or have a large library
- You need specific page types or workflows
Watch for
- Updates, security and performance are yours unless you buy them as a service
Full decision detail
Why it helps
- Flexible content structures and extensions
- Suits regular, higher-volume publishing
Fits when
- You publish often or have a large library
- You need specific page types or workflows
Watch for
- Updates, security and performance are yours unless you buy them as a service
A content management system with an editor, roles, scheduling and extensions you can add.
The editor in a traditional CMS handles drafts, scheduling, categories and several authors, and can be extended with custom content types and editorial workflows. It scales to large libraries and gives developers room to adapt it. Someone has to keep the platform updated and the editing experience tidy.
When you may need more. If content must feed several sites or channels, look at structured or headless content.
Compare the main paths
Show the comparison. The paths side by side
| What to look at | Builder editor | CMS editor |
|---|---|---|
| Set-up and upkeep | Nothing to install or maintain | Someone has to keep the platform updated |
| Publishing features | A predictable set of editing features | Drafts, scheduling, categories and several authors |
| Best suited to | A small site with occasional changes | Frequent publishing or a large library |
| Structure | Limited by the platform | Custom content types and editorial workflows |
| Main thing to check | Custom content types, larger libraries and export | Updates, security and performance |
No option listed yet
We’re currently reviewing suitable options for this area.
Managing website content with a team
Several people publish and edit, and the site needs flexibility in structure, design or custom features. That usually calls for a platform that you or a partner run, which brings updates and security with it. With several editors the question moves from how to publish to who may publish what, and who checks it first. Roles, review and a consistent structure start to matter more than the editor itself.
More about this context
Several people publish and edit, and the site needs flexibility in structure, design or custom features. That usually calls for a platform that you or a partner run, which brings updates and security with it.
With several editors, the questions change from “how do I publish?” to “who may publish what, and who checks it first?”. Roles, review and a consistent structure start to matter more than the editor itself.
How the paths differ
A traditional CMS provides roles, editorial workflow and custom structures, and it needs someone to maintain it. A managed or agency-run CMS gives the same kind of platform with the upkeep taken on by a host or agency, so the team can concentrate on content, at the cost of depending on that partner.
Supporting detail
Questions to ask yourself. 4 questions to settle first
- How many people edit, and with what permissions?
- Is an approval step needed before anything is published?
- Do you need custom page types or structured content?
- Who maintains the platform and its extensions?
Why this decision matters. What is at stake
With several editors, permissions, review and a clear content structure decide whether the site stays consistent. Updates, security and performance remain someone’s job whoever edits.
Before choosing. A short checklist
- Updates, security and performance are yours unless you buy them as a managed service
- Plugin sprawl and abandoned extensions are a common risk
- The quality of the hosting underneath matters (see the Hosting Guide)
- The software may be free, but hosting, extensions and developer time are not
Want the full background? The trade-offs side by side
Choose the path that fits
Select a path to see why it fits and what to watch for.
Traditional CMS with team roles and workflows
Content and presentation in one application, extended with themes and plugins.
Best fit
- Many editors
- Custom features
Main thing to check
Who handles updates and security
A managed or agency-run CMS
The same kind of platform, with a host or agency taking on the upkeep.
Best fit
- No one in-house to maintain it
- Several editors
Main thing to check
The partner’s quality and responsiveness
Traditional CMS with team roles and workflows
Why choose it
- The widest range of themes, extensions and developers
- Full control over structure and design
- Suits several editors and custom features
Best when
- A content-rich site with many editors
- You need custom features or a specific structure
Watch for
- Updates, security and performance are yours unless you buy them as a managed service
- Plugin sprawl and abandoned extensions are a common risk
Full decision detail
Why it helps
- The widest range of themes, extensions and developers
- Full control over structure and design
- Suits several editors and custom features
Fits when
- A content-rich site with many editors
- You need custom features or a specific structure
- You can rely on technical help, in-house or from a partner
Watch for
- Updates, security and performance are yours unless you buy them as a managed service
- Plugin sprawl and abandoned extensions are a common risk
- The quality of the hosting underneath matters (see the Hosting Guide)
- The software may be free, but hosting, extensions and developer time are not
A traditional CMS (content management system): content management and page presentation live in one application that you or a host runs, extended with themes and plugins. Managed hosting or an agency can take on the upkeep.
A managed or agency-run CMS
Why choose it
- Updates, security and performance are handled for you
Best when
- There is no one in-house to maintain the platform
- You still need several editors and custom features
Watch for
- You depend on the partner’s quality and responsiveness
- The software may be free, but the service and developer time are not
Full decision detail
Why it helps
- Updates, security and performance are handled for you
Fits when
- There is no one in-house to maintain the platform
- You still need several editors and custom features
Watch for
- You depend on the partner’s quality and responsiveness
- The software may be free, but the service and developer time are not
The same kind of platform, with managed hosting or an agency taking on the upkeep.
Compare the main paths
Show the comparison. The paths side by side
| What to look at | Traditional CMS with team roles and workflows | Managed or agency-run |
|---|---|---|
| Who runs it | You or a host | A managed host or an agency |
| Upkeep | Yours, unless you buy it as a managed service | Updates, security and performance handled for you |
| Best suited to | A content-rich site with many editors | Teams with no one in-house to maintain the platform |
| What you depend on | Technical help, in-house or from a partner | The partner’s quality and responsiveness |
| Main thing to check | Plugin sprawl and the quality of the hosting | What the service and developer time cost |
No option listed yet
We’re currently reviewing suitable options for this area.
Using content across multiple sites or channels
The same content has to feed a website and other places, such as apps or other sites, or you want a fully custom front end. This is a larger build with more moving parts. Content is managed as structured data in one place and presented by separate front ends, which saves duplication but changes how the work is organised. It suits larger or more technical set-ups.
More about this context
The same content has to feed a website and other places, such as apps or other sites, or you want a fully custom front end. This is a larger build with more moving parts.
Reusing content across a website, an app and other sites saves duplication, but it changes how the work is organised: content is managed as structured data in one place and presented by separate front ends. It suits larger or more technical set-ups.
How the paths differ
A headless CMS stores content in a back end and delivers it by API to front ends you build and host separately; it is the most flexible and the most to build. One platform running several sites is lighter: related sites share a platform, users and updates, with less duplication than separate installations, and a fault can affect all of them.
Supporting detail
Questions to ask yourself. 4 questions to settle first
- Which sites, apps or channels must the same content feed?
- Do you want a fully custom front end?
- Do you have developers for two systems?
- How will editors preview content before it goes live?
Why this decision matters. What is at stake
Reusing content across channels saves duplication, but it adds moving parts. The decision is about who builds and maintains the front end, and how editors work with content they cannot see on a page.
Before choosing. A short checklist
- More to build and more to keep running: both systems need maintenance
- It has the longest time to launch
- The editing experience depends on the build, so live preview has to be provided
- You depend on developers
Want the full background? Choose a path: three questions
Choose the path that fits
Select a path to see why it fits and what to watch for.
Headless CMS
Content in a back end, delivered by API to front ends you build separately.
Best fit
- One body of content, many channels
- Bespoke front ends
Main thing to check
Two systems to maintain
One platform running several sites
Related sites share one platform, its users and its updates.
Best fit
- Related sites
- Shared editors
Main thing to check
A bad update can affect every site
Headless CMS
Why choose it
- Content can be reused across sites, apps and other channels
- You choose the front-end technology
- The front end can be fully custom
Best when
- One body of content must feed several channels
- You want a bespoke front end
Watch for
- More to build and more to keep running: both systems need maintenance
- It has the longest time to launch
Full decision detail
Why it helps
- Content can be reused across sites, apps and other channels
- You choose the front-end technology
- The front end can be fully custom
Fits when
- One body of content must feed several channels
- You want a bespoke front end
- You have technical capacity, or an agency, for two systems
Watch for
- More to build and more to keep running: both systems need maintenance
- It has the longest time to launch
- The editing experience depends on the build, so live preview has to be provided
- You depend on developers
A headless CMS: a back-end content repository delivers content through APIs to a front end that you build and host separately.
One platform running several sites
Why choose it
- Shared users, themes and updates across sites
- Less duplication than separate installations
Best when
- The sites are related and share structure or editors
Watch for
- A fault or a bad update can affect every site at once
- Check how content can be shared or kept separate between sites
Full decision detail
Why it helps
- Shared users, themes and updates across sites
- Less duplication than separate installations
Fits when
- The sites are related and share structure or editors
Watch for
- A fault or a bad update can affect every site at once
- Check how content can be shared or kept separate between sites
A single content platform that runs several related websites from one installation or account.
Compare the main paths
Show the comparison. The paths side by side
| What to look at | Headless CMS | Multi-site platform |
|---|---|---|
| How it works | A back end delivers content by API to separate front ends | One installation or account runs several sites |
| Reuse | Content reused across sites, apps and other channels | Shared users, themes and updates across sites |
| Best suited to | Larger or more technical set-ups | Related sites that share structure or editors |
| Effort | More to build and keep running; longest time to launch | Less duplication than separate installations |
| Main thing to check | Live preview has to be provided | A bad update can affect every site |
No option listed yet
We’re currently reviewing suitable options for this area.
Want to know what sits behind each option? See how we evaluate CMS platforms