Updates close known vulnerabilities, which is why delaying them is the most common route to a compromised site. They also occasionally break things, which is why applying them directly to a live site is how sites go down. The process that avoids both is a backup, a staging copy, and applying them in a deliberate order.
Why delaying is the bigger risk
An update fixing a security flaw is also an announcement that the flaw exists. The details become public, and automated systems start looking for sites that have not applied it.
That is why the window between a fix being released and being applied matters so much. A site running a version with a known, published vulnerability is not waiting to be targeted specifically; it is waiting to be found by something scanning everything.
Most compromised small business sites were running software with a fix available. Not an unknown flaw, a known one with a patch that had been sitting there for months.
Why applying blindly is also a risk
Updates change behaviour. A plugin update can conflict with a theme, a platform update can break a plugin that has not kept pace, and an update to something that has not been maintained in two years can simply stop working.
Applied directly to a live site, that becomes a customer discovering your site is broken. Applied to a copy first, it becomes a Tuesday morning you spent twenty minutes on.
The order that works
- Take a backup you have confirmed can be restored. Not a backup that exists, one you know works, because the moment you need it is not the moment to discover it does not.
- Apply to a staging copy first, which is a duplicate of the site not visible to the public.
- Update one thing at a time where practical, so a breakage identifies its own cause.
- Check the site properly, including the pages that matter and at least one form submission.
- Then apply to the live site, and check again.
The step that gets skipped is the last check. An update applied successfully to staging can still behave differently live because of caching, a different configuration, or something the staging copy did not include.
What to check after any update
A short list, run the same way every time, takes five minutes.
| Check | Why |
|---|---|
| Homepage and two service pages | Catches layout and template breakage |
| Submit the contact form | The most common silent failure after an update |
| Tap the phone number on a phone | Confirms it still dials |
| One page on a mobile screen | Layout breaks often appear only at narrow widths |
| Check for console errors | Catches script failures that are invisible visually |
The form check is the important one. A form that silently stops delivering after an update can cost weeks of enquiries before anyone notices, because nothing appears broken to a visitor.
Priority, when you cannot do everything
Not all updates are equal, and treating them identically means either doing them all urgently or none at all.
Security releases should be applied promptly, ideally within days. These are usually small, narrowly scoped, and unlikely to break anything.
Major version updates of the platform itself deserve staging, testing, and a quiet moment. These are the ones that break things.
Feature updates to plugins you barely use can wait for a scheduled window, or prompt a better question about whether the plugin is needed at all.
The plugins you are not using
A deactivated plugin is still files on the server, and files with known vulnerabilities can be exploited whether or not the plugin is active.
Every update cycle is a chance to ask whether each one is still earning its place. Deleting rather than deactivating removes both the maintenance burden and the exposure, and most sites are carrying several installed years ago for something that ended.
When something breaks anyway
It will occasionally, and the response matters more than the prevention.
Reverse the most recent change first, since the cause is nearly always the thing you just did. Restoring a single plugin to its previous version is faster and less disruptive than a full restore.
Where the cause is not obvious and the site is down, restore from backup and diagnose afterwards on a copy rather than in public. Investigating a broken live site under pressure is how small problems become long outages.
A realistic schedule
Security releases as they appear. Everything else monthly, on a chosen morning, on staging first, with the five-minute check afterwards.
That is perhaps half an hour a month for a typical small business site, and it is the difference between the two failure modes: a site compromised through a patched vulnerability, or a site broken by an update nobody tested. Both are avoidable and both are common, and what happens when the first one is not avoided is set out in the day after a site is compromised.
Frequently asked questions
Why do delayed updates cause compromises?
A security update is also a public announcement that the flaw exists. Automated systems then scan for sites that have not applied it, so the window between release and installation is when sites get found.
Should I apply updates immediately?
Security releases promptly, within days. Major platform versions deserve a staging copy and testing first, since those are the ones most likely to break something.
What is a staging site?
A duplicate of your site that is not publicly visible, used to apply and test changes before they reach the live version. It turns a customer discovering a broken site into a quiet twenty minutes.
What should I check after an update?
The homepage and two service pages, a submitted contact form, the phone link on a mobile, one page at a narrow width, and the browser console. The form check is the one that matters most.
Should I delete plugins I am not using?
Yes. A deactivated plugin is still files on the server, and a known vulnerability in it can be exploited whether or not it is active. Deleting removes both the exposure and the maintenance.
What do I do if an update breaks the site?
Reverse the most recent change first, since that is nearly always the cause. If it is not obvious and the site is down, restore from backup and diagnose on a copy rather than in public.
West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.
Putting off updates because the last one broke something?
We run updates on a staging copy with a tested backup behind them, so nothing reaches your live site untested.
Start a Conversation