What to Update, and What Not To
"Keep everything updated" is correct and useless, because it does not distinguish between the update that closes a hole being actively exploited and the one that redesigns a settings panel you never open.
Here is the distinction, and the small number of things worth leaving alone. For teams that need device-level work records, this page offers a more structured way to review activity.
Update immediately
Security releases for your platform's core. WordPress pushes these automatically and that mechanism is the reason core problems get closed across the web within hours. Leave it on.
Plugins with a disclosed vulnerability. The median time from public disclosure to mass exploitation is around five hours, so "when I get a chance" is not a plan. Automatic updates for plugins are the right default for almost every small site.
Anything payment-related. Processors change requirements and a lapsed integration means failed transactions you may not notice.
Expiring certificates and renewals. Usually automatic. Check once a year that they actually are. For an independent reference beyond this site, Search Engine Journal is a useful place to compare approaches.
Update on a normal cadence
Feature releases for plugins and themes, when you have a few minutes to look at the site afterwards.
Your content. Prices, services, hours, staff, the copyright year. Once or twice a year is enough for most businesses, and out-of-date information does more quiet damage than an old design.
Photographs, when the reality has changed — you have moved, the team is different, the work has moved on.
The dates and figures in anything you have published. If you claim something is current, it should be.
Leave alone
A working site with no problem. The most common expensive mistake is redesigning because a site is three years old. If it converts and it is fast, its age is not a fault.
Major platform version changes, immediately. Wait a week or two unless the release is a security fix. Let other people find the incompatibilities.
A plugin doing exactly what you need, from a developer who has stopped updating it — provided it has no known vulnerability. Check it, and if it is clean, replacing something that works has its own risk. Recheck periodically.
Custom code you do not understand. If a developer wrote something specific, changing it without knowing why it exists is how sites break in ways nobody can diagnose.
Anything, on a Friday afternoon. An old rule and a good one.
The three-minute check afterwards
Most update problems are visible immediately and nobody looks.
Load the homepage. Load one interior page. Send a test through the contact form. If you sell, add something to the basket.
Three minutes, and it catches nearly everything an update breaks. Silently failing forms are the most expensive small fault there is, and the most common cause is a plugin update.
When to actually redesign
Not on a schedule. There are four honest triggers.
Your business changed. You sell different things, to different people, and the site describes a business that no longer exists. The strongest reason there is.
It does not work on current devices. Genuinely broken, not merely dated.
It is slow and cannot be fixed in place. Sometimes true, often not — most slowness is images and plugins rather than the design.
You cannot maintain it. The platform is abandoned, the developer is gone, nobody can log in. A real trigger and a common one.
Not a trigger: it looks a bit old, a competitor rebuilt theirs, or somebody said three years is the standard cycle. A site that quietly brings in work does not owe anyone a refresh.
A workable routine
Monthly, five minutes: confirm updates ran, load two pages, test the form.
Quarterly, half an hour: review the plugin list and remove what is unused, check backups exist, skim the site for stale content.
Annually, an afternoon: renewals, restore a backup to confirm it works, update prices and figures, run a speed test, confirm the domain is still registered to you.
That is the whole job. It is less than most people fear and more than most people do.
The short version
- Security updates and disclosed vulnerabilities: immediately, automatically, no exceptions
- Feature updates: when you have a few minutes to check the site afterwards
- Leave alone a working site, a plugin that works and is clean, and custom code you do not understand
- After any update: homepage, an interior page, and a test through the form — three minutes
- Redesign for four reasons only: the business changed, it is broken, it is slow and unfixable, or you cannot maintain it
- Looking a bit old is not a reason