Sometimes, yes. Updates can break layouts, functionality or a site entirely, usually where a plugin or theme has not kept pace with a change.
But the sites that break during an update are almost always the ones that were left the longest, and not updating is far more dangerous than updating badly.
The answer is not to avoid updates. It is to test them somewhere that is not your live website.
WordPress core changes, and a plugin that has not been updated to match stops working. This is the most common cause, and it is really a symptom of using abandoned plugins rather than a problem with updating.
Two plugins that both worked yesterday can conflict after one of them changes. The more plugins you run, the more likely this becomes, which is another argument for keeping the list short.
Code added directly to a theme rather than to a child theme gets overwritten when the theme updates. Years of small tweaks disappear in one click. This is the one that hurts most, because the work is genuinely gone unless there is a backup.
Skipping eighteen months of updates and then applying them all at once is a different and much riskier operation than applying them as they arrive. Everything changes simultaneously and there is no way to isolate what caused a problem.
An update that breaks a layout is visible, annoying and fixable that afternoon. An unpatched vulnerability is invisible until it is not.
Plugin vulnerabilities are published. When a security flaw is disclosed and patched, the patch notes tell everyone exactly what the flaw was, and automated tools begin scanning for sites that have not applied it. Being behind on updates is not a passive state. It is a published list of ways into your website.
There is a version of this that plays out constantly. A site breaks during an update in 2024, so the business decides updates are dangerous and stops. In 2026, the site is compromised through a vulnerability that was patched in 2024. The original caution caused the eventual breach.
Nobody currently owning your WordPress updates?
If updates are something that happens when someone remembers, that is worth changing before it becomes urgent. We handle website development and WordPress maintenance for businesses across the UK, with updates tested on staging before they touch your live site.
Security releases immediately. Everything else on a regular schedule, monthly at minimum, tested on staging first.
The distinction matters.
A WordPress security release exists because a vulnerability is publicly known, so the window between disclosure and automated exploitation is short. That is not a job for next month’s maintenance slot. Feature updates and minor plugin releases can wait for a scheduled window where they can be tested properly.
Make sure backups are:
Automated, so they happen whether or not anyone remembers.
Stored off the server, so a compromise or a hosting failure does not take the backups with it.
Tested by actually restoring one. An untested backup is an assumption. The moment you need it is a bad time to discover it has been silently failing for four months.
Plugins get abandoned, themes stop being maintained, and PHP versions reach end of life and stop receiving security patches. None of these announces themselves in your dashboard in a way that feels urgent.
This is why maintenance is more than clicking update. Part of it is noticing that something you depend on has quietly stopped being supported, and replacing it before it becomes the way somebody gets in.
For most businesses, this is a handful of hours a month, and the value is not in the hours. It is in it being somebody’s job.
Updates applied on a schedule, tested on staging, with a record kept.
Backups automated, stored remotely, and tested.
Plugin and theme list reviewed periodically, with abandoned components replaced.
PHP and server software kept current.
Uptime and security monitoring, so problems arrive as alerts rather than as phone calls from customers.
Someone to call when an update does break something, which occasionally it will.
The last point is worth being straight about. Even done properly, an update will sometimes cause a problem. The difference is that it happens on staging instead of live, and if it does reach live, you have a tested backup and someone whose job it is to fix it.
Restore your most recent backup, then work out which update caused the problem by reapplying them one at a time on a staging copy. If you have no backup, deactivating the most recently updated plugin via your hosting file manager will often restore access to the admin area, which gives you somewhere to work from.
Back up, apply the updates on a staging copy first, then check the functionality that matters rather than just the appearance. Update in small batches so that if something breaks, you know what caused it. Where a plugin update is flagged as a security release, prioritise it and test quickly rather than waiting for a scheduled window.
For WordPress security releases, generally yes. For plugins and themes it depends on how much you can afford a surprise, because automatic updates apply without anyone checking the result. A reasonable middle position is automatic security updates plus scheduled, tested updates for everything else.
At least daily for a site that changes regularly, and before every update regardless. If you take orders or capture enquiries, consider how much data you can afford to lose and work backwards from that. A weekly backup on a site that takes daily orders means potentially losing a week of orders.
We look after WordPress sites for businesses across the UK, from our base in Manchester. Updates tested on staging, backups you can actually restore, monitoring that tells you before your customers do, and senior developers on the end of the phone. No juniors, no outsourcing.