All blogs

A WordPress maintenance checklist that prevents problems

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.

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.

Things that are not 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 and a compromised install.