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.
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.
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:
This requirements list becomes the basis for your demos, proof of concept, scorecard, and contract review.
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.
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.
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.
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.
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.
Create a source-of-truth map for customer, product, form, analytics, consent, and campaign data. For each required integration, verify:
A marketplace listing is not proof that an integration supports your required fields, edition, or workflow. Test those requirements directly.
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.
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.
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.
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.
Calculate cost over several years, not only the first invoice. Include:
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.
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.
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:
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.
Do not limit evaluation to a vendor-led demonstration. Give each serious candidate the same tasks:
Record completion time, help required, defects, unresolved questions, and edition-specific limits. This turns subjective preference into comparable evidence.
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.
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.
Do not use popularity as a substitute for testing your workflow, governance, integration, and support requirements.
Two products may both list approvals, personalization, APIs, or multilingual content while implementing them differently. Test the exact edition and workflow.
If nobody owns updates, integrations, backups, access, and monitoring, the operational gap remains regardless of platform.
URLs, metadata, structured data, forms, scripts, redirects, analytics, permissions, and design behavior all need controlled handling.
Unweighted future possibilities can make a platform more expensive and harder to operate. Prioritize funded requirements and document what would trigger an upgrade.
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.
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.
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.
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.
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.
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.
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.
Google Search Central: "Get started with Search: a developer's guide", checked September 8, 2026.
W3C Web Accessibility Initiative: "Evaluating Web Accessibility Overview", checked September 8, 2026.
HubSpot: "Content Marketing Software", checked September 8, 2026.
WordPress.org: "Features", checked September 8, 2026.
WordPress.org: "Updating WordPress", checked September 8, 2026.
Google Search Central: "SEO Starter Guide", checked September 8, 2026.
WordPress Developer Resources: "REST API Handbook", checked September 8, 2026.