Most WordPress sites get their updates one of two ways. Either everything updates itself overnight and someone finds out on Monday, or a developer logs in “when there is time”, which in practice means after the next security advisory.
We do neither. Security updates run as a schedule. Over the last three months one reseller partner put 255 site updates through it, in nine batches of about 28 sites each. The median site went from “update started” to “live” in 2 hours 14 minutes, and 245 of the 255 went live the same day.
This is the first of three articles on that process. This one covers the routine path. The second covers the sites that were not routine, which is where the effort goes. The third covers the end client’s side and the four ways an update can be approved.
Why Neither Default Works
Automatic updates are fine until a plugin update changes a checkout or a booking form. Then the live site is the test environment, and the first person to notice is a customer. The problem is not updates. The problem is unsupervised change.
Manual updates have the opposite problem. They depend on someone having time, and security fixes do not wait for that. A site that is updated “regularly” by hand is often updated every few months, in a hurry, with no record of what changed.
A schedule fixes both. Everyone knows when updates happen, every update is tested before it reaches the live site, and every site has a record.
The Routine Path, Step by Step
- A week’s notice. The reseller and their clients get an email listing the sites and the update window. Anyone with a reason to skip this round has time to say so.
- A fresh staging copy. On the day, the system builds a staging copy of each live site. It is a copy for this run only, not the staging site a developer may be working on.
- Updates on staging. WordPress core, plugins and themes are updated on the copy.
- Screenshots before and after. The same set of pages is captured on the live site and on the updated copy.
- A compare page. The reseller’s account manager opens one page per site that shows the two sets of screenshots side by side, and writes a note.
- Push to live. Once approved, the same updates are applied to the live site.
- A completion email. The client gets one email per site with a link to the before-and-after screenshots.
Most notes in step 5 are one line: “Good to go, thanks.” About 94% of the notes across the nine batches were routine approvals like that.
Where the 2 Hours 14 Minutes Goes
The interesting number is not the total. It is the split.
| Stage | Median per site |
|---|---|
| Run start to live | 2 h 14 min |
| Run start to approval | about 1 h 58 min |
| Approval to live | 29 min |
Almost two hours of it is waiting for a person to look at the screenshots. The machine part is fast. The human part is the queue.
That is the design goal, not a flaw. A security update has two jobs: apply the patch, and decide whether the site still works. The first is mechanical. The second needs someone who knows what the site is supposed to look like. The best thing a process can do is make that decision small: two screenshots, one note, one button.
Faster by Removing Work, Not by Rushing
In August a batch took five and a half to six hours from the first site starting to the last site going live. In October it took about two and a half.
The approval step did not get shorter by asking people to look less carefully. The time came out of everything around it: checks that run before the batch starts, so a site with a missing staging address is caught the day before rather than during the run. The next article covers the sites that still needed real work.
What This Means If You Look After WordPress Sites
If you manage more than a handful of sites, the questions worth asking are simple:
- When do updates happen, and does anyone know in advance?
- Where are they tested before they reach the live site?
- What does the person approving them actually look at?
- What does the client receive afterwards?
If the answer to the second question is “on the live site”, that is certainly one way to get customer feedback.
If updates are still a login-and-hope job for you, I am happy to compare notes.
