To choose a CMS, define your content, approval, integration, SEO, accessibility, security, and cost requirements first. Then test shortlisted platforms with the same real tasks. We recommend keeping mandatory requirements separate from a weighted scorecard, so a polished editor does not hide a missing integration or an unworkable maintenance plan.

At Selworthy, we recommend a requirements, evidence, ownership framework: name the business need, collect proof that the platform can meet it, and assign responsibility for keeping it working. This guide gives you eleven evaluation criteria, a scorecard, and a practical test plan. It is not a vendor ranking or a promise of search results.

What is a content management system?

A content management system (CMS) is software for creating, managing, and updating website content. For example, HubSpot describes Content Hub as a content marketing platform with CMS tools. WordPress documents publishing tools, user roles, themes, and plugins. These are examples, not evidence that either product meets every requirement on your list.

Separate three questions: what software will you use, who will operate it, and how will visitors receive the content? An open-source system can use a managed hosting service. A separate front end can consume content through an API. WordPress's REST API documentation shows how its content can be used in a separate application.

Do not choose from a category label alone. Verify the exact edition, configuration, integrations, hosting arrangement, and support responsibilities you would actually buy.

Start with operating requirements, not a vendor list

Before scheduling demos, document what the website must do and who owns each part of the work. Separate current requirements from possible future ideas. A feature that has no owner, process, or funded use case should not carry the same weight as a requirement your team uses every week.

Write down the following requirements:

  • Content and cadence: List the content types you publish and how often each changes.
  • People and permissions: Name who drafts, reviews, approves, and publishes, including changes that need a developer.
  • Site footprint: Identify the languages, regions, brands, and domains you manage.
  • Connected systems: List the CRM, analytics, consent, advertising, commerce, and support systems that need data.
  • Risk and standards: Ask the responsible teams to document accessibility, privacy, security, and retention requirements.
  • Performance and reporting: Define traffic, availability, performance, reporting, and attribution needs.
  • Operating capacity: Record internal skills, outside support capacity, and a realistic budget for implementation, maintenance, and change.

This requirements list becomes the basis for your demos, proof of concept, scorecard, and contract review.

Eleven criteria for choosing a CMS

1. Content structure and reuse

List the content types your site needs, such as service pages, locations, resources, case studies, events, team profiles, product records, and FAQs. Ask whether the CMS can model these as structured fields or whether every page becomes an unstructured block of formatted text.

To evaluate reuse, try displaying the same structured record in two places and updating it once. Test whether your team can add fields, set validation rules, maintain relationships, and change a model without breaking existing pages. Document the modeling work and any developer support required.

2. Editorial workflow and approvals

Map the real publishing process. Can writers save drafts, compare revisions, request review, schedule publication, and restore a previous version? Can the system separate drafting, approval, and publishing permissions?

Test the workflow with the people who will use it. Ask them to complete a review and correct a rejected Draft without vendor coaching. Record where they need help and whether permissions enforce your required approval process.

3. Roles, permissions, and governance

Determine whether access can be limited by role, content type, business unit, domain, or environment. Ask how temporary vendors receive access and how quickly it can be revoked. Verify whether important actions are logged and whether audit history is available at the level you need.

Include governance outside the interface. Decide who owns templates, domains, redirects, integrations, user access, backups, incident response, and platform renewal.

4. Editor experience and design control

Ask representative users to create a page, reuse a section, update navigation, add an image, set alt text, schedule a post, and correct a mistake. Count the steps and identify where a developer is required.

At the same time, test design guardrails. Editors should have enough flexibility to build useful pages without accidentally changing typography, spacing, accessibility, or mobile behavior across the site. Previewing a page is useful, but it does not replace testing the rendered page at representative screen sizes.

5. Developer experience and release safety

Developers should test local development, version control, reusable components, environments, validation, deployment, rollback, and debugging. Ask how templates and modules move from development to production and how the team prevents an editor change from being overwritten.

Confirm what can be exported, which APIs are available, how rate limits work, and which features require a specific edition. If the site depends on proprietary modules or marketplace extensions, document who supports them and what happens if they are retired.

6. Integrations and data ownership

Create a source-of-truth map for customer, product, form, analytics, consent, and campaign data. For each required integration, verify:

  • Scope: Identify which records and fields move, in which direction, and how often.
  • Identity: Test how records are matched and how duplicates or conflicting changes are handled.
  • Failure behavior: Document what happens during an outage and how failed updates are recovered.
  • Data controls: Confirm where consent and deletion requests are enforced with the responsible team.
  • History: Specify which system retains the authoritative record and who can export it.

A marketplace listing is not proof that an integration supports your required fields, edition, or workflow. Test those requirements directly.

7. SEO controls and crawlable output

The CMS should let authorized users manage page titles, meta descriptions, headings, canonical URLs, index controls, redirects, image alt text, structured data, and XML sitemaps where appropriate. It should also support stable, descriptive URLs and standard crawlable links.

Inspect rendered HTML rather than relying only on editor settings. Google's current developer guidance recommends secure, fast, accessible pages that work across devices, and it explains that important pages should be reachable through crawlable links. Verify those controls in your implementation. Google's SEO Starter Guide makes clear that there is no guarantee a site will be added to Google's index.

8. Accessibility support

Verify that the CMS and its components can preserve heading order, labels, keyboard operation, link purpose, alternative text, captions, table structure, focus visibility, and other accessibility information. Test output from templates and dynamic content, not only a blank editor.

The W3C notes that automated tools can help find accessibility issues, but no tool alone can determine whether a site is accessible. Include knowledgeable human review and representative user testing in the evaluation process. The W3C's accessibility evaluation resources provide a useful starting point.

9. Security, hosting, and maintenance responsibility

Identify who owns hosting, core updates, extensions, certificates, backups, vulnerability response, access reviews, monitoring, and recovery. Verify the division of responsibility in the actual service agreement. For a concrete maintenance example, WordPress's update guidance recommends backing up files and the database before updating.

Do not compare a software license with a fully operated service as if the costs and responsibilities were identical. For an open-source implementation, include hosting, updates, extensions, testing, monitoring, and technical support. For a managed platform, verify service terms, account controls, release behavior, limits, and export options.

10. Performance, reliability, and scale

Define meaningful test conditions: representative templates, real media, third-party scripts, expected traffic, geographic audiences, and authenticated or personalized experiences where applicable. Record performance on mobile and desktop and identify which team controls the bottlenecks.

Ask how the platform handles caching, media delivery, traffic spikes, uptime incidents, status communication, backups, and recovery. Avoid treating a vendor benchmark or empty demo site as a prediction for your finished implementation.

11. Total cost and exit risk

Calculate cost over several years, not only the first invoice. Include:

  • Platform costs: Include subscription or license fees, hosting, infrastructure, and paid extensions.
  • Delivery costs: Estimate implementation, migration, design, development, and integration work.
  • Operating costs: Include maintenance, security work, training, support, and internal staff time.
  • Quality and measurement: Budget for accessibility review, technical QA, analytics, and consent tooling.
  • Future change: Allow for renewals, upgrades, additional content requirements, and eventual migration.

Then estimate the cost of change. Confirm how pages, assets, structured fields, redirects, form data, and analytics history can be exported. Document which parts of the design and functionality can move to another platform and which must be rebuilt.

Compare CMS operating models

Use these as evaluation lenses, not mutually exclusive product categories. Hosting responsibility and presentation architecture are different decisions.

Approach to evaluate Evidence we recommend collecting Ownership question
Provider-operated or managed hosting Service terms, platform limits, recovery procedures, and sample exports Which tasks does the provider handle, and which stay with your team?
Self-managed implementation Hosting plan, update procedure, extension inventory, backups, and recovery test Who operates and supports each part of the system?
Separate front end using content APIs Prototype API delivery, editorial preview, deployment, search, and analytics Who maintains the publishing system, front end, and their connection?

WordPress's REST API is one example of delivering CMS content to a separate application. That architectural choice does not, by itself, tell you who hosts or maintains either system. Compare the complete implementation instead of assuming a category is always simpler, faster, safer, or less expensive.

Use a weighted CMS scorecard

For Selworthy's recommended scorecard, give each criterion a weight from 1 to 5 based on business importance. Define the rating scale before testing: for example, 1 means substantial unresolved gaps and 5 means the requirement was demonstrated in your test. Keep untested criteria marked unverified, not scored as if they passed.

Multiply each verified rating by its weight, then sum the results using the same criteria and weights for every platform. Illustrative example: a workflow criterion weighted 5 and rated 4 contributes 20 points. These numbers are a decision aid, not an industry benchmark or a prediction of website performance.

Keep evidence beside each score:

  • Content and workflow: Retain completed task tests from editors and approvers.
  • Governance: Attach the role matrix, audit-history findings, and access test.
  • Design and development: Link the prototype component and tested release workflow.
  • Integrations: Record field-level data tests and failure behavior.
  • SEO and accessibility: Retain rendered-page checks and knowledgeable human review.
  • Security and operations: Attach the responsibility matrix, recovery test, and service terms.
  • Cost and exit: Include a multi-year estimate, sample export, and migration dependency inventory.

Keep hard requirements separate from weighted preferences. A platform that fails a legal, security, accessibility, data, or critical integration requirement should not win because it scores well on less important features.

Run a representative proof of concept

Do not limit evaluation to a vendor-led demonstration. Give each serious candidate the same tasks:

  1. Build a page: Create a service page from an approved design.
  2. Test reuse: Create a reusable content type and display it in two places.
  3. Run the workflow: Draft, review, schedule, publish, and restore a test page.
  4. Check access: Set roles for an editor, approver, developer, and outside vendor.
  5. Test a form: Connect a test form to the required customer-data workflow using non-sensitive test records.
  6. Inspect SEO controls: Configure title, description, canonical, index controls, redirects, and sitemap behavior.
  7. Check accessibility: Add useful image alt text and test keyboard navigation, then arrange broader human review.
  8. Measure output: Test a representative page with production-like scripts and media.
  9. Try an export: Export a content sample and document what is missing.
  10. Rehearse recovery: Simulate an integration failure and a rollback in an isolated test environment.

Record completion time, help required, defects, unresolved questions, and edition-specific limits. This turns subjective preference into comparable evidence.

Plan migration before signing

A CMS decision is also a migration decision. Inventory current URLs, traffic owners, backlinks, content, templates, forms, files, scripts, structured data, analytics, consent behavior, integrations, and redirects before estimating the move.

A release plan should include URL mapping, content ownership, redirect testing, metadata parity, image handling, mobile QA, accessibility review, form and conversion testing, analytics validation, sitemap and robots checks, rollback, and post-launch monitoring.

Do not change a healthy URL merely to match a new CMS convention. Preserve important content history and route retired pages to a genuinely relevant destination. If the current platform can meet the requirements through a controlled repair, compare that option with a full migration.

Keep platform comparisons in their own scope

A broad selection guide should help a business define requirements before comparing brands. A direct platform comparison should verify the current capabilities, editions, costs, and responsibilities of those specific products.

If your shortlist includes HubSpot and WordPress, use Selworthy's separate WordPress versus HubSpot CMS comparison as a starting point, then verify the current product details directly. HubSpot describes Content Hub as a content marketing platform with CMS tools. WordPress describes its software as open source and extensible through themes and plugins. Neither product is automatically the right choice for every business.

Common CMS selection mistakes

Choosing from popularity alone

Do not use popularity as a substitute for testing your workflow, governance, integration, and support requirements.

Comparing feature checklists without testing

Two products may both list approvals, personalization, APIs, or multilingual content while implementing them differently. Test the exact edition and workflow.

Ignoring maintenance ownership

If nobody owns updates, integrations, backups, access, and monitoring, the operational gap remains regardless of platform.

Treating migration as content copy and paste

URLs, metadata, structured data, forms, scripts, redirects, analytics, permissions, and design behavior all need controlled handling.

Buying for every possible future idea

Unweighted future possibilities can make a platform more expensive and harder to operate. Prioritize funded requirements and document what would trigger an upgrade.

Frequently asked questions

How do I choose the right CMS?

Document your content, workflow, governance, integration, SEO, accessibility, security, performance, cost, and migration requirements. Test shortlisted platforms with the same real tasks, score the results by business priority, and verify the exact edition and contract terms.

What is the best CMS for a business?

There is no universal best CMS. The right choice depends on the business's operating model, team skills, content structure, required integrations, governance, support capacity, budget, and exit requirements.

Should a small business use a hosted or open-source CMS?

Compare the complete responsibility and cost model, not just the software label. Open-source software can also use managed hosting. Ask who handles hosting, updates, extensions, backups, recovery, and support, then test the implementation your business would use.

What SEO features should a CMS have?

Look for control over titles, descriptions, headings, URLs, canonical tags, index directives, redirects, alt text, structured data, sitemaps, and crawlable navigation. Verify the rendered HTML and do not treat built-in tools as a ranking guarantee.

How much does a CMS cost?

Total cost includes licensing, hosting, implementation, design, development, integrations, extensions, maintenance, security, training, QA, internal labor, and future migration. Compare a multi-year operating cost rather than the entry price alone.

When should a company replace its CMS?

Consider replacement when verified business requirements cannot be met safely or economically through a controlled repair. Define the gap, cost the repair and migration options, and account for URL, content, data, integration, and team disruption before deciding.

Make the CMS decision testable

You do not need the longest feature list. We recommend choosing from documented requirements, representative tasks, clear ownership, verified output, realistic cost, and a tested exit path.

Selworthy can help with website design and development, HubSpot onboarding and training, migration planning, and technical SEO. Talk with Selworthy about the website, team, and systems you need the CMS to support.

Sources and checked dates