We apply several hundred WordPress updates a month across our care plan clients. Here is what actually causes problems, based on the ones that did.
WordPress core updates are, by some distance, the safest thing that happens to your site. The core team tests against an enormous installed base and backwards compatibility is close to a religion there. In eleven years we have had two core updates cause a client problem, and both were on sites running PHP versions that were already unsupported.
The plugins that break things share a profile: they modify the admin heavily, they hook into things they should not, or they were last updated a long time ago and have started to rot against a moving platform.
An abandoned plugin does not break on the day it is abandoned. It breaks eighteen months later, when something it depended on changes, and by then nobody remembers installing it.
Both work. Both are maintained. Both want to control the checkout, or the sitemap, or the image sizes. This is the failure we see most often on sites we inherit, because it is invisible until something forces the two to interact.
Every update goes to a staging copy first. An automated pass checks that the key pages still return 200, that the checkout still reaches the payment step, and that nothing new has appeared in the error log. Then a person looks at it. That last step is the one that cannot be automated away, and it is the reason our clients’ sites do not fall over on a Tuesday morning.
Reduce the number of plugins. Every one is a dependency on somebody else’s continued interest. We audit plugin lists for free for anyone who asks, client or not — it takes us an hour and it is usually the highest-value hour in the relationship.