Updating a service on your website should take a few minutes, and in a page builder it can turn into an afternoon of moving boxes and fixing spacing. A good editor lets your staff change what the business offers and publish it, while the design stays as it is.
Before you compare editors, write down five changes you made in the last few months, including an awkward one, like adding a service with its own booking rules or removing a staff member from every page they appear on. Try each editor on those five changes, and you will learn more than any demo on a sample site can show you.
This guide walks through a small editing plan you can prepare yourself, then use to try WordPress, EmDash, Strapi or another system with your own content.
Collect changes before you choose an editor
Start with the person who updates your website now, even if that person is you. Open the requests you sent them and describe the result each request needed. “Change this paragraph” tells you very little, while “replace our old service area wherever it appears” reveals a shared fact that needs an owner.
Put the requests into a simple table. The examples below are possible jobs, so keep only the ones your business has.
| Change | Where it appears | Who should handle it | When it must be checked |
|---|---|---|---|
| Change opening hours | Contact page and location page | Office manager | Before a holiday period |
| Add a service | Service listing and its own page | Service lead | Before customers can request it |
| Replace a team photo | Staff profile and team listing | Content editor | After approval from the person shown |
| Change a booking destination | Buttons and confirmation messages | Person responsible for bookings | When the scheduling system changes |
| Publish an article | Blog listing and article page | Writer or editor | After factual review |
Your table may reveal that the booking destination should stay under tighter control than a team biography. Giving every editor the same freedom would make those two changes equally easy, although their consequences differ considerably.
Write down the slowest recent change too. The delay may have come from the editor or from missing information, even from a missing approval. Buying a different CMS will help with only some of those causes.
Separate the facts you reuse from the pages that display them
A phone number repeated in seven text boxes creates seven opportunities to leave an old number behind. A shared contact record gives the website one place to read it, provided the templates have been built to use that record.
For a service business, we would usually begin with separate records for services and locations, then decide whether staff profiles need their own records. An article can refer to a service without carrying a second editable copy of its opening hours or booking address.
Strapi calls these structures content types and supports fields and relationships between them. The names in other systems differ, but you can judge the outcome without learning their terminology by changing a shared fact and checking which pages change with it. Strapi’s content structure documentation
Keep this exercise connected to real work. A business with one office does not need an elaborate location system merely because its CMS can provide one. It does need a reliable way to change its address if the office relocates.
The service-page writing guide helps decide what belongs in the page itself, while this plan decides where that information lives and who can change it.
Write one editing record in ordinary language
Take a service your business already provides and fill in the following outline. Use the information you would be comfortable putting on the public site, without copying private customer records into a demonstration.
Service name: the name a customer would recognize.
Who it helps: the situation that makes this service relevant.
What is included: the work a buyer receives, with any important limits written alongside it.
Where it is available: the offices or areas that provide it.
How to start: the correct form, phone number or booking destination.
Who approves changes: a named role in your business.
Now give that record to the person building the editor. Ask them to show it on a service page and in the service listing, then change the name once and inspect both places. The exercise reveals whether you have a reusable record or two pages that happen to contain the same words.
Try leaving out a required detail. If the service needs an area before it can be published, the editor should make that omission clear. Otherwise the first person to notice it may be a customer requesting work you cannot provide.
Decide how much control your team wants over layouts
There is a useful middle ground between a rigid form and a completely blank canvas. Your editor might offer a handful of approved sections, such as an introduction and a set of customer questions, with your team choosing the order and filling in the content.
That approach can suit someone who publishes regularly but does not want to make design decisions about spacing and mobile layouts. A more open page builder can suit a team with a designer who expects to create different campaign pages every week.
Astro can use a separate CMS or keep content in files, so choosing Astro does not settle this editing decision. You still need to choose the workflow your team will receive. Astro’s CMS guide
If a technical person makes a few changes a year, files may be perfectly workable. If the office manager needs to correct tomorrow’s opening hours without waiting for that person, demonstrate that change before accepting the setup. The EmDash and WordPress comparison explains the broader platform choices.
Test preview and publishing with an unfinished page
A preview should let you inspect a draft before customers see it. Put a conspicuous temporary sentence into your test page, save it as a draft and check the public address in a separate signed-out browser. The unfinished sentence should appear only where the preview workflow permits it.
Then publish the page and ask how long the public site should take to update. Some sites rebuild when content changes, while others retrieve it when someone opens the page. The person editing should know which behavior to expect and where to look if publication fails.
In Strapi, draft and publication status are available, while preview needs a connection to the website that renders the content. Do not assume a dashboard preview button proves that connection has been finished. Draft and publishing, preview configuration
Use a long service title and a tall photograph in the same trial. These are ordinary publishing situations, and they can expose a layout that only looked good with the developer’s short sample text.
Finish with a small handover your staff can use
Write the publishing instructions while doing the exercise, using the names your staff see on screen. Include where to sign in, how to find a draft and whom to contact if a published change does not appear. Keep credentials in your normal password manager, and leave them out of the shared instruction document.
Have a second person make a change using those notes without coaching. If they get stuck at “rebuild the site,” the instructions still assume knowledge they do not have. Either explain the action in the tool they use or arrange for it to happen automatically.
You can judge the finished editor against the five requests you started with. The office manager should be able to complete their ordinary updates, while changes that affect bookings should have the review you chose. Save those examples with the website handover record, so the next person responsible for the site can repeat them when the editing setup changes.