Guides / CMS & Website Platforms

Decision guide

CMS & Website Platforms

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. This guide explains the main platform models, gives you a question-led path to choosing between them, and lists the trade-offs to check before you commit.

  • Five situationsEach with a way into Solutions
  • About 11 minutes11 sections, jump to any
  • Informational guideNot personalised advice

The short answer

Pick the model by who will run the site, not by which template looks best. Start with the closest match, then confirm it with the path and trade-off table below.

You need a simple site and nobody technical to maintain it

A hosted website builder is usually the fastest, lowest-maintenance route. Check what you can export and what each plan limits.

Hosted website builder in Solutions

You need flexibility, several editors or custom features, and can rely on technical help

A traditional CMS on well-chosen hosting gives the most control over structure, design and extensions, at the cost of ongoing updates and security work.

Team content in Solutions

One body of content must feed a website and other channels, or you want a fully custom front end

A headless CMS separates content from presentation. Expect more build effort and dependence on developers.

Headless CMS in Solutions

Selling online is the main goal

Start with the Ecommerce guide, because the platform decision there also carries payments, tax and fulfilment.

Launching in Solutions

You already have a working site

Do not replatform for its own sake. Rebuild when maintenance, cost, security or capability problems outweigh the cost and risk of moving.

A planned move to another platform in Solutions

Choose a path: three questions

Answer in order. Each answer points to one platform model, with what it costs you in return. Real products blur these lines, so treat the result as a starting shortlist.

Can you rely on ongoing technical help, in-house or from a partner?

If not

Hosted website builder

The platform, hosting, editor and templates come as one service. You configure the site instead of running it.

Trade-offs: quickest to launch, least maintenance, a predictable feature set. Less control over structure and code, and you work within the platform’s limits.

Watch for: what you can export, what each plan caps (pages, storage, bandwidth, apps), and how the price changes as you add features.

Do you need one content source for several channels, or a fully custom front end?

Ask this if you answered yes above.

If not

Traditional CMS

Content management and page presentation live in one application that you or a host runs, extended with themes and plugins.

Trade-offs: the widest range of themes, extensions and developers, and full control over structure and design. You carry updates, security and performance unless you buy them as a managed service.

Watch for: plugin sprawl and abandoned extensions, update discipline, and the quality of the hosting underneath (see the Hosting guide).

Yes to both

You have technical capacity and need content reuse or a bespoke front end.

If yes to both

Headless CMS

A back-end content repository delivers content through APIs to a front end that you build and host separately.

Trade-offs: content reuse across sites, apps and other channels, and freedom to choose front-end technology. More to build and to keep running, and editors lose live preview unless it is built for them.

Watch for: developer dependence, two systems to host and secure, and search-friendliness: Google still recommends server-side or pre-rendering, because not every crawler runs JavaScript.

The trade-offs side by side

The same ten questions, asked of each model. Use it to test the model the path suggested, and to see what you are giving up.

Show the table
QuestionHosted website builderTraditional CMSHeadless CMS
Who runs itThe platform vendorYou, a host or an agencyYou or an agency, for two systems: the content back end and the front end
Time to launchShortestModerateLongest
Ongoing maintenanceMostly handled by the platformUpdates and security are yours unless bought as a managed serviceBoth systems need maintenance, and the front end is custom code
Control of design and structureWithin templates and platform limitsHigh, through themes, page builders and custom codeComplete, but built by developers
ExtensionsApp store or built-in featuresLarge third-party ecosystems of varying qualityAPIs and integrations you wire up
Editing experienceVisual and immediateGood; varies with theme and pluginsDepends on the build; live preview has to be provided
Who owns performanceThe platform, within its limitsShared: hosting, theme, plugins and mediaYou: rendering strategy, hosting and caching
PortabilityOften the least portable; check exportsUsually good for content; design and settings need rebuildingContent is reachable by API; the front end is yours
Cost shapeA subscription that rises with features and trafficSoftware may be free or licensed, plus hosting, extensions and developer timeA CMS plan or hosting, plus front-end hosting and developer time
SuitsSmall sites, fast launches, non-technical ownersContent-rich sites, custom needs, many editorsMulti-channel content, bespoke front ends, engineering teams
General patterns only. Individual products blur these lines, so verify each row for any platform you shortlist.

What these terms mean

A content management system (CMS) is software for creating, organising and publishing website content without hand-editing every page. Most provide a content editor, page and content types, templates or themes, user roles and permissions, media handling, fields for search engines, and ways to extend them.

  • Hosted website builder. An all-in-one service that sells the platform, hosting, editor and templates together. You configure it rather than install it.
  • Traditional (coupled) CMS. Content management and page presentation combined in a single application. It can be self-hosted or offered as a managed service.
  • Headless CMS. A back-end-only content repository that delivers content through APIs, such as REST or GraphQL, to any front end. The front end is a separate build.
  • Page builder. A visual layout tool that sits inside a CMS or builder. It changes how pages are laid out, not where content lives.
  • Themes, templates, plugins and apps. Add-ons that extend a platform. They are where much of the cost, risk and lock-in hides.

The boundaries are blurring. Hosted builders add code and API features, and some traditional CMSs can also serve content through APIs. Decide by who runs the platform and how content is delivered, not by the label.

Pick the model by who will run the site, not by which template looks best.

What the market looks like

W3Techs’ technology survey reported in September 2026 that 31.5% of websites use no known CMS. Of all websites, 40.2% use WordPress, which is 58.7% of the sites where a CMS was detected. The next largest, each in low single digits, are Shopify, Wix, Squarespace and Joomla.

Popularity is a reason to expect a deep pool of themes, plugins, developers and documentation. It is not evidence of fit, and a large ecosystem also means more third-party code to keep updated. Use market share to judge how easy it will be to find help, not whether a platform suits your business.

Ownership, portability and lock-in

Lock-in rarely shows up at launch. It shows up when you want to leave. Before you commit, ask:

  • What can I export? Pages and posts, media files, redirects, form entries, customer data and design each move differently. In what format?
  • Will my URLs survive? Keeping addresses stable protects search visibility. If they will change, you need a redirect plan.
  • Who owns the domain and DNS? Keep them registered in your own account, not a vendor’s or agency’s.
  • Is custom functionality built on standard technology? Proprietary features are the hardest to move.
  • Does layout tooling trap content? Some layout tools store content inside their own markup. Test an export and an import before you build hundreds of pages.

As an example, the WordPress export tool produces an XML file of posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies and users, which another WordPress site can import. That moves content. Check separately how the theme, plugin settings and media files travel.

How platform costs are structured

Prices change often, so this guide gives no figures. The structure is what stays useful:

  • Hosted builder: a plan that rises with features, storage or traffic; a domain if not included; paid apps; possible fees on any sales.
  • Traditional CMS: the software (often free, sometimes licensed), hosting, theme and plugin licences that renew yearly, security and maintenance, and developer time.
  • Headless CMS: the CMS plan or its hosting, hosting for the front end, integrations and developer time, which is usually the largest item.
  • Every model: design and build, content migration, ongoing editing, accessibility fixes and the cost of leaving.

To compare fairly, price each option over three years at renewal rates, including the people who will run it. A “free” platform with an expensive maintenance burden is not cheaper than a subscription that includes it.

Search, accessibility and speed: check them on any platform

These three outcomes depend on the platform, your content and your hosting together. Ask what the platform controls and what stays your job.

  • Search visibility. Can you edit titles, descriptions, headings, URLs and redirects without a developer? Google explains that it renders JavaScript-based pages, and still calls server-side or pre-rendering a good idea because it is faster and not all bots run JavaScript. That matters most for headless and JavaScript-heavy builds.
  • Accessibility. The current W3C standard is WCAG 2.2, published in October 2023, with conformance levels A, AA and AAA. Ask whether the platform’s templates are built to meet AA, and remember that headings, link text, colour contrast and image descriptions in your own content remain your responsibility. Some laws, including the European Accessibility Act, reference WCAG-based standards.
  • Speed. Core Web Vitals call for Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, at the 75th percentile of real visits. Themes, page builders and plugins all add code, so measure real pages. Hosting is one input; see the Hosting guide.

Switching platforms without losing what you have

A rebuild is justified when maintenance effort, security risk, cost or missing capability outweigh the cost and risk of moving. A fresh look alone rarely is. If you do move:

  1. Inventory content and URLs. Decide what to keep, merge or retire.
  2. Export and test an import before committing, and note what does not carry over.
  3. Map every old URL to its new one. Google recommends permanent server-side redirects (301 or 308) and keeping them in place for at least a year.
  4. Build and test on a staging copy, then remove any noindex or crawl block used during development when you launch.
  5. Launch, then monitor crawl errors, indexing and traffic, and fix redirect chains and soft errors.

Common mistakes and warning signs

  • Choosing by template appearance instead of who will maintain the site.
  • Never testing an export before committing to a platform.
  • Letting plugins and add-ons accumulate with no owner for updates.
  • Paying for custom development where a standard feature exists.
Show 4 more
  • Choosing a headless build because it sounds modern, with no content-reuse need and no developer capacity.
  • A domain or DNS registered in an agency’s or vendor’s name.
  • No staging copy, so updates are tested on the live site.
  • Ignoring mobile, speed and accessibility until after launch.

Frequently asked questions

Is WordPress the default choice?

It is the most widely used CMS, which brings a large pool of developers and extensions. That popularity is not a reason to choose it. Match the model to who will run the site and what it must do.

Can I switch platforms later?

Yes, but the effort depends on how portable your content and URLs are. Plan the export, the redirects and a test import before you commit, not when you want to leave.

Do I need a developer?

For a small hosted site, often not. A traditional CMS benefits from technical help for setup, updates and security. A headless build needs developers throughout.

Is a headless CMS faster?

Not automatically. Speed depends on how pages are rendered, cached and delivered. Google still recommends server-side or pre-rendering for JavaScript-based sites.

Are page builders bad for performance or search?

They can add markup and scripts, which affects speed. They are not inherently bad. Measure your real pages against Core Web Vitals and compare with a simpler template.

Where does the site run if I use a hosted builder?

On the vendor’s infrastructure, so you do not choose hosting separately. That is convenient, and it also limits control. The Hosting guide explains the alternatives.

How often is this guide updated?

We review it when material information changes, and the review date is shown at the top. See How We Evaluate.

Ready to compare available providers?

This guide explains the decision. When you are ready to shortlist by business need, see CMS & Website Platform Solutions.

Sources and method

Sources and how we work (7 sources)

This guide is based on public documentation, standards and published sources, and on general industry practice. Provider claims, public documentation, published sources and our own observations are kept distinct, and where we have directly tested or used something, we say so explicitly. This guide names no products as recommendations. Figures that change are dated where they appear. Sources used:

Read How We Evaluate for our criteria and the limits of what we claim. If you spot an error or an omission, please email info@kybervega.com.