Part two of three on how you can edit a website in 2026. Part one covers updating a site by asking AI, and part three covers a full CMS.
In part one I made the case for running a website as a folder of text files with no CMS at all. It’s fast and cheap to run. There’s very little of it that can break or get broken into.
Then a client’s marketing manager says, reasonably, “I just want to change my own headline, and I am not learning a new tool to do it.”
The normal answer is to bolt a CMS onto the site. But a CMS hands back the database, the admin panel, the login screen, the monthly bill, and the security surface we were happy to be rid of. That’s a lot to take on for the ability to reword a paragraph. So we built something much smaller.
Add ?edit=1 to the URL
That’s the whole entry point. Put ?edit=1 on the end of any page address and the live page becomes editable. Click a headline, type a new one, save.
It feels like editing the actual page because you are editing the actual page. There’s no separate admin site to learn and no second version of the content to keep in sync with the first. What you’re clicking on is the finished page.
Underneath, nothing about part one changes. The content is still text files. The site is still built ahead of time and served as finished pages. There is still no database.
Where the edit actually goes
Here’s the part I’m proud of.
When someone saves an edit, it doesn’t get written into a database. It gets written back into the text file and filed as a proposed change, exactly the way a developer’s work gets filed.
So a marketing manager clicking around on a Tuesday afternoon produces the same thing an engineer would: a clearly labeled change, with a full history, that we can approve, adjust, or undo. She gets click and type. We keep the safety rails. And nobody ever has to reconcile what the CMS thinks the site says against what the site actually says, because there’s only one copy of the truth.
That last point sounds like a technicality. It is the source of a truly enormous amount of pain on normal websites.
What it deliberately can’t do
I want to undersell this, because what we left out is the reason it works.
It’s for changing content, not inventing it. Reword a headline, fix a typo, update a number, swap an image: all good. Twelve people editing at the same time, content that has to exist in eight languages, a proper approval chain with scheduled publishing: not this. We didn’t try. The moment you build for those, you’ve rebuilt a real CMS badly. You should have just used one.
Editors change words and images. The layout stays out of reach. A very long headline can still push the spacing around and a broken image will still look broken, but nobody can take the page apart by accident. The worst outcome of a bad edit stays small and stays fixable.
Who it’s for
If you want a fast website that’s hard to break, and you also want your marketing team to own their own copy without filing a ticket and waiting two days, this is the sweet spot. It keeps everything good about part one and adds the one thing part one was missing.
Some projects really do need the twelve editors and the eight languages and the publishing calendar. That’s where a thin editing layer stops being enough and a real CMS starts to earn its cost, which is part three.