How to Choose a Content Management System: A Practical Guide

Choose the least operationally complex content management system (CMS) that meets your required publishing, integration, control, and growth needs. A marketing team that needs to publish approved pages without developer help may prefer a hosted visual platform. A team delivering the same structured content to a website and an app may justify a headless CMS, provided it has engineers to build and operate the frontends.

A CMS is software for structuring, editing, storing, and publishing website content. Hosting, site building, and content management may be bundled together or handled by separate products. The right choice depends less on a universal ranking than on who will use, maintain, secure, and eventually replace the system.

This guide compares hosted, self-hosted, and headless operating models, gives representative platform fits, and provides a proof-of-concept process for testing editorial workflows, APIs, portability, cost, and ownership before procurement.

Choose a CMS by matching its operating model to your team

Begin with the work the system must perform, not a vendor ranking or feature count. Write down the content you publish, who creates and approves it, where it must appear, which systems it must connect to, and who will maintain the platform.

Separate requirements into required, preferred, and out of scope. A required feature such as approval before publication should be tested with an editor and approver account. Do not infer that it is included because a product is described as enterprise-ready, headless, or all-in-one.

For each requirement, name the tester and the evidence that counts as a pass. This turns a sales claim into a decision record and makes unresolved plan, permission, API, and export limitations visible before they become implementation problems.

Decide who owns the frontend and ongoing maintenance

A hosted, all-in-one platform combines some or all of content editing, site building, and hosting. It can reduce infrastructure work for your team, but plan limits, support terms, permissions, integrations, and exit options still matter. Webflow, for example, combines visual site design and managed hosting. Shopify combines ecommerce and website operations in one product.

Self-hosted systems such as WordPress and Drupal give an organization more control over code and hosting choices. That control comes with operational work. Updates, backups, compatibility checks, access management, monitoring, and recovery need named owners. WordPress supports configurable plugin and theme auto-updates, but that does not replace compatibility checks or a recovery plan. See the official WordPress auto-update documentation and core update documentation.

A headless CMS manages content separately from the frontend that presents it. The customer team builds, deploys, previews, and operates that frontend, connecting it to the CMS through an API. Storyblok documents this division of responsibility in its technical requirements. Headless is a delivery architecture, not an automatic performance or scalability improvement.

Operating model	Suitable team	Key tradeoff
Hosted, all-in-one	Teams seeking visual editing and less infrastructure work	Review plan limits, integrations, permissions, and exit options
Self-hosted	Teams with technical ownership and a need for hosting or code control	Your organization owns updates, backups, compatibility, and recovery
Headless	Teams with frontend engineers and a real multi-channel need	You must build and operate the frontend and API connection

Turn publishing needs into testable CMS requirements

Describe real editorial tasks rather than collecting features from product pages. For each requirement, name the person who will test it and the evidence that counts as a pass. Useful requirements include:

• Content structure: Can editors create the pages or records you need, with required fields, reusable media, and relationships between content types?
• Editorial workflow: Can an editor preview a draft, send it for approval, schedule it, publish it, unpublish it, and restore an earlier version?
• Permissions and localization: Can roles restrict editing and approval appropriately, and can the team manage the languages, regions, brands, and domains it actually needs?
• URLs and metadata: Can editors manage metadata and redirects when a URL changes? Can you verify that visitors reach the intended destination?
• Integration and API: Which systems must exchange content? Verify authentication, read or write access, required fields, pagination, rate limits, response handling, and error behavior in current documentation.
• Commercial constraints: Record required seats, locales, storage, traffic, API requests, environments, and support arrangements, then verify the relevant plan limits.

Marketplace size is not proof of quality, compatibility, or support. Evaluate the specific extension or integration your workflow needs, including who will maintain it. Keep every item marked required, preferred, or out of scope so attractive extras do not obscure a missing must-have.

Compare platforms by fit, not by a universal ranking

The options below represent different operating models. They are candidates to test, not a ranking. Product pages describe advertised capabilities, and current plan details should be confirmed for your implementation.

Platform	Plausible fit	Tradeoff to test
HubSpot Content Hub	Teams that value content tools connected to HubSpot’s broader customer platform	Confirm which capabilities, seats, and limits apply to the chosen plan, and assess whether the wider platform fits your workflows
WordPress	Flexible publishing where the organization can own hosting and extension maintenance	Test the actual theme and plugins together, and assign update, backup, and recovery ownership
Drupal	Organizations with technical resources and complex content requirements	Validate implementation effort, editorial usability, and the maintenance capacity the configuration requires
Webflow	Teams prioritizing visual site design and managed hosting	Check current plan limits and export behavior; dynamic content and forms have limitations after export
Shopify	Businesses whose central requirement is ecommerce operations	Test the commerce workflow and integrations you need, along with current plan terms
Storyblok	Teams with a customer-operated frontend that consumes API-delivered content	Budget for frontend engineering and check seats, traffic, locales, API requests, and content limits
Agility CMS	A headless candidate for teams evaluating a content platform with visual editing	Verify required capabilities, package limits, and technical details directly before selection

Pricing and usage limits change. HubSpot’s current pricing pages display different Starter figures depending on billing and promotional context. Webflow’s current page shows Starter, Basic, and Premium plans rather than the older Basic, CMS, and Business structure. Storyblok lists annual and monthly figures with different seats, API requests, traffic, locales, and content limits. Compare the live official pricing pages at evaluation time and record the retrieval date, billing context, and assumptions.

Market share can help explain ecosystem familiarity, but it cannot establish suitability. On October 9, 2026, W3Techs reported WordPress at 58.6% and Shopify at 7.8% among websites whose CMS was known. These figures use that denominator and measurement date. They are not quality scores or percentages of all websites. See the W3Techs CMS usage table.

If customer-platform integration is central to the decision, evaluate Content Hub against your actual customer and publishing workflows. HubSpot systems consulting may help if you need an independent assessment of that fit.

Run a proof of concept using the real editorial path

Before procurement, test one representative record from creation through recovery. Use the actual editor and approver roles, not only an administrator account or a vendor-led demonstration. For any must-have that cannot be confirmed in current documentation, require a proof of concept.

1. Create a realistic record. Use a representative content type, required fields, media asset, and localized variant. Record the test owner and selected plan or environment.
2. Run the editorial journey. Have the editor draft and preview the record, then have the approver review and publish it. Unpublish it and confirm what each role can and cannot do.
3. Test URL and media handling. Change a URL, verify the redirect, and check how media is stored and referenced. Record manual steps or missing capabilities.
4. Test retrieval or export. Use the documented API or export route for the specific content you need. Record whether it returns the right fields, locale, and publication state, and note what does not transfer.
5. Test recovery and decide. Restore or roll back a change. The evaluation lead records pass or fail, evidence, unresolved requirements, and an owner for each issue.

The following is an illustrative scorecard format, not a vendor feature or ready-made integration. Its grain is one test record and one evaluation run, so a later run receives a new run identifier rather than overwriting the earlier evidence.

{
  "test_record_id": "poc-001",
  "evaluation_run_id": "cms-eval-2026-10-09-001",
  "content_type": "product_page",
  "locale": "en-CA",
  "workflow_results": {
    "create_content": "pass",
    "preview_draft": "pass",
    "approve_and_publish": "pass",
    "unpublish": "pass",
    "change_url_and_test_redirect": "fail",
    "retrieve_or_export_content": "pass",
    "restore_or_rollback": "pass"
  },
  "manual_steps": ["Redirect was entered by an administrator"],
  "unsupported_requirements": ["Redirect review by approver"],
  "owner_required": "CMS evaluation lead"
}

For API tests, verify authentication, required request fields, response structure, pagination, rate limits, and whether the endpoint is read-only or supports writes. Storyblok’s REST Content Delivery API documentation describes regional endpoints, JSON responses, pagination, caching, and rate-limit handling. Its GraphQL API is documented as read-only. These behaviors are a starting point for a test, not proof that another platform has the same API behavior.

For a customer-operated headless frontend, a proposed retrieval sequence is: authenticate against the documented regional endpoint, request the required published version and locale, validate the HTTP status and JSON structure, render the response, and handle missing records, invalid credentials, and 429 responses with bounded retries. Keep secret credentials out of browser code. If an internal index is required, store the source space, stable story identifier, locale, publication state, source version or cache version, retrieval timestamp, run identifier, payload hash, and sync status.

That storage design is an illustrative implementation recommendation, not a vendor-published schema. Use a database-enforced unique constraint or atomic upsert on the source system, space, stable record identifier, locale, and version context when concurrent workers can run. A lookup followed by create is not sufficient for race-safe deduplication. Store failed attempts separately from successful records so retries do not create duplicate content.

Compare portability asset by asset: static pages, structured content, media, forms, redirects, search, analytics, and integrations. Webflow says paid Workspace users can export sites, but dynamic content requires collection-by-collection export and forms stop working after export. A site export therefore does not prove that the complete publishing operation can move unchanged.

Calculate first-year cost and assign operational ownership

A subscription price is only one part of the operating cost. Estimate the first year using the same scope for every candidate. Include implementation and migration work, not just the initial account or hosting charge.

• Subscription, hosting, domain, and applicable seat, traffic, storage, locale, API, or environment charges.
• Premium themes, templates, apps, plugins, or other extensions.
• Implementation, content migration, URL mapping, redirect setup, and integration work.
• Backups, security monitoring, maintenance, support, and recovery planning.
• Editor and administrator training, plus the time needed to manage publishing workflows.

For self-hosted WordPress, name who monitors core, plugin, and theme updates, checks compatibility, maintains backups, and handles recovery. WordPress documentation describes configurable update controls, not a complete maintenance service. Wordfence reported that plugin vulnerabilities accounted for 96% of the vulnerabilities disclosed in its 2024 WordPress analysis. That figure describes Wordfence’s analysis and dataset, not all WordPress security risk. Use it as a reason to assign extension maintenance, not as a platform-wide security rating.

Hosted services can shift some infrastructure work to the vendor, but your team still needs to review plan limits, permissions, integrations, and support responsibilities. Assign named roles for publishing access, vendor-plan reviews, incident response, and integration credentials.

Make the decision and document the exit conditions

Score only criteria that influence the decision: required workflow fit, publishing autonomy, technical ownership, integrations, portability, security responsibilities, and total cost. Record the evidence for each score and leave unresolved plan, API, or export questions visible rather than treating them as passes.

Before selecting a platform, document where canonical content lives, who owns URLs and redirects, how integration credentials are managed, and how content and assets will be exported or migrated. These details turn portability from a general promise into a set of testable exit conditions.

Customer case studies can show how a particular organization deployed a product, but they are not independent benchmarks or guarantees of similar outcomes. HubSpot’s case study reports a customer-specific lead result for The Chopping Block. Storyblok’s case study reports that Oatly launched 16 global market websites in two months. Agility’s case study reports Cineplex usage figures. Treat such claims as attributed deployment examples, not forecasts or proof of causation.

The right CMS is the candidate that passes your required workflow tests, has an accountable operating owner, fits the full first-year budget, and has an acceptable exit plan. If you need help mapping system ownership and publishing workflows, explore systems and automation consulting.