← All posts
16 July 2026

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:

  1. Core, theme and plugin updates, tested on staging, with a rollback path
  2. Automated offsite backups, files and database, with tested restores
  3. Uptime plus error, form and SSL monitoring
  4. Security patching, two-factor access, brute-force protection
  5. Performance checks against Core Web Vitals
  6. A budget of small content changes with a written response time
  7. A monthly report of what was actually done
  8. 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.

Tell us what’s broken.
We’ll tell you the truth.

Book a free call →
Reply within one business day ¡ EN / LV