The worst calls I get all start the same way. Somebody rings, slightly out of breath, and says the site has gone. Sometimes it is a white screen. Sometimes it is a plugin update that took the checkout with it. Once it was a hosting company that had quietly stopped taking backups eight months earlier and nobody had checked.
Almost every one of those calls would have been a twenty minute job instead of a bad week if two things had been set up on day one. Backups you can actually restore from, and somewhere safe to test changes before they hit the live site.
Neither is exciting and neither shows up on the homepage. They are still the first two things I put on any WordPress site I look after.
What most sites actually have
When I take over a site, I ask where the backups are. The answers I get, roughly in order of how often I hear them:
The host does it. Sometimes true. Often it is a daily snapshot kept for seven days, stored on the same machine as the site, and nobody has ever restored one.
There's a plugin. Installed in 2021, licence expired, last successful run eighteen months ago. The plugin has been emailing failure notices to an address nobody reads.
I think so? This is the honest one, and it usually means no.
None of those are stupid answers. Backups are the definition of a job that feels finished the moment you set it up. The problem is that a backup you have never tested is a promise, not a safety net.
A backup that is genuinely worth having
Three things make the difference between a backup and a comfort blanket.
It leaves the server. If your only copy sits on the same box as the site, a host level failure takes both. Push it somewhere else. Object storage, a separate cloud account, anywhere that is not the thing you are protecting against.
It includes the database. Files alone are half a site. Every post, page, order, user and setting lives in the database. I have seen file-only backups sold as full backups more than once.
You keep more than a week. Some problems are slow. A dodgy plugin or an SEO change can take three weeks to show up in the numbers. Daily for a fortnight, weekly for a couple of months, monthly for a year is plenty for most small business sites.
For a brochure site that changes rarely, daily is generous. For anything taking orders or bookings, daily is the floor, and you want to know how much data you would lose if it went at four in the afternoon.
The bit everyone skips
Restore one. Actually do it. Not in your head, not by looking at the file list and deciding it looks about right.
Pull last night's backup down, stand it up somewhere separate and click round it. It takes half an hour and it is the only way you will ever know whether the thing works. Roughly a third of the sites I have inherited had backups running and failing silently, and nobody found out until the day it mattered.
Once a year is enough for most sites. Put it in the calendar next to the domain renewal so it actually happens.
Staging, in plain English
A staging site is a private copy of your live site that only you can see. Same theme, same plugins, same content, different address. You break things there instead of in front of customers.
Most decent hosts will give you one at the click of a button now. If yours will not, that on its own is a reason to look at moving.
The workflow is dull and that is the point. Copy live to staging. Do the updates or the changes on staging. Look at the pages that matter, which for most sites means the homepage, a service page, the contact form and the checkout if there is one. Then push it live, or apply the same changes to live if pushing would overwrite content that has changed since you copied.
Why updates on live break sites
The single most common cause of a broken WordPress site is somebody clicking update all on a Friday afternoon. Not because updating is wrong. You have to update, security patches are the whole reason plugins get updated in the first place.
It breaks because plugins are written by different people who have never spoken to each other, and occasionally two of them disagree in a way that only shows up in your specific combination. That disagreement happening on a staging copy is a Tuesday morning. On live it is lost enquiries and a phone call to me.
If you take one thing from this: never update a live site you cannot roll back within ten minutes.
The routine I run
For sites I maintain it is monthly, and it looks like this.
Copy live to staging.
Update WordPress core, then plugins, then the theme, in that order.
Walk the four or five pages that actually earn money.
Check the contact form sends and arrives.
Push live, then walk the same pages again.
Note anything that looked odd, even if it fixed itself.
It takes under an hour on a normal site. When a plugin does go wrong, I find out on my own time rather than the client finding out from a customer.
What this costs
Less than people expect. Off-server backup storage for a small business site is a few pounds a month at most. Staging is included with most managed WordPress hosting. The real cost is the hour a month, and that hour is cheap set against a day of emergency work and however much business went missing while the site was down.
If you run a shop the maths gets more one sided, because the downtime has a price you can actually calculate.
Where to start if you have none of this
Do these in order. Find out what backups you currently have and where they live. Restore one. If it fails or you cannot find one, get an off-server backup running this week. Then ask your host about staging.
If you would rather somebody just checked, I do a free thirty minute surgery where I look at what you have got and tell you straight. No pitch. Book a slot and bring your hosting login.
More on the WordPress side of what I do is on the WordPress services page. If you are running a bigger ecommerce setup and the question is really about a platform rather than a plugin, that is my other site's territory and there is more on it at Headless Digital.
Free 30-min surgery
Working on something similar?