A website content publishing workflow is the path a page takes from draft to public URL, including who may approve it. Roles make that path enforceable. A CMS can store drafts and revisions; it does not invent an editor. What a CMS is, as software, is explained in what is a CMS. This page is about the people and the states, on any CMS that supports them.
Roles
Keep the list short:
- Author — writes and edits their draft, cannot publish to the public site
- Reviewer — checks accuracy, claims, and tone, and sends the draft back or forward
- Publisher — may put approved items live, and unpublish them
- Administrator — manages users, plugins or templates, and technical settings
One person can hold two roles in a small company. They should still use an account that matches the action, or you will not know who approved a price change. A shared “admin” login makes the workflow theatre.
Authors should not be able to change templates, tracking codes, or user lists. That split is the same idea as least privilege, applied to the website.
States worth using
- Draft — not linked in menus, not indexed
- In review — the reviewer has been asked
- Approved — ready for the publisher
- Scheduled — will go live at a stated time
- Published — on the public URL
- Unpublished or archived — kept for history, not in navigation
If the CMS offers twenty statuses nobody remembers, map them to this list and hide the rest.
Scheduled publishing needs a timezone. “Midnight” in the wrong zone publishes during the business day or the day before a public holiday announcement. Someone should know the scheduler actually runs; a cron job that has been off for a month silently misses the announcement.
Revisions and incidents
Revision history should show who saved which version. Before a risky replace of a high-traffic page, note the revision you can restore. Technical rollback of the whole site is a hosting concern covered in backup restoration testing. Content rollback is the revision list.
Corrections after publish are normal. The workflow should say whether a typo can be fixed by the publisher alone, and whether a price or legal line must go back to review.
A page moving to the public site
- Author saves a draft in the agreed template
- Reviewer checks facts and sends it back or approves
- Publisher previews on staging if the change is structural
- The page is published or scheduled
- The live URL is checked, including the title and links
Several languages and several sites
Each language needs an owner, or the Bahasa Malaysia page will lag the English one. URL patterns are covered in multilingual website structure. Structural changes belong on staging before production. Wording changes can follow the draft-review-publish path directly when they do not alter templates.
A practical example
A marketing executive drafts a service page but cannot press Publish. An operations lead reviews the claims and returns it once because a process description is too broad. The publisher schedules it for 8:00 Malaysia time on Monday and opens the live URL that morning. A shared login is retired so the revision list shows the publisher’s name. The executive can still edit a later draft, which does not overwrite the live page until it is approved again.
Key takeaways
- Separate writing, reviewing, and publishing.
- Use named accounts so revisions mean something.
- Schedule in the correct timezone, and confirm the job runs.
- Decide which edits may skip a second review.
FAQ
Do we need this for a five-page site?
You need a named publisher and a habit of previewing. Formal statuses matter more as soon as two people edit, or when prices and claims change often.
Can the reviewer be the same person as the author?
Sometimes, in a tiny team. Then a second pair of eyes is missing. At least wait and reread, and do not give every author the administrator account to compensate.
Should we publish straight to production?
For copy in an existing template, yes, after approval. For a new layout or form, rehearse on staging first.