A website content approval workflow for small teams

Three jobs, named in advance

Drafter: Writes and edits the change in the project: new copy, a price update, a new page. Usually the marketing or comms person.
Reviewers: Check the parts they own. A product lead checks claims, someone in finance checks prices, legal or compliance checks anything regulated. They comment; they don't edit.
Publisher: Confirms every comment has been dealt with, runs the final checks and puts the version live. One person, with a named cover.

Write these names down in the team's handbook along with which kinds of change need which reviewers. A typo fix needs nobody; a new pricing page needs finance; a claim about a medical or financial product needs whoever signs off regulated wording.

How roles map onto an Anticode Team workspace

Anticode's Team workspace has three roles. Members can build, edit and publish. Admins can also invite and remove people and delete projects. The owner alone changes roles. There's no role that can edit but not publish, so the split between drafter and publisher is a team rule rather than something the software enforces. In practice that's workable for small teams: give the publishing job to an admin, agree that members don't publish without a recorded approval, and use version history to see who changed what if the rule is broken.

Reviewers outside the workspace don't need a seat at all. A client review link opens the current preview for anyone who has it, without an account, and lets them leave comments tied to a section.

The approval cycle

The drafter makes the change in the project, by editing text in the visual editor or asking for it in a sentence. Nothing is published yet.
The drafter runs the release checklist, which runs every publish check without publishing, so reviewers never see something that couldn't go live.
The drafter notes the version in version history and creates a review link from the project.
The drafter sends the link to the reviewers with a short note: what changed, which section, what each reviewer should check, and the deadline.
Reviewers comment on the sections they own. Each comment arrives tied to its section, so a note about the pricing table can't be confused with one about the hero.
The drafter applies or answers each comment. Disagreements between reviewers go to whoever owns that topic; the publisher settles anything left.
The publisher checks the final version against the comments, records the approval (who, which version, when) in the team's tracker, and publishes.
The drafter revokes the review link so nobody keeps commenting on a version that's now live.

Keep the preview still during review

A review link shows the project's current preview, not a frozen copy. If someone keeps editing while reviewers are reading, they may approve wording that has already moved. Agree a simple rule: once a link goes out, no edits until the review round closes, except those that answer a comment. If an urgent unrelated change comes in, hold it until after publishing.

Version history is your record

Saves are kept as versions, up to a number that depends on the plan, and you can preview or restore any of them. Pair each approval in your tracker with the version it covered. If a published change turns out to be wrong, the publisher can preview the last approved version and restore it, then publish; the restore is added as a new version, so nothing is lost. For larger changes see making big changes to a live website safely.

Where this goes wrong

Approval by silence. "No comments by Friday means yes" works only if reviewers agreed to it beforehand. Otherwise ask for an explicit reply.
Too many reviewers. Each extra person adds days. Route changes only to the people whose area they touch.
Edits sneak in after approval. The publisher compares the version number in the tracker with the one about to go live.
The publisher is away. Name a cover with the admin role before the holidays, not during them.

Limits

Anticode doesn't have an approval button, a publish-only role, a draft that reviewers can sign, or scheduled publishing. Review comments are a conversation, not a recorded approval, so the yes belongs in your own tracker or email. Every team member can publish, and only admins and the owner can take a site down or delete a project. Set up the workspace with team website workspaces, and use client review links for reviewers outside it.

Questions people ask

Can I stop team members from publishing?

Not in the software: members can build, edit and publish. Make publishing a named job for an admin and agree that members don't publish without a recorded approval.

Do reviewers need an Anticode account?

No. A review link opens the current preview for anyone who has it, and they can comment on each section without signing in.

How do we prove what was approved?

Note the version from version history beside each approval in your own tracker or email thread. You can preview that version later.

What if a mistake goes live anyway?

Restore the last approved version from history and publish it, then put the change through review again.