Does your small-business website need a CMS?

Start with the edit, not the platform

Suppose your opening hours change tomorrow. Who changes the website, how soon must the correction appear, and who checks it? Now ask the same question about a new service page, a staff photograph and an expired offer. Those answers reveal more than a request for “an easy CMS.” The decision is whether the team needs a browser-based publishing workflow for specific content, or whether a documented request and release process can handle the work reliably.

A content management system is useful when people need to create, edit, review and publish defined kinds of content repeatedly. It is not a substitute for a content owner or a clear approval rule. Equally, a site without a CMS can still be editable: a developer or trained operator can change version-controlled files and publish a reviewed release. The trade-off is the effort and waiting time for each change. Treat these as operating choices, not as a contest between “modern” and “old” websites.

Inventory the changes you can name

Look back at changes requested over the past few months and list credible changes coming next. Separate corrections to existing pages from new entries in a repeatable collection. “We may blog someday” is a weak requirement; “the service manager will publish two location-specific opening updates each month after operations approves them” describes a workflow that can be tested. Do not choose a system from a speculative publishing calendar.

For every item, note its frequency, urgency, source of truth and consequence if it is wrong. A seasonal notice that expires automatically has different needs from a service description revised once a year. Count changes to structured details such as dates, locations and prices only when the business actually publishes those details. If the content rarely changes, ask whether a named service arrangement with a clear response window would be simpler than training several people on an editor.

Copy this editing-role and content-type worksheet

Make one row for each content type, such as service page, article, event, notice, team profile or downloadable guide. Use the prompts below as the columns. Complete the sheet with the people who will perform the edits, not only with whoever buys the site. If nobody owns a row, the issue is editorial responsibility before it is software.

• Content type and example: What repeatable item is being edited, and what is one real upcoming change?
• Fields and boundaries: Which title, body, date, image, link, expiry or other fields must be editable? Which layout and legal text must stay protected?
• Author: Who supplies the facts and draft? Do they need to work directly in the website, or can they send a reviewed request?
• Reviewer and publisher: Who checks accuracy and accessibility, and who may make a change public? Can one person safely hold both roles?
• Cadence and deadline: How often does this change, and what is the longest acceptable wait for a correction?
• Preview and history: Must the team inspect a draft before release, compare versions or restore an earlier item?
• Access and absence: Who needs an account, who covers leave, and how will access be removed when a role changes?
• Owner and review trigger: Who retires stale items, and what event or date prompts a content review?

Match the worksheet to an editing model

A managed edit process may fit a small set of mostly stable pages. The business sends approved changes to a named person, who updates the site and checks the result. Agree how urgent corrections are handled, how the requester previews the change, and where the history lives. A file-based site with a version-controlled review process can also work when a trained operator is already part of the team; GitHub documents how proposed file changes can be reviewed before merging. Neither route requires every business user to enter a publishing interface.

A CMS becomes a stronger candidate when several people must update content without waiting for a developer, or when repeated items need consistent fields. Drupal’s guide shows how content types can share defined fields, such as a title, image and description. That structure helps when many entries must stay consistent; it does not make editorial judgement automatic. If authors, reviewers and publishers need different powers, test those permissions with real tasks. WordPress documents separate roles and capabilities, while Drupal documents workflow states and transitions; what is available in a proposed setup still depends on its configuration.

A visual site builder may include an editor and content collections. Treat it as a candidate in the same test rather than assuming its label settles the question. Ask for a demonstration of your actual content types, roles, draft preview, export and exit path. Do not buy a complex approval workflow for a single occasional editor, or accept an unrestricted admin login when a contributor only needs to change a notice.

Test what happens between draft and public page

Choose one routine change and one urgent correction from the worksheet. Ask the likely editor to make each in a trial environment. Can they find the right item, edit only the intended fields, save a draft, preview it on a phone, send it for review and publish or request publication? Then introduce a mistake. Check whether the team can see what changed and restore the previous content. WordPress documents revision comparison and restoration; Drupal documents revision tracking and editorial workflows. Verify the particular product and configuration rather than assuming all editors behave alike.

Give the reviewer a short content check: correct facts, readable headings, meaningful link text, image alternatives where needed, working links and a clear expiry plan. W3C’s Authoring Tool Accessibility Guidelines distinguish the accessibility of the editing tool itself from its support for creating accessible public content. Test both with the people who will use the system. A helpful prompt for image alternatives is valuable, but a prompt cannot decide whether an image is informative or decorative for the author.

Account for the work after launch

For each candidate, name who will create accounts, review permissions, train editors, check updates, back up content and recover from a bad release. A hosted service may carry some platform maintenance while leaving content quality, user access and vendor terms with the business. A self-managed installation adds a more direct update and recovery job. WordPress’s update documentation explicitly discusses updates and backups; the exact tasks depend on the chosen stack and support agreement.

Do not grant broad administrator access just because it is faster during setup. OWASP’s authorization guidance recommends giving each person the minimum access needed for the job. Test an author account and a publisher account separately, including what happens after a person leaves. Record any limits on export, media ownership and future migration. These are selection criteria now; the detailed transfer of accounts, backups and recovery evidence belongs in the website handover plan.

Hypothetical example: a local training studio

Consider a hypothetical training studio with five stable service pages and a class timetable that changes every month. A coordinator writes timetable entries; an instructor checks dates and capacity; the owner approves publication. The worksheet shows that the stable service pages can follow a managed change request, while the timetable has repeated fields for class name, location, time, instructor and booking link. It also needs an expiry rule so old classes do not remain bookable.

The team trials two options: a lightweight editor with a structured class collection and a file-based update process. The coordinator must publish a sample class, correct a time and remove an expired entry in both. If the editor provides the needed roles and preview with a support plan the studio can operate, a CMS is reasonable for the timetable. If the operator already makes reliable reviewed releases within the required window, the file-based route may be enough. This is a hypothetical decision example, not a Kinetivy client or measured outcome.

Write a one-page decision record

The decision should be explainable to the next person who maintains the site. Record the selected editing model, the content types it covers, who may draft, review and publish, the expected correction window, the maintenance owner and the evidence from the trial. Write down what remains outside the editor. A CMS chosen for articles does not mean every layout, form or integration should become freely editable.

If you have not yet identified the website’s audience, core journey or project constraints, start with the small-business website brief. If the open question is which services deserve separate pages, use the service website content map. Once the site is built, use the handover checklist to verify ownership, access and recovery. This guide answers the narrower question of how the team should make and govern content changes.

• Chosen model and reason: Which real editing tasks made it the simplest workable option?
• Scope: Which content types and fields are editable, and which changes still need a developer or operator?
• Roles: Who authors, checks and publishes, including leave cover and access removal?
• Trial evidence: Which routine change, urgent correction, preview and recovery steps were completed?
• Operation: Who handles training, updates, backups, content review and support after launch?
• Revisit trigger: Which increase in publishing volume, team size or workflow complexity would justify changing the model?