Not all updates are equal
A typical business WordPress site has fifteen to twenty-five plugins, and most months several have updates. The great majority apply without incident. A few categories account for nearly every break we have seen, and knowing which they are is how the monthly update round stays boring.
The categories to watch
Page builders and their add-on packs. Elementor, Divi, WPBakery, and the third-party widget packs that extend them. Major versions change how layouts render, how CSS is generated and how responsive breakpoints work. An update can shift spacing across every page, break a custom widget, or, when an add-on pack is updated before the builder it depends on (or vice versa), take the editor down. Always update builder and add-ons together, on staging, and check several page types.
WooCommerce and anything that touches it. WooCommerce ships frequently and its extensions (payments, shipping, subscriptions, bookings) each declare a supported version range. An extension a version behind can break checkout. Database schema updates run on the first admin load after updating; on a busy store, do that on staging first and at a quiet hour on live. Test a full checkout after every WooCommerce update, without exception.
Forms. Gravity Forms, WPForms, Contact Form 7, Fluent Forms. Updates change field rendering, validation, and notification handling. A form that looks fine and no longer sends is the classic silent break. Submit every form after updating and confirm the email arrives.
Security and firewall plugins. Wordfence, Sucuri, iThemes. New rules can block legitimate things: the booking widget's requests, a payment gateway's webhook, the REST API a theme depends on. After updating, check anything on the site that calls in from outside.
Caching and optimisation plugins. WP Rocket, LiteSpeed Cache, Autoptimize, Perfmatters. A changed default for script deferral or CSS combination can break JavaScript on the front end while the admin looks perfect. Clear the cache after updating and load the site logged out, on a phone.
The theme. A parent theme update overwrites any customisation made directly to its files. If the site has no child theme, a theme update can erase months of tweaks. Check for a child theme before updating a parent, and if there is none, either create one first or do not update.
Anything abandoned. A plugin whose author stopped updating it two years ago has no updates to break the site, but it breaks when WordPress or PHP moves past it. These are the ones to replace before they become emergencies rather than to watch.
Major version jumps. Any plugin moving from 4.x to 5.x. Semantic versioning means the author is warning you that behaviour changed. Read the changelog.
How we run a monthly round
1. Refresh staging from production. Same files, same database, same plugins, today's content. Testing against last month's copy misses things.
2. Read the changelogs. Two minutes per plugin. We are looking for "major", "breaking", "requires", "deprecated", and anything about the features this site uses. A changelog that says "improved compatibility with WooCommerce 9.x" on a store running 8.x is a stop.
3. Update in groups. Core first if there is one. Then the risky categories above, one group at a time, checking between groups. Then the rest. If something breaks, the group that was just updated contains the cause.
4. Test the fixed list. For every site, the same checklist: home, a service page, the contact page load and look right on a phone; every form submits and the email arrives; the booking flow works to confirmation; if a store, a checkout to a test payment; admin loads; the error log is clean. Per site, ten to twenty minutes. The list is written per site because each has its own critical paths.
5. Note anything held back. A plugin not updated because its changelog or the staging test says it will break gets a line in the site's notes with the reason and the version, so next month's round knows.
6. Apply to live. Same order, at a quiet time for that business. Back up first. Clear caches. Run the short version of the test list on live.
7. Report. What was updated, what was held and why, what was tested, and anything the owner should know. One paragraph in the monthly note.
What is deliberately not done
Auto-updates for anything in the watch categories. WordPress can update plugins automatically, and for a site nobody maintains it is better than nothing, because unpatched vulnerabilities are worse than the occasional break. For a site on a care plan, auto-updates are off for the risky categories and the round above replaces them, because a break at 3am with nobody testing is the thing the plan exists to prevent. Security-only releases for core stay automatic.
The occasional break anyway
Sometimes the staging test passes and live breaks, because of a caching difference or a plugin that behaves differently under real traffic. That is what the pre-update backup and the rollback are for: revert, note it, investigate on staging. The measure of the process is not that nothing ever breaks; it is that when something does, it is on staging, or it is undone in minutes, and it is never a customer who finds it.
This is the update section of our care plan, described in the same words in the plan itself. It is most of what the monthly fee is for, and the watch list above is why the fee buys quiet.