The question I hear most about static sites is not about speed or hosting. It is “but how will the marketing team update it?” That is a fair question, and for years the honest answer was “they will email the developer”. That answer loses projects, and it should.

This guide covers the ways to put an editing screen on top of a static site, what each one is good at, and how to choose. It names categories rather than products, because the products change faster than the trade-offs do.

Why static sites need a CMS

A static site is built from files: templates, Markdown for pages and posts, YAML or JSON for structured data such as team members or pricing. Developers edit those files in a code editor and commit them to git. That works well for the people who build the site.

Everyone else needs something else. A marketing coordinator wants to fix a date on the events page, add a blog post or swap a photo, without learning Markdown front matter or opening a pull request. Without a CMS, those requests pile up with whoever knows git. The site goes stale, or the developer becomes the bottleneck for typo fixes.

A CMS for a static site gives non-developers a form-based screen for content, while keeping the site static. The approaches differ mainly in where the content lives.

Git-based CMSs

A git-based CMS reads and writes the same files your developers work with. When an editor saves a post, the tool writes a Markdown file and commits it to your repository. Your host sees the new commit and rebuilds the site.

What this gives you:

One source of truth. Content stays in the repository alongside the templates. There is no second database to back up or keep in sync.
History and rollback for free. Every edit is a commit with an author and a timestamp. Undoing a change is a revert.
No lock-in on content. If you stop using the tool, your content is still plain files in your repo.
Developer-friendly. Developers keep working in their editor and with AI coding tools on the same files.

The trade-offs:

Each save triggers a rebuild, so changes take as long as your build to go live, usually seconds to a few minutes.
Large volumes of content, or content shared across many sites, can become awkward in files.
The tool needs permission to write to your repository, so you should check what access it asks for.

Git-based tools come in two broad shapes: ones you add to your site (often a JavaScript admin page you host yourself) and hosted services that connect to your git provider. Hosted ones usually handle sign-in, roles and image handling for you.

Headless API CMSs

A headless API CMS stores content in its own database and exposes it through an API. At build time, your static site generator fetches content from that API and turns it into pages. Editors work in the CMS’s web app.

What this gives you:

Rich editing features. Many have mature workflows, localisation, scheduled publishing and fine-grained roles.
Content reuse. The same content can feed a website, an app and other channels.
Scale. Large content libraries are easier to manage in a database than in thousands of files.

The trade-offs:

Content lives outside your repo. Your git history covers the templates but not the words. Backups, exports and history depend on the vendor.
More moving parts. The build depends on an external API being up and the content model matching your templates.
Pricing usually scales with users, content entries or API calls.
Lock-in. Moving away means exporting and transforming content.

Hybrid and visual editors

Some tools sit between the two, or focus on visual, on-page editing where editors click into the live page and change text in place. These can feel closest to what editors expect from a page builder. They also tend to need extra markup in your templates so the tool knows what is editable, and that coupling can make templates harder to change later.

Visual editing is appealing, but be careful not to recreate the problems of page builders: layout decisions made in a tool’s panel rather than in your templates. Keep structure in code and let editors change content.

What your editors need

Before choosing a tool, ask the people who will use it. Most editors need:

A list of posts and pages they can search and filter.
A simple writing screen with headings, links, lists and images.
Images that are resized and placed correctly without thinking about file paths.
Drafts, so they can work on something before it goes live.
Clear feedback on when a change will be live.
Access only to the sites and sections that are theirs.

Few editors need a blank canvas to design pages. Giving them one usually leads to inconsistent pages and a design that drifts over time.

What developers need

Developers and template-editing designers have a different list:

Content in a predictable format, ideally files they can read and diff.
No markup or special attributes forced into templates.
Custom fields and front matter preserved when editors save.
The ability to keep working with their own tools, including AI coding assistants, without the CMS overwriting their changes.
A clear permission model for the tool’s access to the repository.

A git-based CMS usually fits this list more easily. A headless CMS can, but requires more setup to map content to templates.

Setting one up step by step

The details depend on the tool, but the shape is the same:

Tidy your content structure. Put posts, pages and data files where your static site generator expects them. Consistent front matter makes the editing screen cleaner.
Decide who edits what. List the people and the sections they need. This drives roles and access.
Connect the tool. For git-based tools this means granting access to the repository. For headless tools it means defining a content model and wiring your templates to the API.
Configure fields. Map front matter or content fields to sensible controls: dates as date pickers, tags as tags, images as image pickers.
Test the full loop. Have an editor make a change and watch it build and go live. Check the commit or entry looks right.
Write a one-page guide for editors covering how to publish, how long changes take, and who to ask.

The article on editing workflows for teams covers roles, drafts and review in more depth.

Choosing the right CMS

A rough guide:

If you need	Lean towards
Content in your repo, full history, minimal moving parts	Git-based CMS
A few editors on small to medium marketing sites	Git-based CMS
Content shared across several sites or apps	Headless API CMS
Large editorial teams with complex workflows	Headless API CMS
Editors clicking into the live page	Visual or hybrid editor, with care

For more detail on the first two rows, see git-based CMS vs headless API CMS. If you are weighing editing against the other gaps in static sites, shortfalls of static sites and how to fix them puts them in context.

My take

For most agency and in-house sites, I would start with a git-based CMS. Keeping content in the repository means the site stays one thing: files in git, with a full history, that a developer, a designer with an AI assistant or an editor can all work on. Headless CMSs earn their place when content really is shared across channels, but that is less common than the marketing suggests.

I build Mabel, a hosted git-based CMS for Jekyll sites, so weigh my view accordingly. Whatever you choose, choose it at the start of the project, not after the first “can you just change this?” email.