There are two ways to get this wrong, and both are common.
Update everything the moment a notification appears, and eventually one will break your checkout on a Friday afternoon. Leave updates for months because the last one caused problems, and you leave publicly documented security holes open on a live site.
Neither is necessary. Here is a realistic approach to when you should update WordPress plugins, and how to do it without gambling every time.
Why the timing genuinely matters
When a plugin vulnerability is patched, the details are published. That disclosure tells everyone — including people scanning for vulnerable sites — exactly what the flaw is and which versions have it.
Automated scanning for a newly disclosed vulnerability typically begins within days. Sometimes hours.
The window between a patch being released and being applied is where most compromises happen. It is the one variable you fully control.
This is why "we update every few months" is a security posture, not a maintenance schedule. It means running known-vulnerable code for weeks at a time.
Not all updates are equal
Treating every update the same is the root of the problem. Sort them first.
Security releases — within 24 to 48 hours
If the changelog mentions a security fix, a vulnerability, or a CVE, apply it now. These are the updates worth some risk of breakage, because the alternative is worse.
If a plugin has an active vulnerability being exploited and no patch exists, deactivate and delete it until one does.
Minor releases — weekly
Bug fixes and small improvements. Version 3.4.1 to 3.4.2. These rarely break anything. A weekly pass is fine.
Major releases — monthly, and tested
Version 3 to version 4. These change how things work and are where breakage lives. Read the changelog, test on staging, and never apply one straight to a live site during business hours.
WordPress core — quickly for security, carefully for major
Core security releases are well tested and safe to apply promptly. Major core versions deserve the same staging treatment as a major plugin release.
A schedule that works in practice
- Daily: check whether anything you run has a security release. Automated notifications handle this.
- Weekly: apply minor and patch updates. Check the site afterwards.
- Monthly: apply major updates on staging, test, then push live.
- Quarterly: audit the plugin list. Delete anything unused or abandoned.
For most small business sites that is about thirty minutes a week, plus an hour a month.
Should you turn on automatic updates?
Partly. Automatic updates for WordPress core security releases are sensible and should be on. The same goes for minor plugin releases on a simple brochure site with a good backup running.
Do not auto-update major plugin versions, anything touching payments or checkout, or a site running heavy customisation. The failure mode is a broken site nobody notices for hours.
If you do enable automatic updates, you need two things alongside them: daily backups and uptime monitoring. Otherwise you have automated the risk without automating the recovery.
How to update without breaking things
- Back up first. Files and database. Every time.
- Use staging for anything major. A copy of the site where breakage costs nothing.
- Update in small batches — three or four at a time, not thirty. When something breaks you want to know what caused it.
- Check the site after each batch. Homepage, a key landing page, the contact form, and checkout if you have one.
- Avoid Friday afternoons. Not superstition — if something breaks, you want to be available to fix it.
The plugins nobody thinks about
Two blind spots cause a disproportionate number of problems.
Deactivated plugins. Switching a plugin off does not remove its code from the server. In many cases those files can still be reached directly. If you are not using it, delete it.
Abandoned plugins. If the last update was two years ago, no patch is coming when a vulnerability is found. Check the WordPress.org listing for the last-updated date and plan a replacement before it becomes urgent.
When an update breaks the site
It will happen eventually. Stay calm and work in order: restore the backup if the site is down and revenue is affected, then reproduce the problem on staging where you have time to think.
Identify the specific plugin, check whether a newer version already fixes it, and if not, roll that one plugin back rather than everything. Then report the bug — plugin authors generally fix things faster than you expect when given a clear report.
If you end up on a blank page, our guide to the WordPress white screen of death covers the diagnosis.
The honest trade-off
Updating carries a small risk of breaking something you can usually fix in minutes. Not updating carries a growing risk of a compromise that takes days to recover from and damages your search rankings on the way.
The second risk is the larger one, and it compounds. But that is only true if updates are done properly — with backups, staging and a check afterwards. Reckless updating is not the answer to slow updating.
If this is not a good use of your time
Most business owners should not be spending Tuesday mornings reading plugin changelogs. Our managed website plans cover updates tested on staging before they go live, daily backups, uptime monitoring and someone who fixes it when something does break.
If your concern is security specifically rather than general maintenance, our security monitoring service tracks the plugins you run against published vulnerabilities and patches quickly when one is disclosed.
Get in touch and tell us what you are running. We will tell you honestly whether you need either.
Get Shielded
We build, host, secure and monitor business websites — cleaning up hacks and keeping sites online for clients across the UK, USA, Australia and the UAE.
