Keystatic for static websites: simple editing without losing performance

There is an interesting middle ground between a fully static website and a large CMS with a database, users, server, complex roles, and extra maintenance.

That middle ground is where Keystatic can make sense: file-based content, visual editing, Git control, and a website that can remain fast, static, and easy to deploy.

The real problem

Many small projects do not need a huge CMS. They need to edit pages, services, projects, articles, images, and a few global texts. Nothing more.

But asking the client to edit JSON or MDX by hand is not comfortable either. That creates the need for an editing interface, even when the project does not justify a heavy architecture.

Keystatic handles that tension well: structured content, editable from a panel, but stored in the repository. That means content is part of the code, has history, and triggers deployments like any other change.

Versioned content

I like the idea of content living in Git. Not for every case, but definitely for portfolios, corporate websites, small blogs, and projects where content changes calmly.

Versioned content makes it possible to review changes, go back, understand what changed, and avoid depending on a database for something that can be static.

It also fits a performance-minded approach: if the site can be generated at build time, there is no need to query a server for every visit.

Editing needs design

The delicate part is configuring the CMS well. If everything goes into one giant collection, the editor becomes uncomfortable. If you separate too much, it becomes bureaucratic.

What works better is thinking about how the person will actually edit: pages separated, navigation, shared UI, projects, services, blog, SEO, and repeatable content. Each thing in its place.

A good CMS does not only store data. It reduces anxiety. The person enters, knows where to touch, and understands what will change.

Static does not mean rigid

Static websites are sometimes confused with immovable websites. That is not true. A static website can have a blog, projects, images, SEO, languages, RSS, sitemap, and editable content. What changes is when it is built: at deploy time, not on every request.

That is often ideal for portfolios and service websites: very fast for the user, simple to host, and with fewer parts to monitor.

Clear limits

I would not use Keystatic for everything. If you need advanced editorial permissions, complex workflows, thousands of records, large internal search, or real-time content, I would probably look at Payload, Sanity, WordPress, Supabase, or another option.

But for a website that wants editing without losing performance, it feels like a very honest tool.

Closing

The good thing about Keystatic is that it does not overreact. It gives editing where it is needed, keeps content close to the repo, and lets the website stay lightweight.

To me, that is a good direction: autonomy for the client, control for the project, and less infrastructure when it does not create value.