The Question Nobody Thinks to Ask Their Web Developer

When a security problem turns up in a piece of software that half of a developer's clients are running, what actually happens next?

The honest answer, at most small shops, is that somebody works through a list. Client by client, site by site, in whatever order the folders happen to sit in. And somebody is always at the bottom of that list.

I manage multiple WordPress sites for a living, forty of them, and for years I was the person working through the list. Every site I look after runs a small piece of software I wrote to keep an eye on things. When it needed updating, I logged into forty sites by hand. Upload, activate, log out, next one.

Done properly, that took an evening. The tedium was never really the problem though. The problem was that a job like that tends to get abandoned three quarters of the way through, and then some sites are running this month's version and some are six months behind, and nobody can tell you with confidence which is which.

Now the Update Goes Out By Itself

Last August I sat down with Claude, the AI assistant I work with most days, and we built the thing that fixed it.

Now I make the change once and mark it ready. A service called GitHub Actions packages it up, and every site I look after notices the new version and installs it without any help from me. I do not log into anything.

The last time I ran it, the update reached 39 of the 40 sites within minutes. The fortieth turned out to be a wrong address in my own notes rather than a problem on the site itself, which I would not have found any other way.

That is the whole change, and written down it sounds small. What it did was move the gap between "I have the fix" and "every client has the fix" from about a week of evenings down to roughly four minutes.

What That Changes for Your Site

Three things, and the third is the one nobody thinks about until it bites.

You are never the site at the bottom of the list. There is no list any more. Every site gets the update inside the same few minutes, so there is no version of this where your site waits until Thursday because of where it happens to sit in my filing.

A problem found on someone else's site gets fixed on yours the same day. This is the part I did not predict when I built it. When something turns up on one client's site, the repair does not stay with that client. It goes out to everybody, usually before anyone else has any idea there was something to worry about. Malware is the obvious example, and it rarely announces itself politely: the last strain I dealt with disguised itself as an ordinary "verify you are human" screen. You end up benefiting from problems you never actually had.

Every site I look after is running the same, current version. That sounds like housekeeping, and it is not. It is the thing that prevents the worst conversation in this business, which is a client asking why their site suddenly broke and their developer not being able to say for certain what was running on it. I can answer that question about any site I manage, immediately, because the answer is the same for all of them.

What I Kept Slow on Purpose

Sending something to forty sites in four minutes raises the stakes rather than lowering them. When the job was slow and manual, a mistake would reach one site before I caught it. Now it would reach all of them before I had finished my coffee.

So the parts that catch mistakes stayed slow, and stayed manual. I test changes on a staging copy of the site before anything is marked ready, and I check the finished package against what I actually wrote before it goes anywhere near a live site. Those steps take a few minutes each and I have made no attempt to speed them up.

Working with Claude is a large part of why this took one evening to build rather than a month, and it is also why the checking matters more now than it used to. Things get made quickly these days. That is only an advantage if somebody is still reading them properly, and that somebody is me.

One practical thing worth knowing. When an update goes out to forty sites, they do not all finish at the same instant. The first time I watched it run, three sites looked like they had failed. Two had simply not finished yet, and the third was sitting behind a firewall doing exactly what a firewall is supposed to do. So now I look twice, a minute apart, before I believe anything is actually wrong. None of which replaces watching the sites properly, which is a separate job and still matters.

Where That Leaves You

If you have one website, none of this changes your day. It changes mine, and more usefully it changes what I am able to promise you.

What it lets me say is this: whatever I build or fix for one client, every client I look after gets the benefit of it quickly, and without a separate invoice for the privilege. That is not a marketing line. It is a description of how the plumbing works now.

If you manage multiple WordPress sites of your own, whether that is several locations or a business plus a side project, the same thinking applies to you directly and it is worth a conversation. That is a good part of what I do.

And if you are the technical sort and you want to know how the mechanism actually works, ask me and I will walk you through it. I left the detail out of this post because most of the people reading it have better things to do with their afternoon.