The monthly WordPress maintenance checklist

A WordPress site stays healthy on about an hour of maintenance a month. The monthly list: run the updates after skimming what changed, push major updates through staging first, confirm the newest backup can be restored, empty the spam queue, glance at the error log, delete the plugins nobody has touched in months, and sanity check uptime and page speed. Once a quarter, go deeper: a full restore test on a clone, an admin account audit, and a look at how fast the database is growing. This is the checklist we run across client sites, and it works because every item on it is small enough to get done.

Updates, with the changelog read first

We update in a fixed order: a fresh backup, then WordPress core, then plugins, then the theme. Minor releases, security patches and bugfixes, go on without ceremony, and WordPress applies minor core updates by itself, which we leave enabled. Major updates get five minutes of reading first. The plugin changelog tells you whether the new version is a coat of paint or a rewrite, and rewrites are where sites break. A page builder announcing a new editor, an ecommerce plugin changing its template tags, a form plugin altering its database schema: those entries change the answer from update now to stage it first.

Major updates go through staging

Any update that rewrites a major component deserves a staging pass, and staging has to be cheap or the pass never happens. Clone the site, update the clone, click through the five pages that earn the site its money, then push the clone live. On Cloudways, staging is included on every plan, which is why this item sits inside the monthly hour instead of on the quarterly wish list.

The backup that restores

A schedule running green in the panel proves that a schedule exists. Once a month, pull the newest backup into a clone and open it. The check takes minutes where cloning is a button, and it is the difference between a backup and a hope. The full method, what to click and what a failure looks like, is in our guide to testing a backup restore before you need it.

Spam, comments, and database weight

Empty the spam queue and the trash. Thousands of accumulated spam comments do more damage than they get credit for: wp_comments grows, comment queries slow, and the export file you will need during the next migration bloats with garbage. Post revisions pile up the same way on busy blogs. Neither will kill the site this month, and both make every future move heavier than it needs to be.

The error log, once a month

Two logs earn a glance. The PHP error log collects deprecation warnings, which are the forecast: a plugin throwing notices today is a plugin that breaks at the next PHP version bump, and knowing a month ahead turns an emergency into a line item. The access log's 404 column tells you about broken internal links and about whatever the bots are currently probing for. While you are there, run a broken-link check over the half dozen pages that matter, because visitors find broken links before owners do.

The plugin audit

One question per plugin: when did this last earn its place? Plugins deactivated six months ago get deleted, since inactive plugins still trigger update prompts and still show up in security scans. Plugins with no update in over a year get a replacement plan, because abandonment is the most common way a useful plugin becomes a liability. The audit takes ten minutes with the plugins page open, and it is the item clients never think to ask for and always benefit from.

Uptime and speed

Uptime monitoring should already be running between visits, so the monthly item is checking the monitor: did the last real incident produce an alert, and did someone see it? A monitor that stopped paging is worse than no monitor, because it supplies confidence. For speed, load the front page and one heavy interior page as a visitor would. If either feels slow, the first suspects are new images at full camera resolution and a plugin added since last month; the server is usually the last thing that needs changing. When the server genuinely is the constraint, the server size calculator works out what to move up to.

The quarterly deeper pass

Once a quarter, add an afternoon. Run the full restore test rather than the quick clone check. Audit every account that can log in, ex-clients, ex-staff, the contractor from the redesign, and remove or downgrade the ones nobody will admit to using. Rotate the passwords nobody remembers anyway. Check the TLS certificate expiry even on platforms that renew automatically, because the failure mode is a certificate that expires on a weekend. Export the database and note the file size; a database that doubles in a quarter is trying to tell you something, usually unbounded logging in a plugin.

Keeping the hour honest

The checklist fits in an hour because each item is small. It stops fitting the month a client calls with an emergency that eats the afternoon, so the calendar slot, the same week every month, matters more than any single item. Sites that get this hour are boring to own, and boring is the goal.