Here is the part that changes the maths. When a plugin developer ships a security fix, the details of the vulnerability usually become public. The changelog points straight at the unlocked door it just locked. Attackers read those same changelogs, write a script that looks for the old version, and then sweep the web for every site still running it. The scan is not targeted and it is not personal. It is a mop moving across the entire internet, and it brushes past your site whether you are watching or not.
Your backlog is not a to-do item. From the other side of the internet, it looks like an unattended door with the key hanging next to it.
This one runs a little geeky in the middle, but none of it needs a developer. Set aside an hour. Here is the whole routine.
Step 1. Back up before you touch anything
Updates occasionally break things, and the fix for a broken update is a working backup. Use your host’s snapshot tool or a backup plugin that stores a copy off your server. Create one fresh backup now and download the file to your own computer, or at least confirm the last backup completed successfully in your host’s panel. A backup you have never downloaded is a promise, not a plan.
Step 2. Find the backlog
In your WordPress admin, open Dashboard → Updates. WordPress lists available updates for core, plugins and themes, and labels the plugins with security fixes. Ignore the label at your peril: the ones marked as security updates are the exact ones bots are scanning for.
Then open Tools → Site Health. It will flag outdated software, abandoned plugins and problems with your PHP version in plain English. Site Health is the closest thing WordPress has to a mechanic’s report card, and most site owners never open it.
Step 3. Update in small batches
Do not select everything and cross your fingers. Update the security-flagged plugins first, then core, then the rest in groups of three or four. Between each batch, reload your site: the home page, a product page, the add-to-cart flow and your contact form. Each batch is a small experiment. If something snaps, you know exactly which update caused it, which makes the fix a five-minute job instead of an archaeology project.
If an update genuinely breaks something, roll back that single plugin from your backup or with the WP Rollback plugin, then leave it and come back to it. Never let a half-broken page sit live while you research. Put the old version back and carry on.
Step 4. Retire the dead weight
Check the “last updated” date on every plugin. A plugin that has not been updated for a year or more is not saving you work, it is parking risk on your server. Someone published that code, then stopped patching it. Whatever hole exists in it is permanent.
Two rules of thumb:
- If you do not use it, delete it. Deactivated is not disabled. Inactive plugins and themes still sit on the server with their code intact, and they can still be attacked. Delete unused plugins and remove spare themes except for one healthy default theme to fall back on.
- If it is abandoned but essential, replace it. Search the WordPress plugin directory for an alternative that does the same job and shows recent updates. Swap carefully, one plugin at a time, and test.
Step 5. Turn on auto-updates for the low-risk stuff
Since WordPress 5.6, every plugin list has an “auto-update” toggle. Turn it on for simple plugins that rarely conflict with anything: SEO utilities, backup tools, form basics. Leave auto-updates off for complex ones such as page builders and anything that touches your checkout, because those deserve a test after each update.
The result is a split rhythm. The boring plumbing updates itself overnight, and the delicate machinery gets your scheduled attention.
Step 6. Set the rhythm so this never happens again
Create a recurring calendar event, thirty minutes, once a week, called “site maintenance”. When it arrives, you do exactly this: open Updates, apply what is pending, glance at Site Health, done. A weekly half-hour keeps the backlog so shallow that no single update ever feels urgent again.
While you are in Site Health, check the PHP version your host has assigned. WordPress and every modern plugin run faster and more securely on the latest PHP. If Site Health flags an old one, ask your host to move you up a version. That is usually a five-minute support ticket.
The honest trade
Nobody maintains a site because it is thrilling. You do it because the alternative is a stranger in another timezone noticing your outdated plugin before you do, and deciding what your downtime is worth to you. One hour a week, in small batches, with auto-updates carrying the boring half of the load, is the entire strategy. It fits inside a lunch break, and it ends the quiet drip of risk that comes from an unmaintained site.
Want more like this? Join MOKU Club for free. Weekly resources, early access to new guides, and occasional templates you can actually use. Join below.
