The update badge says 14. You have a Tuesday morning, 60 client sites, and a rule that says nothing ships without a glance at what changed. The glance is where most agencies cheat, because a changelog is boring and the badge is not. Done properly it takes about four minutes per plugin, and it catches the one update in fourteen that will take a checkout page down before it runs, not after.
What a changelog is actually telling you
A WordPress plugin changelog is a developer's own account of what they touched. It is not audited, not standardised, and not always honest, but it is the only pre-update signal you get for free. Read it for four things, in this order: how big the version jump is, whether any line mentions something your sites depend on, whether the plugin's compatibility headers moved, and how the developer talks about their own mistakes.
The version number is the first filter. Most serious plugin authors follow semantic versioning, where the major number goes up for "incompatible API changes", the minor for functionality added "in a backward compatible manner", and the patch for "backward compatible bug fixes" (semver.org). Not every plugin shop reads the spec, but a jump from 4.9.3 to 5.0.0 deserves a different Tuesday than 4.9.3 to 4.9.4.
The compatibility headers are the second filter. "Tested up to" is the WordPress version the author says they tested against, and the directory ignores the minor part of it, so "6.9" covers 6.9.x. "Requires PHP" and "Requires at least" come from the plugin's main PHP file since WordPress 5.8, not the readme (WordPress plugin handbook, "How your readme.txt works"). When a changelog line says "minimum PHP is now 8.1", that is a hard break for every site still on 8.0, and the symptom is a white screen, not a graceful error.
The four-minute read
Open the plugin's page on wordpress.org, or its own changelog if it is premium, and read only the entries between the version installed and the version on offer. If a site is three releases behind, all three entries count, because you are installing all three at once.
Minute one: note the version jump and whether any entry carries a word from the danger list below. Minute two: search the entries for the names of things your sites use with this plugin, meaning the theme, the page builder, WooCommerce, the form plugin, the caching layer. "Reworked the Elementor widget" is harmless on 50 sites and a checkout risk on the 10 that build product pages with it. Minute three: check whether "Requires PHP" or "Tested up to" changed, and compare against the oldest PHP version in your portfolio. Minute four: decide the tier, which is the subject of the next section.
The vocabulary that should slow you down, in rough order of how often it bites:
- "Breaking", "removed", "deprecated", "dropped support for", "no longer", "renamed", "migrated settings", "database upgrade", "run the migration", "requires reauthorisation", "new minimum". Any one of these moves the update out of the batch.
- "Refactored", "rewrote", "new architecture", "major rewrite of", "replaced the X engine". These are not breaking by intent, but a rewrite is where regressions live, and the author's own testing rarely covers your client's 2019 theme.
"Fixed", "improved", "security fix", "compatibility with WordPress 6.x" and "updated translations" are the lines you are hoping for. A security fix is the one entry where the risk of waiting beats the risk of updating, so it moves the plugin to the front of the queue rather than off it.
Sorting updates into three tiers
Reading the changelog is only useful if it changes what you do next. Sort every update into one of three tiers before you touch a site; the split is about blast radius, not trust in the developer.
| Tier | What the changelog shows | How it runs |
|---|---|---|
| Batch | Patch or minor bump; only "fixed", "improved", "compatibility", "translations"; no header changes | All sites in one pass, restore point first, screenshot diff after |
| Canary | Minor bump with a rewrite line, or any mention of a builder, theme, WooCommerce or a form plugin you rely on | Two or three representative sites first, wait 24 hours, then the rest |
| Hold | Major bump, "breaking", removed features, new PHP or WordPress minimum, settings migration, re-authorisation | One test site, manual checklist, client told in advance if the change is visible |
The numbers matter for a 60-site portfolio. If 14 plugins have updates in a week and the usual split is roughly ten Batch, three Canary, one Hold, the Batch tier is 600 individual plugin updates that run unattended with a restore point, and the Canary tier is six sites checked by hand on day one and 174 updates on day two. The Hold tier is one plugin on one test site. Four minutes times 14 plugins is 56 minutes of reading to protect 840 update operations. At $100 an hour that is $93 of time, against a single checkout outage that, on a store doing $2,000 a day, costs the client more than that before you have finished reading the ticket.
When the changelog lies, or says nothing
Three cases break the routine. The first is the empty changelog: "Bug fixes and improvements", repeated for every release. Treat a plugin that does this as Canary by default: you have no information and the author has told you they will not give you any. If it also has a large footprint, say a builder or a commerce extension, it is a candidate for replacement in your next plugin sprawl audit.
The second is the understated entry. "Updated the settings page" can mean a redesigned admin screen that moves every option, and "improved performance" has preceded more than one cache rewrite that broke a site's custom rewrite rules. The tell is timing: if a "minor" release took six weeks from an author who usually ships weekly, something large landed.
The third is the release-day regression. Even a careful author ships a 5.2.0 that is fine and a 5.2.1 two days later that says "fixed fatal error on PHP 8.2 introduced in 5.2.0". The cheap defence is a delay rule: nothing in the Batch tier runs on the day it is released, and nothing in Canary runs within three days. WooCommerce core, for one, publishes a five-week release cycle with betas on Mondays and majors on Tuesdays (developer.woocommerce.com release calendar), which makes a "Thursday after the Tuesday" rule easy to keep for stores.
What the tier changes on the day
The tier decides the safety net, not just the order. A Batch update needs a restore point taken immediately before and a screenshot comparison immediately after, and if the diff is clean on the first 20 sites you let the rest run. A Canary update gets the same, plus a human on the two or three test sites clicking through the checkout, the contact form and the one page the client always complains about. A Hold update gets a written checklist, a client email a day before if anything visible changes, and a rollback rehearsed on the test site before it is attempted on a live one. The earlier post on safe WordPress updates covers the restore point and diff mechanics.
One habit worth adding: paste the one changelog line that made you choose Canary or Hold into the site's internal note before the update runs. When something breaks three weeks later, the note is how you remember that 5.0.0 "migrated settings to a new table": a 10-minute rollback instead of an hour of guessing.
WPClientHub shows the available version and its changelog next to each update across your sites, takes the restore point and screenshot diff for you, and holds Canary and Hold updates in an approval queue so they cannot run by accident in a batch. It is free for 3 sites, with paid plans from $19/month.
Where this leaves you
A changelog is four minutes of reading that sorts an update into Batch, Canary or Hold before it touches a client site, and the sort is what decides whether a bad release costs you a rollback or an afternoon. The vocabulary list and the delay rule do most of the work; the tiers make the decision repeatable. If you want the changelog, the restore point and the approval queue in one place while you do it, start with your three worst sites on the free plan.