I studied computer science from 2006 to 2009 and started with WordPress when it was still around version 2.0. Since then I have built plugins, themes, and well over a hundred WordPress sites — including years of self-employed client work where the queue of “update this next” never matched the calendar.
Those years did not teach me that WordPress is uniquely insecure. They taught me that portfolio work fails on prioritization. Here are the patterns that kept repeating — and that shaped WP Triage.
More alerts do not create more safety
Scanners and host emails are good at proving risk exists. They are bad at sequencing a Monday morning. The agencies and freelancers I worked with did not need another feed; they needed a short ordered list they could finish.
Similar issues should batch
Four sites on the same vulnerable plugin are one work session, not four dramas. Portfolio triage only works if the view makes shared problems obvious. That is why recurring findings and score-sorted lists matter as much as per-site detail.
Quiet alerts beat noisy ones
If everything pages you, nothing does. Critical vulnerabilities and sudden score drops deserve interruption. The rest belongs in a weekly review. I built that into WP Triage because I ignored my own noisy tools for years.
Management tools and triage tools are different jobs
WP Foundry exists to help you operate WordPress installs from the desktop. WP Triage exists to decide what deserves attention first. Keep the firewall and the remote manager; add a decision layer when the portfolio outgrows a spreadsheet.
A practical next step
If you manage client WordPress sites today, try the weekly rhythm in how to triage WordPress client sites, then compare how our scoring methodology maps to the work you already do.
Questions about the approach? Get in touch — I read every email.