When the same WordPress maintenance checks fail on most of the sites you look after, your baseline is broken, and fixing sites one at a time won’t change that. I picked the idea up this month from outside the WordPress bubble, in Alle Sravani’s piece on Towards Data Science about moving data governance from product triage to infrastructure investment, and it maps onto client work almost one to one.
Her argument goes roughly like this. A governance team reviews 60 data products sprint after sprint, ticking boxes, and the queue quietly becomes the whole job. Gartner, cited in the piece, projects that up to 80 percent of these initiatives fail, mostly because they stay reactive. Swap client sites in for data products and you have most monthly maintenance reports I’ve seen, a list of things that got fixed and no view of what keeps breaking them.
Why does the same problem come back on every site?
The article’s example is access control. Five data products across three business domains all show missing RBAC, so five stewards get five separate tickets. Put them side by side and it’s one infrastructure failure showing up five times. I see the exact shape of this on WooCommerce stores: a former contractor who still has an administrator login on five shops, or five shops with customer registration open because nobody ever changed the default. Five tickets deal with the symptom and leave the process that causes it alone, so the sixth shop arrives with the same problem preinstalled.
How do you turn WordPress maintenance checks into a grid?
Sravani’s tool is a domain maturity heatmap. Rows are business domains, columns are governance pillars, and each cell only says whether the control passes. It’s binary, with no averages, because averages hide the clustering you’re trying to spot. You can build the same grid for a portfolio with aliases in your WP-CLI config, and it takes about an afternoon.
# ~/.wp-cli/config.yml
@all:
- @acme
- @northwind
- @toolworks
@acme:
ssh: deploy@acme.test
path: /srv/www/acme/wordpress
wp @all eval 'echo json_encode([
"php_ok" => PHP_VERSION_ID >= 80200,
"debug_small" => @filesize( WP_CONTENT_DIR . "/debug.log" ) < 1048576,
"few_admins" => count( get_users([ "role" => "administrator" ]) ) <= 3,
"cron_ok" => ! empty( _get_cron_array() ),
]);'The output arrives prefixed per site, so paste it into a grid with sites as rows and checks as columns, and color each cell by pass or fail. The red column is what you chase first. A red row is a different conversation, and I’ll get to it. (Aliases run wp over SSH on each host; where a host can’t support that I mark the cell unknown rather than fail it, since a false red sends you hunting a bug that isn’t there.) If you want to turn this one-off eval into a real command, the structure I use for writing WP-CLI commands applies.
Setting up the aliases, agreeing on the checks, and turning the monthly report into one grid instead of a ticket list is also work I take on for agencies and store owners. Tell me how many sites you look after and what’s on your current checklist, and I can say what the grid version would take.
What does a red column tell you?
A red column tells you where a system fails, not why, and the article is upfront about that. Two domains can both sit at 15 percent on lineage: one has a disconnected ingestion tool, a one-day fix, while the other never mapped its data flows at all, which is weeks of work. In WordPress terms, say two stores both fail the debug log check. One has a 2GB debug.log because a plugin spams notices in a loop. The other has had WP_DEBUG on in production since launch. The cell looks the same for both, but only the second one says anything about how you ship.
A column that’s red across every site usually points at provisioning. If DISALLOW_FILE_EDIT isn’t in any wp-config.php because your deploy script never adds it, per-site tickets will always lose the race against new installs.
When is the single site still the right unit?
When one row is red across every column. In the source that’s a domain with no ownership and no standards, and the fix is a dedicated uplift program rather than certification. On a single store it looks like this: nobody remembers who owns it, staging never existed, updates haven’t run since the build, and half the failing checks fail for reasons nobody wrote down. Here the order matters. Name an owner first, then apply the baseline for PHP version, roles, backups and registration defaults, and only after that do the checks start to mean anything. I’m not sure how cleanly this maps to multisite, where one wp-config.php covers every site in the network.
What to ask before the next review
Before you open any single site’s backlog, ask which of the WordPress maintenance checks fail across more than one site. That’s the question Sravani wants governance councils to ask before they review any product, and it works word for word for maintenance. A check that fails across sites belongs to whatever layer can fix it everywhere at once, whether that’s your deploy script, your monitoring cron or your host template. Add DISALLOW_FILE_EDIT to the deploy script and every site you build from now on passes that check before you ever log in.
