Most of what goes wrong with a website doesn’t happen because somebody broke in. It happens because somebody changed something.
That includes us. Anyone who works on live systems long enough has made a change that did something they didn’t intend. The question isn’t whether it happens, it’s how long the site is broken afterwards and whether anything is lost.
So here’s how we work, plainly, because it’s worth knowing what to expect from whoever maintains your site.
Before a change is made, the current state is saved. Not “there’s a backup from last night” — the specific thing about to be changed, exported first, with the exact command to put it back written down before anything is touched.
Changes go one at a time, with the result checked before the next one starts. Ten changes at once means ten suspects when something breaks.
Nothing is deleted. Content that’s no longer wanted gets unpublished, not removed. A file that’s replaced gets kept. Storage is cheap and regret isn’t.
And the check afterwards is done against the live site, not against what the settings screen claims. A setting that says it saved and a page that actually shows the change are two different facts, and only the second one counts.
We rebuilt a site this month and went in with the rollback commands written down first. We ended up needing them — something went wrong mid-way, the site went down, and it came back from a snapshot taken before the work started. Total damage: an afternoon.
Without that snapshot, the same mistake would have been a genuinely bad week for somebody’s business. The discipline isn’t cautious. It’s the difference between an inconvenience and a disaster.