Updating your website yourself without breaking it

A site built for owner editing is a deliverable you demand at the brief, not a capability that appears after launch.

Every owner wants the same small thing: to fix a typo, swap a photo, publish a short announcement, without filing a request and waiting a week for the developer. And every owner carries the same quiet fear: that one wrong click will take a page down in front of customers. Both feelings are legitimate, and the difference between the sites that satisfy the first feeling and survive the second was decided at the build, not at the moment of the edit.

The honest framing is that self-editing is safe in layers. Changing words inside an existing block, replacing an image with one of similar size and shape, publishing a post: these are owner territory, and a site should be built so they are easy. Changing layout, moving sections, touching forms or payments or anything that moves customer data: this is developer territory, because these changes alter how the page works, not merely what it says. The line to remember is exactly that one: does the edit change what the page says, or how it behaves.

The failure versions all start as innocent edits. The text pasted from a document that carried hidden formatting with it and dragged the layout out of shape around it. The section deleted to tidy a page, which turned out to be unrecoverable, because no backup existed to restore it from. The price corrected on the live page while a search result kept showing the cached old figure to everyone who searched, for weeks after the fix. None of these people were careless; each was editing beyond their layer without knowing there were layers.

The practice that keeps self-editing safe is short enough to pin above the desk. Look at every change in a preview before it reaches the live site. Change one thing at a time, so a broken page has one suspect instead of five. Check the page on a phone before publishing, because that is where most customers meet it. Keep the backup discipline alive, meaning restores actually tested, not just copies scheduled. And keep a written one-page list of what is yours to touch and what goes back to the developer.

The deeper point is that owner editing is a deliverable, not a given. A site can be handed over with a real editing surface, sensible defaults, and a boundary document, or it can be handed over as a sealed box that breaks when opened. If you intend to edit, say so in the build brief, before the plan and the numbers exist, because designing for safe editing is different work from designing a site only its builder can touch.

We hand over sites with the editing boundary written down, because a client who is afraid of their own website stops updating it, and a frozen site rots in public. Guidance, not guarantees: this essay is the boundary, not the mechanics; the upkeep calendar lives elsewhere, the staging idea has its own essay, and the specifics of your build belong with whoever holds it.