WordPress maintenance: what a monthly plan should actually include
Most maintenance plans are a backup script and an invoice. Here is the full checklist a monthly WordPress plan should cover, what each item protects you from, and what the cheap plans quietly skip.
Your WordPress site worked on launch day. Then the agency handed over the keys, the invoices stopped, and nobody has updated anything since.
That is how most WordPress problems start. Not with a clever attack - with a plugin that fell 14 versions behind while nobody was watching. We have handled 5,000+ support tasks for clients and agencies in the last 18 months, and the expensive incidents almost always trace back to the same thing: months of skipped maintenance, invoiced as âpeace of mindâ by a plan that only ran a backup script.
So here is the actual checklist. What a monthly WordPress maintenance plan should include, what each item protects you from, and the items cheap plans quietly leave out.
Updates - tested, not just clicked
Every maintenance plan says âupdatesâ. The question is how they happen.
Clicking âupdate allâ on a live site is not maintenance, it is gambling with a business asset. A plugin update can conflict with your theme, your page builder or another plugin, and the first person to find out is a customer looking at a white screen.
The version of this that works: updates run on a staging copy of the site first, get checked, and only then touch production. That is how we run it, and it is why an update has never taken a clientâs business offline on our watch. If a plan does not mention staging, ask where updates are tested. âWe monitor after updatingâ means your live site is the test environment.
This includes PHP. Hosts bump PHP versions on their own schedule (WordPress itself currently recommends PHP 8.3 or greater), and a site that was never tested against the new version finds out in production. A database update loop or a frozen, expired page builder licence is the kind of thing that surfaces exactly then.
Two more words to look for in the updates section of any plan: rollback and testing. When an update goes wrong despite staging, there has to be a known path back to the last working state, not an all-nighter. And after every update round, someone should check the things that earn money - forms submit, checkout completes, booking works. An update that âsucceededâ while silently breaking the contact form is worse than no update at all.
Backups that someone has actually restored
Everyone has backups. Almost nobody has tested a restore.
A backup you have never restored is a hope, not a backup. The checklist here is short and unforgiving: backups run automatically, they are stored offsite (not on the same server that could die), they cover both files and the database, and someone has performed a real restore from them recently enough to know it works and how long it takes.
Ask a provider âwhen did you last restore a site from backup, and how long did it take?â A good answer is specific. A bad answer is âour host handles thatâ.
Monitoring - uptime is the minimum
Uptime monitoring tells you the site is down. Useful, but it is the smallest part.
A plan should also watch for the quieter failures: error logs filling up, forms that stopped delivering, checkout or booking flows breaking, SSL certificates about to lapse, disk quotas filling. These do not take the site down - they just quietly cost money until a human notices. In our experience the silent form failure is the worst of them, because the site looks fine while leads go nowhere.
Security - patching, hardening, and honesty
Most sites do not get hacked by geniuses. They get hacked by neglect: a disclosed vulnerability in an outdated plugin, exploited by a bot that scans half the internet for it.
The numbers say exactly that. Patchstack logged 11,334 new WordPress vulnerabilities in 2025 - up 42% on the year before, 91% of them in plugins, and only 6 in WordPress core itself (all low risk). The core is fine; the plugins nobody updates are the attack surface. Sucuriâs remediation data matches from the other side: 39.1% of infected CMS sites were running outdated software at the time they were compromised.
The security section of a real plan is mostly discipline: security releases applied promptly (this is where staging-tested updates pay off - you can apply them fast because you can apply them safely), admin access limited and behind two-factor authentication, credentials in a password manager rather than an email thread, and login endpoints protected from brute force.
What it is not: a security plugin installed and forgotten. A firewall plugin on a site running plugins from 2021 is a lock on a door with no wall.
Performance upkeep
Sites slow down over time - plugins accumulate, databases bloat, image libraries grow, caches misbehave after updates. A maintenance plan should hold the line: periodic checks against Core Web Vitals, database cleanup, and a look at what changed whenever the numbers drift.
This does not need to be a monthly performance project. It needs to be someone noticing the site got slower before your customers and Google do.
Small changes, with a real response time
The item that separates a maintenance plan from a monitoring subscription: a human who makes the small changes that pile up - a price update, a new team member, a section swapped on the homepage - with a defined response time, not âwhen we get to itâ.
Our plans include a budget of small content changes, and urgent edits are typically turned around in 1-2 hours during working hours. Whatever provider you pick, get the response time in writing. âFastâ is not a number.
Know the boundary too, so quotes stay comparable: maintenance is not custom development, a redesign, new features or an SEO campaign. Those are projects with their own scope and price. A provider who blurs that line in the sales call will blur it on the invoice.
A report - the receipt for the invoice
Every month you pay for work you mostly cannot see. The proof it happened is a report: which updates were applied, backups taken and verified, incidents caught, what changed in performance, hours used from the change budget.
It does not need to be long - one page is fine. But if a provider sends no report at all, you are not buying maintenance, you are buying a promise. We put numbers on everything for a reason; ask your provider to do the same.
What the cheap plans skip
Reading a cheap planâs feature list, notice what is missing rather than what is there. The usual gaps:
- Staging. Updates go straight to production, untested.
- Restore testing. Backups exist; nobody has ever restored one.
- A named person. You get a ticket queue, and every request is handled by someone who has never seen your site before.
- PHP and hosting-level issues. âWe maintain WordPressâ quietly excludes the server it runs on.
- An exit. No documentation, no handover, access held hostage. Leaving is made expensive on purpose.
None of these show up as problems in month one. All of them show up eventually.
When you donât need a maintenance plan
Honesty over upsell: not every site needs one.
A hobby site with no business function can run on auto-updates and an occasional manual check - worst case, you lose a hobby site. A site already scheduled for replacement needs a freeze and a rebuild plan, not a retainer; sometimes the right call is leaving WordPress altogether. And if you have in-house developers who actually own the site, a plan duplicates what you are paying them for.
For everything in between - any site that generates leads, sales or credibility - the math is simple: a year of maintenance costs less than one serious incident. We have cleaned up enough of those incidents to publish that as fact, not fear.
The checklist, in one list
What a monthly WordPress maintenance plan should include:
- Core, theme and plugin updates, tested on staging, with a rollback path
- Automated offsite backups, files and database, with tested restores
- Uptime plus error, form and SSL monitoring
- Security patching, two-factor access, brute-force protection
- Performance checks against Core Web Vitals
- A budget of small content changes with a written response time
- A monthly report of what was actually done
- Documentation and a clean exit - your site, your access, your code
If your current plan covers all 8, keep it. If it covers 2, you now know what the invoice is actually buying.
Want the 8 items handled without chasing anyone? That is what our care plans are - month to month, no lock-in, and we take over sites we didnât build after a short audit.