blog single

Choosing a CMS your content team will actually use

Editor publishing a page in a content management system

Published on:

October 10, 2024

TAG:

WEB PLATFORM

BY:

Edgeless Team

Read Time:

6 MIN READ

post detail

Content management systems are usually compared on feature lists. Does it support scheduled publishing, multi language, custom post types, revisions? Those questions matter, but they rarely predict whether a team will be happy two years later. The systems that fail are the ones that add work to everyday editing or become expensive to leave.

Start with the editing job

Watch an editor publish a typical page in the current system. Note the steps, the places they switch tools, the things they ask a developer to do and the mistakes they correct before publishing. Then ask what the same task should look like. That description is your real requirements document.

Most teams publish a small number of page types: an article, a service page, a case study, a job listing, an event. The editor should be able to create each one from a clear starting point, fill the fields, preview the result and publish without opening a design tool. If the system requires assembling a page from thirty blocks for a routine update, editors will avoid routine updates.

Features that matter after the first year

The first month is dominated by launch tasks. The second year is dominated by change. Evaluate the system for the work that happens after launch: adding a field, creating a new template, moving a section, restoring an old version and finding out who changed what.

A preview that matches the live site closely enough to trust.
Scheduled publishing and unpublishing without a developer.
Revisions with a clear way to restore an earlier version.
Roles that separate editing, reviewing and publishing.
A media library that handles alt text, captions and file sizes.
An API or export path for every piece of content.
Search and filtering that works with a few thousand entries.
Redirects managed inside the system rather than in a plugin nobody owns.

Preview quality deserves special attention. An editor who cannot see the page as a visitor will publish and then check, which turns every update into a two step process. A preview that renders the real template, with the real components, removes most of that uncertainty.

The cost of leaving

Every system has an exit cost, and that cost is part of the price. Ask how content leaves. Can you export entries with their relationships, or only a flat file of text? Are images downloadable in their original sizes? Do the URLs survive a move? A system that stores content in a proprietary format makes a future migration a content project rather than a technical one.

Test the export before you commit. Take a sample of twenty entries, export them and try to rebuild the same pages in a different system or a static site generator. If the test takes days for twenty entries, the full migration will take months.

Templates are part of the exit cost too. If the page designs live only inside the vendor's builder, a new platform means rebuilding every layout, not just moving the text. Ask whether the templates are stored as code you control or as configuration inside the product.

Content team reviewing a publishing workflow — The best test of a CMS is a real page, published by a real editor, with the clock running.

Who maintains it

A hosted system moves patching and uptime to the vendor, which suits teams without a server administrator. A self hosted system gives more control and puts security updates on your team. Neither is automatically better. The question is who will actually do the work on a quiet Friday in December.

Ask about the update cadence and the breaking change policy. A vendor that ships major versions twice a year without a migration guide creates work for every customer. A self hosted system with no update plan becomes a liability within a year, especially when a security patch requires a framework upgrade.

Pricing that hides work

Compare total cost, not the subscription line. Add the implementation, the template work, the training, the plugins or add ons, the hosting and the internal time to manage it. A cheap license attached to an expensive implementation is not cheap. A higher license that removes two days of developer work each month can pay for itself.

Watch for limits that appear later: entries, environments, users, API calls, bandwidth or storage. The limit that matters is the one you expect to cross in eighteen months, not the one on the plan you buy today.

Multi language is a content decision

If the site may serve more than one language, choose a system that models translations as separate entries linked to the same content, not as pages with a language prefix. The difference appears when a product changes in one market and the other language needs an update. Linked entries make that visible. Duplicated pages hide it.

Decide who translates and when. A translated page that lags six months behind the original is worse than no page, because it gives customers outdated prices and policies. The workflow should show which entries are out of date across languages and who owns the update.

Training and handover

A CMS is only as good as the team's ability to use it. Record short videos for the five tasks editors do most often, and keep them next to the editor documentation. A ten minute recording of a real page being published is more useful than a fifty page manual.

Hand over the model as well as the software. Explain why the fields exist, which ones are required and what happens when a reference is missing. Teams that understand the model make better decisions when a new page type appears, and they stop asking for a developer for simple changes.

Agree on a support arrangement before launch. Who answers an editor question, within what time and at what cost. A short retainer for a few hours a month covers the questions that appear in the first quarter and gives the team a clear path when something does not work.

Choose the system that makes the everyday edit easy and the eventual exit possible. Everything else is a detail you can change.
Edgeless Team

Questions worth asking a vendor

Show us a preview of a page that uses our real components.
How do we add a field to an existing content type?
What happens to our URLs if we leave?
Which parts of the editor are custom, and who maintains them?
How are security updates delivered, and how often?
Can we run a staging copy of the site with the same content?

Ask for references from teams with a similar content volume, not just similar industry. A five page brochure site and a two hundred page resource library put very different demands on editing, search and preview.

Ask those references what they stopped using. Every system has features that looked important in a demo and were abandoned in practice. The answer tells you which parts of the feature list are real and which are sales material.

Run a trial with real content. Give two editors a page to build in a sandbox with no help beyond the documentation. Watch where they stop. That session tells you more about the next two years than any demo, because it tests the system against the work your team actually does.

We evaluate content systems against real editorial work, then build the templates and workflows around the team that will use them.

Explore web development

A content system is a long relationship. Pick one that fits the editing routine, survives a change of plan and can be left without losing the content. The feature list will change. Those three qualities will not.

CMS

Web Platform

Content Operations

Choosing a CMS your content team will actually use

Let's Talk About Your Project