The Hub

Everything was answerable, one site at a time

Nothing about the estate was unknowable. Every fact they needed existed somewhere: on the server, in the WordPress install, at the registrar, in a performance tool. The problem was that answering a question across the whole fleet meant asking it individually, dozens of times.

That made routine maintenance expensive enough to defer. Which sites are still on an old PHP version is a five-minute question for one site and a whole afternoon for the fleet, so it got asked rarely, which is exactly the wrong cadence for something security-relevant.

It also meant problems were found reactively. A site with a plugin missing, a firewall that had been switched off, or Core Web Vitals that had quietly degraded were all discoverable, but only if somebody happened to look at that specific site.

Pulling the truth off the servers

The Hub reads directly from where the sites actually live rather than from a record of how they were set up. That distinction matters, because a configuration record tells you what someone intended and a server tells you what is true.

For every site it surfaces the PHP version it is genuinely running, whether the firewall is active, and which plugins are installed and at what version. Those three answers alone covered most of what the team had previously been checking by hand.

Because it reads live, a change made outside the platform still shows up. Somebody disabling protection during troubleshooting and forgetting to re-enable it is visible on the next read rather than at the next audit.

Performance data next to the site it belongs to

PageSpeed and Core Web Vitals data is pulled in per site and shown against everything else about that site. That sounds obvious and is the part most tooling gets wrong: performance scores usually live in a separate tool, disconnected from the PHP version, the plugin list, and the host.

Sitting together, the numbers become diagnostic rather than decorative. A poor score next to a bloated plugin list and an old PHP version is a specific piece of work, not a metric to feel bad about.

It also made the fleet sortable by how bad things were, so attention went where it was worth spending instead of wherever a client complained loudest.

DNS without the registrar tab

DNS was the piece the team most wanted and the piece most likely to go wrong. Records are read into the Hub and can be updated from it directly, so a change does not require finding the right login for the right registrar for the right client.

That removes the two failure modes that make DNS work stressful. Editing the wrong account, which is easy when you have a dozen registrar tabs open, and having no record afterward of who changed what.

Everything else about the site is on the same screen, so a record is edited with the context of what it points at rather than in an isolated control panel.

What it replaced

It replaced a habit rather than a tool. There was no incumbent system to migrate off, just an accumulated set of logins, spreadsheets, and the knowledge of which team member remembered which detail.

The measure of whether it worked was simple: could someone answer a question about the whole estate without opening anything else. That is what it was built to make possible.