A CMS on its own does not make a static site easy for a team to run. The workflow around it does: who can change what, how drafts get checked, how long a change takes to go live, and how developers and editors avoid tripping over each other. I have seen good tools fail because nobody agreed on those things.
This article sets out a practical workflow for small agency teams and in-house marketing teams running static sites.
Who edits what
Start by listing the kinds of change your site gets and who makes them. A typical split:
| Change | Who | Where |
|---|---|---|
| Blog posts, news, events | Content editors | CMS |
| Page copy, images, testimonials | Content editors | CMS |
| Team members, pricing, FAQs (structured data) | Content editors | CMS, as data entries |
| New sections, layout changes, styling | Designers and developers | Templates in git, often with an AI assistant |
| Build, hosting, integrations | Developers | Repository and host |
The principle is simple: editors own content, designers and developers own templates. Editors should not be able to break the layout, and developers should not be the bottleneck for words.
Structured content such as team members or pricing tiers works best as data files (YAML or JSON) that the templates loop over. Editors then fill in fields rather than editing HTML, and the design stays consistent.
Roles and permissions
Most teams need three levels:
- Editors change content and, where relevant, read form submissions. Limited to the sites they work on.
- Admins also manage settings, forms and people.
- Owner handles billing and account-level settings.
Give each person their own sign-in. Shared logins make it impossible to see who changed what and hard to remove access when someone leaves. For agencies, being able to limit a client’s editor to their own site is essential.
Drafts and review
Drafts let an editor work on something without it going live. In Jekyll, a draft is a file with published: false in its front matter. It is saved in the repository but left out of the build.
For review, choose the lightest process that works:
- Small teams: editors publish directly. Git history means any mistake can be reverted.
- Teams with sign-off: editors save drafts; a reviewer checks and publishes.
- Sensitive sites: changes go to a branch, the host builds a preview, and a reviewer merges the change.
Heavier processes slow everything down, so only add them where the risk justifies it.
Publishing and deploys
When an editor publishes, the CMS commits to the repository and the host rebuilds the site. Make sure editors know:
- How long it takes. Usually seconds to a few minutes. Tell them, so they do not publish twice.
- Where to check. The live URL, or a deploy status page.
- What to do if it fails. Failed builds leave the previous version live, so the site does not break, but someone should be notified.
Set up build failure notifications to go to whoever looks after the site, not to the editor who happened to trigger it.
Keeping the repo clean
When editors and developers commit to the same repository, a few habits avoid friction:
- Pull before you push. Developers should pull the latest content commits before starting work, so they are not working on stale files.
- Keep content and templates in predictable places. Posts in
_posts, pages in their folders, data in_data. CMS tools and AI assistants both work better with a tidy structure. - Do not reformat content files in bulk without a good reason. It creates noisy diffs and can clash with editors’ work.
- Preserve custom front matter. Choose a CMS that leaves fields it does not recognise untouched.
- Commit messages matter. A CMS that writes clear commit messages makes the history useful.
Common workflows
Blog post: editor creates a draft in the CMS, adds images, previews, then publishes. The site rebuilds in a minute or two.
Typo fix: editor opens the page, fixes it, saves. Done. No ticket.
New landing page: a designer builds the layout as a template with an AI assistant on a branch, the host builds a preview, a developer reviews and merges. Editors then fill in the content through the CMS.
Undoing a mistake: find the commit in the history and revert it. The site rebuilds as it was.
Someone leaves: remove their CMS account. Nothing else changes, because they never had repository access.
For setting up the CMS itself, see the complete guide to adding a CMS to a static site. For why designers editing templates with AI is part of this picture, see static sites in the agentic age.
My take
The best workflow is the one where nobody has to think about it. Editors change words and publish. Designers and developers change templates and review each other’s work. Git sits underneath, recording everything and making mistakes cheap to undo. Mabel’s roles and per-site access are built around that split, but the principle holds whatever tool you use: decide who owns what before the first edit, not after the first argument.