CMS and blogging

What this category covers

Systems for writing, structuring and publishing content: traditional platforms that store and render pages, headless back ends that hand content to something else, and hybrids trying to do both without annoying either audience.

Buyers here fall into two camps with opposite needs. A marketing team wants to change a page in ten minutes without asking anyone. An engineering team wants content modelled properly, versioned, testable and delivered through an interface. Products that promise both usually favour one and tolerate the other.

Drag-and-drop tools for a site with a handful of pages sit in website builders. Internal documentation belongs in docs and knowledge base.

Content model before features

The model is the part you cannot change cheaply later.

Ask whether content is stored as structured fields or as one blob of formatted text. Fields survive redesigns, feed several destinations and let you list, filter and reuse things. A blob renders once and traps everything inside the markup of whichever editor produced it.

Then ask about relationships. An author linked to their articles, a product linked to its category, a page linked to its translations: those connections are what make a site maintainable at two hundred pages rather than twenty.

Reuse follows from the same decision. If a legal line, a price or a call to action appears on forty pages, it should exist once and be referenced, not pasted forty times and corrected thirty-nine.

Editing, and who actually does it

The people who use this software every day are usually not the people choosing it.

Watch a non-technical colleague create a page during the trial. Note where they hesitate. Check whether they can see the result before publishing, whether they can undo a mistake, and whether the preview shows the real design rather than an approximation.

Workflow matters once a team grows past a couple of editors. Draft states, scheduled publishing, a review step and a readable history of who changed what are the difference between a system and a shared document with a login.

Publishing, performance and the search question

Whatever renders the site decides how fast it is, and speed is a ranking input as well as a courtesy.

Ask what the output looks like. Static pages rebuilt on publish are quick and cheap to serve. Server-rendered pages need caching that someone has to configure. Client-rendered pages need care to stay readable by crawlers.

The rest of search readiness is unglamorous. Editable titles and descriptions per page. Clean, stable URLs. Redirects when a URL has to change. Canonical handling for anything reachable by two addresses. Sitemaps that update on publish. Products that hide these behind a plugin, or behind a higher plan, are telling you something about their priorities.

Multilingual sites should test translation handling early, because retrofitting it is close to a rebuild.

What it costs to run

• Licence or subscription, per seat, per site or per environment.
• Hosting, bundled in hosted platforms and entirely yours in self-hosted ones.
• Traffic and bandwidth, metered on plenty of hosted plans.
• Builds or rendering, counted on platforms that rebuild the site on every change.
• Maintenance, invisible on the pricing page and real in the calendar.

Self-hosted systems look free and are not. Updates, plugin conflicts, security patches and backups are somebody’s weekly job, and that job has a salary attached. Hosted platforms move the same work into the invoice, where it is at least easy to compare.

Read the extension market before deciding. A cheap core with four paid add-ons is a mid-priced product wearing a disguise, and what pricing pages hide has more of that arithmetic.

Migration, and the part that costs traffic

Moving between content systems is a known quantity except for one thing, and that thing is addresses.

Content usually exports in some form and imports with effort. What breaks a migration is changing URLs without redirects. Search engines and every link anyone ever made still point at the old ones.

Plan that before choosing a platform. List every published address, decide which survive, and map the rest to their replacements. A redirect map built during the project takes hours. Rebuilt afterwards from a report of broken links, it takes weeks, and traffic falls for the whole of that time.

Check the other inherited details as well: image handling, structured data, feeds, and anything embedded in old pages that the new system will render differently or not at all.