Choose a content management system by running your own publishing tasks through a shortlist. Agree essential requirements first, test with representative content, and keep evidence of what worked. The best fit depends on your editors, technical capacity and delivery needs.
Write requirements before watching demos
Start with three actual content types, such as a service page, a news item and a downloadable guide. Identify who writes, approves, translates and publishes each one. List the systems that exchange data with the website and the people responsible for hosting, updates and recovery.
Separate essential requirements from preferences. If confidential previews or an accessible editor are essential, a failure needs resolution before selection. A high score for attractive templates cannot cancel that failure. Record the tested product version, plan, configuration and any paid extension required for each feature.
| Requirement | Demonstration to request | Evidence to keep |
|---|---|---|
| Editorial approval | An author submits a revision while the approved page remains public. | Roles used; review history; public URL check. |
| Reusable content | Change a shared contact record and inspect every intended use. | Affected-page list and exceptions. |
| Accessible publishing | Create headings, links, an image alternative and a form using the editor. | Keyboard checks and output inspection. |
| Content portability | Export pages, assets and relationships; import into an empty test destination. | Export files and reconciliation results. |
Include the needs of people creating content as well as people reading it. The W3C page structure tutorial provides useful examples of semantic output to inspect. A theme demonstration alone says little about the content your editors will produce.
Match the architecture to maintenance capacity
A traditional coupled CMS usually provides authoring and page delivery together. A headless CMS separates the content service from the presentation application; the team must arrange the front end, previews and deployment. A static publishing workflow generates pages ahead of delivery and needs a process for rebuilding changes. Products can combine these approaches.
Choose by responsibilities: who fixes a failed build, updates dependencies, manages preview access and restores service? Ask for a diagram of the actual proposed setup. The programming language or architecture label alone cannot establish security, performance or total effort.
Run the same trial in every finalist
- Create a realistic page with an image, related content and a download.
- Submit it using an author account; review and publish using the intended permissions.
- Edit the published content, inspect revision history and restore a previous approved version.
- Change a shared field, then check dependent pages, navigation and search behavior.
- Use the editor with a keyboard and check the resulting public page at a narrow width.
- Export the trial content and restore it to a clean test destination, documenting what needs separate transfer.
For a concrete example of export scope, WordPress documents its WXR export as an XML content transfer format. Treat a content export and a complete site recovery as separate tests; themes, configuration and files may need their own procedures. Check the exact platform documentation for your setup.
Let likely editors perform the trial after ordinary training. Record assistance required, errors and recovery effort, rather than timing only the vendor's expert demonstrator.
Use a scorecard without hiding essential failures
After essential requirements pass, assign weights before comparing results. Use 0 for unavailable or failed, 1 for a major workaround, 2 for a workable result with friction, 3 for meeting the task and 4 for exceeding it in a useful, demonstrated way. Treat untested items as pending rather than silently awarding points.
Download the trial scorecard CSV and scoring instructions. It contains empty score and evidence fields plus suggested weights. Calculate each weight × score and divide their sum by the sum of weights only after all required tests are complete.
Document the decision and the exit route
Compare implementation, migration, training, hosting, subscriptions, extensions, updates, support and eventual exit effort over the same planning period. Keep staff-hour assumptions separate from supplier quotations. Ask which charges increase with editors, traffic, storage or API usage and verify the terms at the time of purchase.
Write a one-page decision record: tasks tested, essential gaps, accepted compromises, responsible operators, costs and uncertainty. Include the export format, asset transfer method and how a replacement system would preserve identifiers and URLs. A system is easier to maintain when its boundaries and responsibilities are understood before purchase.