Open a typical WordPress maintenance report and you’ll find a list: eleven plugins updated, four backups completed, 99.98% uptime. It’s an itemized record of activity. What it doesn’t tell anyone is whether the site is healthier than it was thirty days ago, which measurements are quietly sliding in the wrong direction, or what’s likely to fail next.
WP Maintain builds every WordPress maintenance report around that second question. One report draws on availability probes, malware and vulnerability scans, Lighthouse runs, the database, PHP error output, certificate and domain expiry dates, broken-link and mixed-content crawls, backup records, and three separate sources of update history which compresses all of it into a single figure a non-technical reader can absorb at a glance.
What follows is what’s actually in one, and why the distinction becomes load-bearing once you’re the host accounting for thousands of sites at once.
What Goes Into a WordPress Maintenance Report Score
Each report carries a health score between 0 and 100. It isn’t uptime wearing a costume. It’s a composite:
| Signal | Weight | What moves it |
|---|---|---|
| Uptime | 20 | Measured availability over the period |
| Security | 18 | Scan findings that are displayed by severity i.e. critical, high, medium, low |
| Outstanding updates | 15 | Pending plugin, theme and core updates |
| Performance | 12 | Lighthouse performance, averaged across devices |
| Backups | 8 | Whether a client-facing backup actually ran |
| Database health | 5 | Size and genuine overhead |
| SEO | 4 | Lighthouse SEO |
| Broken links | 4 | Decays per broken link found |
| Accessibility | 3 | Lighthouse accessibility |
| Best practices | 3 | Lighthouse best practices |
| PHP issues | 3 | Errors, warnings and notices, weighted separately |
| Mixed content | 3 | Decays per insecure asset |
| SSL and domain expiry | – | Ramps down as the nearer of the two approaches expiry |
Two choices in how that math works matter more than any individual weight.
Unmeasured is not the same as perfect. If no security scan ran during the reporting window, that site’s security posture is simply unknown — so security leaves both the numerator and the denominator instead of quietly banking a 100. Performance, database health, PHP checks and link crawls behave the same way. A 94 means 94 out of what was actually observed, not 94 out of a set of assumptions.
A disabled section can’t drag the number down. The score renormalizes across exactly the sections a report includes. Switch SEO off for a client who has never once asked about it, and the SEO, accessibility or best practices stop influencing their score rather than silently costing them ten points on work they were never going to commission.
Updates: a changelog, with attribution
The Updates Applied section is a record of change, not a stock list. Every row names the item, the version it left, the version it landed on, the date, and who did it.
Getting that last column right meant reconciling three sources, each of which sees a different slice of the truth:
- Pipeline snapshots carry exact before-and-after versions for anything applied through scheduled or safe updates.
- Activity logs carry the actor for manual and scheduled updates performed inside the platform, resolved to an actual teammate’s name.
- The connector’s own update log picks up anything applied by hand in wp-admin, attributed to the WordPress account that did it.
Drop that third source and you’d publish a suspiciously quiet month for a client who had been patching plugins manually the whole time. The section also tracks the currently installed version separately from the version any given update moved to, so an item that’s been updated twice since isn’t misreported.
Fourteen sections, every one optional
A report series is assembled from the sections you enable per template:
– Updates Applied
– Plugins
– Themes
– Core and Environment
– Database
– PHP Issues
– Uptime
– Speed and Performance
– Security
– Backups
– SEO Scores
– Broken Links
– Mixed Content
– Completed Tasks
Updates, plugins, themes, core, database, PHP issues, uptime, speed, security and backups ship on. SEO, broken links and mixed content are opt-in. They’re the three most likely to generate a support ticket a host would rather not field across every account on the platform. Each section has its own editable heading and body copy, so identical data can be pitched to a small-business owner in one series and an agency in another.
There’s also a recommended-tasks section that turns the report’s own findings into tracked tasks, grouped by area and priority. It’s off by default, because a report that hands out work is a different product decision from a report that describes it.
Averages across the window, not whatever was measured last
Speed and SEO cards show the mean of every scan that falls inside the reporting period, split desktop and mobile, with a trend sparkline built from those scans in sequence. That’s the honest figure. A single most-recent reading lets one bad afternoon become the month’s headline.
If no scan happened to land inside the window, the card falls back to the most recent one available and says so, rather than rendering an empty box. Generating a report also triggers a fresh Lighthouse run in the background. It won’t complete in time for the report that started it; it will be there for the next one.
What a plugin list never surfaces
Several sections exist specifically to catch problems before the customer does:
Database – The actual size and overhead, plus cleanup counts for post revisions, auto-drafts, trashed posts, spam comments, trashed comments and expired transients. Overhead is scored on the platform side rather than taking the connector’s word for it, because InnoDB’s free-space figure isn’t fragmentation, and treating it as such made perfectly healthy sites report “Poor”.
PHP issues – Errors, warnings and notices counted apart from one another, and only scored when the site was genuinely checked.
Environment – WordPress core version, PHP version, debug mode on or off, WP-Cron running or disabled.
SSL and domain expiry – A ramp rather than a pass/fail. A certificate with 40 days left is fine. One with 6 days left is already pulling the score down, while there’s still room to fix it.
Security – Findings tallied by severity, so a single critical costs eight times what a single medium does.
Four routes to the customer’s attention
A report only counts as proof of care if someone reads it, and WP Maintain doesn’t assume anyone will log into a dashboard to do so:
| Delivery | How it works | Best for |
|---|---|---|
| Panel embed | Token-authenticated embed URL, dropped into an iframe in your hosting panel | Customers who never leave your control panel |
| API | Pull the report data, render it in your own template, send from your own infrastructure | Hosts with an existing email pipeline and brand system |
| White-label SMTP | WP Maintain sends the email itself, from your domain, with your logo and colors | Reaching delivery without engineering time |
| Export | PDF, CSV or JSON download | Attaching to a ticket, an account note, or a renewal conversation |
Branding is snapshotted into each report at generation time i.e. workspace logo and name, header, body, heading, background, card and email-header colors. Therefore, a PDF regenerated or forwarded eight months later still renders as the brand that sent it, not as WP Maintain.
Scheduled, and recovered when a send fails
Series run weekly, bi-weekly, monthly or quarterly. The scheduler is designed around a single observation: reports fail to send far more often than they fail to generate.
So each pass evaluates the current period for each site and picks one of three outcomes; generate the report if it doesn’t exist, retry the email if a report exists but was never delivered, or skip if it already went out. A report built during an SMTP outage gets another delivery attempt on the next pass instead of being marked complete. Bi-weekly and quarterly series carry a spacing guard so they can’t quietly regenerate on the weekly or monthly grid running beneath them.
A dry-run mode assembles the full report data for a scoped series and returns a per-site section summary without writing a row, rendering a PDF, or sending anything. Therefore, a template change can be proven out on a canary account with no side effects at all.
Why the calculation is different for a host
An agency sends a maintenance report to justify a retainer. For them, the report is the deliverable.
A host sits somewhere else entirely. Your customer didn’t buy maintenance; they bought hosting, and they assumed the site would work. They are not going to read a monthly PDF for enjoyment, but at renewal, in the moment they’re comparing your price against someone else’s, or halfway through a support conversation about why the site crawled last Tuesday e.g. a record showing the real signals changes what that conversation is about, threats found, and how serious they were. Updates applied, and by whom. A score moving in the right direction.
That’s the gap between a receipt and proof of care. A receipt asserts that work happened. Proof of care demonstrates that the site improved, points to the evidence, and survives being checked.
