---
title: "A WordPress maintenance checklist that prevents problems"
date: "2026-05-12"
updated: "2026-09-07"
excerpt: "What to actually check weekly, monthly and quarterly on a WordPress site, and why a backup you have never restored does not count as a backup."
tags: ["WordPress", "Maintenance", "Hosting"]
draft: false
category: "guide"
tldr: "Most WordPress emergencies are deferred maintenance. Take security updates weekly and confirm backups ran, restore a backup monthly to prove it actually works, and review PHP version and plugin health quarterly. A backup you've never restored is a hypothesis, not a backup."
faqs:
  - question: "How often should I actually check on a WordPress site?"
    answer: "Weekly: apply security updates and confirm the backup ran. Monthly: restore a backup somewhere and review users. Quarterly: check your PHP version, measure performance against a number, and audit the plugin list."
  - question: "Why doesn't having a backup plugin installed count as being backed up?"
    answer: "Because a backup you have never restored is a hypothesis, not a backup. Broken backups are common and fail silently. Restoring into a staging site monthly is the only way to know it actually works."
  - question: "What's the minimum viable WordPress maintenance routine?"
    answer: "Apply security updates promptly, keep offsite backups and restore one occasionally, remove plugins and users you don't need, and check the site logged out on a phone once a month."
---

Most WordPress emergencies are maintenance that got deferred. The site was
fine, so nothing was done, until a plugin three versions behind stopped
working with a PHP upgrade the host applied on a Tuesday.

Maintenance is dull by design. Here is what is worth doing, and how often.

## Weekly

**Take updates, but read them first.** Security releases go on
immediately. Feature releases can wait a few days, long enough for other
people to find the breakage. Update on staging where one exists, and never
update everything at once on a site that takes money.

**Confirm the backup ran.** Not that the plugin is installed. That last
night's backup exists, is a plausible size, and is stored somewhere other
than the server it came from. A backup sitting on the same disk as the
site protects you from mistakes but not from losing the server.

**Skim the error log.** You are looking for change, not perfection. A new
warning repeating thousands of times is a plugin conflict announcing
itself early, which is when it is cheap to fix.

## Monthly

**Restore a backup somewhere.** This is the step nearly everyone skips,
and it is the one that matters. A backup you have never restored is a
hypothesis. Restore into a staging site and click around for two minutes.
Broken backups are common and they fail silently.

**Review users.** Remove accounts for people who have left. Check nobody
has quietly gained an administrator role. Contractors given admin access
for one job rarely get downgraded afterwards.

**Delete what is not in use.** Deactivated plugins and unused themes are
still on disk and still reachable by a request. If you are not using it,
remove it. Deactivation is not removal.

**Check the site as a visitor.** Logged out, on a phone, on mobile data.
Plenty of problems only appear outside the admin: a broken form, a
certificate warning, a layout that collapsed after an update.

## Quarterly

**Check your PHP version.** Hosts upgrade, sometimes with little notice,
and an old plugin can break on the day they do. Knowing which version you
are on (and which the site supports) turns a surprise into a
scheduled task.

**Review performance against a number.** Not a feeling. Record a
measurement, compare it against last quarter, and look into it if it has
drifted. Sites get slower gradually, through accumulated plugins and
uncompressed images, so nobody notices until it is bad.

**Audit the plugin list properly.** For each one: is it still maintained,
still needed, and still doing something? A plugin whose last update was
three years ago is a liability regardless of whether it currently works.

**Test your rollback.** Know how you would revert a bad update at 9pm on a
Friday. If the answer is "restore a backup and lose a day's orders", that
is worth improving before you need it.

## What doesn't count as maintenance?

A few habits look like diligence and are not:

- **Installing a security plugin and considering security done.** It helps.
  It does not replace updates, strong credentials and least-privilege access.
- **Clearing the cache when something looks wrong.** That hides the
  symptom without telling you what caused it.
- **Keeping every backup forever.** Storage costs money and old backups of
  a compromised site are not useful. Keep a sensible window and know what
  is in it.

## A minimum viable version

If the full list is more than the site warrants, do these four:

1. Apply security updates promptly.
2. Keep offsite backups, and restore one occasionally.
3. Remove plugins and users you do not need.
4. Look at the site logged out, on a phone, once a month.

That covers most of what actually goes wrong.

When it does go wrong anyway, the two failures I see most are
[a database connection error](/blog/error-establishing-a-database-connection)
and [a compromised install](/blog/reading-a-hacked-wordpress-install).

If you don't have the internal bandwidth or staging infrastructure to run verified updates and restorations, my ongoing [WordPress maintenance services](/wordpress-maintenance) take this off your plate. And if an update already broke your live site, you can request an [emergency WordPress site rescue](/wordpress-site-recovery) or [dedicated technical support](/wordpress-support).