What to put in a WordPress maintenance report that clients actually read
Short answer
Put the answer first: one sentence on the site’s state, then what you did, what’s coming (a plugin that needs replacing, a PHP version ending), and what the client needs to decide. Keep the technical details in an appendix for developers. A report clients read is short, in plain words, and the same shape every month, so changes stand out. Its job is to make invisible work visible.
Answer first
Clients open the report to learn one thing: is my site all right? Put that answer at the top, in one sentence:
- Everything is up to date and backed up; nothing needs your attention.
- One plugin needs replacing before your host’s PHP upgrade in March; details below.
Everything else supports that sentence.
The four parts
- What we did. Updates applied (counts, not a list), backups tested, checks run. One line each.
- What we found. Anything unusual: a failed update you rolled back, a warning in the log, a plugin that hasn’t had an update in a long time.
- What’s coming. Dated work ahead: a licence to renew, a plugin to replace, the end of the PHP version the site runs.
- What you need to decide. At most one or two questions, with your recommendation: Replace the old slider (2 hours) or remove it?
Long lists (every plugin and version, log lines, file paths) go in an appendix or an attachment, for whoever maintains the code.
Always include the PHP line
One line, every month: the PHP version the site runs, the date its security fixes end, and whether the plugins and theme are ready for the next version.
The dates are public and fixed, on php.net: for example, PHP 8.2 gets security fixes until 31 December 2026. Showing the date months ahead lets the client budget the upgrade, and turns a forced move by the host into a planned item in your report. What that upgrade involves is in the best PHP version for WordPress.
Make it look the same every month
Same order, same headings, same place for the status sentence. When the shape doesn’t change, the client sees at once what did. Your logo and colours on it help too: the report is often the only thing from you the client sees all month.
A free way to produce the PHP part: CompatNav’s HTML report opens in any browser and prints to PDF, with a plain-language summary and details for developers. What goes into the routine behind the report is in the maintenance checklist.
Why it matters for your business
Maintenance is invisible when it works. A client who sees nothing for months starts to wonder what they pay for, and cancels the plan at the next budget review. A short, regular report is the cheapest way to show the value of your maintenance plan.
Key takeaways
- Start with one sentence: is the site fine, or does something need attention?
- Then four short parts: what you did, what you found, what’s coming, what the client decides.
- Name upcoming dated work, such as a PHP version that ends, months before it’s urgent.
- Plain words for the client, an appendix for developers; the same shape every month.
- A report that shows the work is what keeps a maintenance plan from being cancelled.
Frequently asked questions
How long should a maintenance report be?
One page for the client. Lists of updated plugins, versions and log lines go in an appendix or an attachment.
Should I send a report when nothing happened?
Yes: nothing broke, everything was updated, backups were tested is the result the client pays for. Keep it short.
What do I show for PHP?
The PHP version the site runs, its security end date, and whether the plugins and theme are ready for the next version. That turns a future emergency into a planned item.
Check your own site before you upgrade
CompatNav is a free WordPress plugin. It reads the code of your plugins and themes on your own server and tells you, in plain words, what will break and what will only show notices on the PHP version you choose. It never changes your code. It can’t see problems that only appear while code runs with real data, so a quick check of your site after the upgrade still matters.
Sources
About the code examples: each output is the real output of the code shown, run with the official PHP builds, without a php.ini, with all errors reported and displayed. Only the file path was replaced by a neutral server path.