The WordPress Maintenance Checklist We Run on Client Sites

Most WordPress maintenance checklists are lists of chores. This one is a schedule with a reason attached to every line, because the value of maintenance is not that tasks got ticked — it is that the three things that actually take sites down get caught before they do.

Those three things, in the order they cause damage: an unpatched plugin vulnerability, a backup that turns out not to restore, and a PHP or core version that quietly stops receiving security fixes. Everything else on this page — database cleanup, broken links, comment moderation — is hygiene. Useful, but nobody has ever lost a week of revenue to an unoptimised wp_options table.

So the checklist below is ordered by consequence. If you only ever do the weekly block and the quarterly restore test, you are ahead of most sites on the internet.

What a WordPress maintenance schedule should actually cover

Here is the full cadence we run. Times are per site, assuming a site already in a known-good state — the first month on a neglected site always costs more.

Why weekly updates, not monthly

The update cadence question has an evidence-based answer now. Patchstack’s State of WordPress Security 2026 report recorded 11,334 new vulnerabilities disclosed during 2025 — a 42% increase on the previous year — with 91% of them in plugins, 9% in themes, and six in WordPress core, all low risk. Roughly 17% were rated high severity.

The number that decides your cadence is not the volume, though. It is the speed: around half of high-impact vulnerabilities were exploited within 24 hours of disclosure, and for the most heavily targeted the median time to exploitation was about five hours.

You cannot win that race. A weekly cycle does not beat a five-hour exploit window — nothing short of automated patching does. What it buys you is that your average exposure to any given disclosed vulnerability is three and a half days instead of fifteen. That is the honest framing, and it is why the other half of the answer is a web application firewall with virtual patching, not a faster human.

The same report found hosting-level defences blocked only 12% of actively exploited WordPress vulnerabilities, rising to 26% across a wider set. If your security plan is “our host handles it”, that is the number it is built on.

One more figure worth knowing before buying the premium version of anything: 1,983 of those vulnerabilities were in premium or freemium products, 59% of them high-risk, and 46% had no patch available at public disclosure. Paid does not mean safer.

What to automate and what to hold

WordPress’s own defaults are a reasonable starting point but not a policy. On installations from 5.6 onward, core minor and major updates run automatically; on sites that predate it, only minors do. Plugins and themes never auto-update by default, except for critical security patches pushed by the security team.

For a business site, the configuration we deploy is minors automatic, majors manual:

// wp-config.php
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

WP_AUTO_UPDATE_CORE accepts true (development, minor and major all automatic), false (all disabled), or 'minor'. Leaving it undefined means the site falls back to whatever its installation-era default was, which on an inherited site is usually a mystery — set it explicitly.

Then enable per-plugin auto-updates selectively: on for security plugins and anything from a vendor with a strong release record, off for the page builder, the form plugin, the payment gateway, and anything with custom code hooked into it. Those are the ones that break things, and a broken checkout that self-inflicts at 3am is worse than a two-day patch delay.

The abandoned plugin problem WordPress does not warn you about

This is the gap in almost every maintenance checklist published, and it is a real one.

When a plugin is closed or removed from the WordPress.org repository — for a guideline violation, an unresolved security issue, or because the developer walked away — your site keeps running it and your plugins screen keeps showing it as up to date. Patchstack’s write-up on repository closures puts it plainly: WordPress “shows closed plugins just as an up-to-date plugin.” There is no core notification, no badge, no admin notice. The plugin simply stops receiving updates forever, and the only visible signal is an absence.

This is not an edge case involving obscure software. Plugins with millions of active installations have been closed, sometimes with the vendor moving updates to their own server — which requires every site owner to download and reinstall the plugin manually, because repository rules forbid a hosted plugin from updating itself from elsewhere.

The monthly audit is mechanical: take your active plugin list and check each slug against its repository page. A page returning a “closed” notice, or a “last updated” date more than roughly a year old, goes on a replacement list. Pull the list in one command:

wp plugin list --status=active --field=name --format=csv
# then check https://wordpress.org/plugins/<slug>/ for each

Replacing an abandoned plugin is rarely urgent on the day you find it, and always urgent three months later when a vulnerability is disclosed against it and no patch is ever coming. Finding it early is the entire point.

Backups: the task everyone has and almost nobody tests

Every maintenance checklist says “take backups”. Very few say “restore one”, which is the only part that carries any information.

A backup job reporting success tells you a file was written. It does not tell you the database dump completed before the connection dropped, that the archive is not truncated, that wp-content/uploads was included rather than excluded by a size cap, or that the restore works when the person who set it up is on holiday. Those failures are silent and discovered at the worst possible moment.

The quarterly test: pull the most recent off-site backup, restore it into a clean staging environment that shares nothing with production, then check four things rather than glancing at the homepage.

• Row counts on the transactional tables. Orders, users, form submissions — compare to production. A restore that silently loses the last two days of orders looks perfect on the homepage.
• Media files resolve. Load several post pages and confirm images return 200, not just that the uploads folder exists.
• A write path works. Place a test order or submit a form. Read-only browsing does not exercise the database user’s permissions.
• Time to restore, measured. Write the number down. “We have backups” is not a recovery plan; “we can be back in 40 minutes” is.

If a restore has never been tested on your site, that test is the most valuable hour anyone will spend on it this quarter. It is also the task most likely to turn up something genuinely broken — which is uncomfortable to discover, and far better than the alternative. Our walkthrough of the first 60 minutes after a WordPress site is hacked assumes a working restore at several points; without one, every branch of that process gets significantly longer and more expensive.

If you are not sure whether your backups restore — and most site owners genuinely are not — have us run a restore test against your current backups. It is a contained piece of work with a clear answer at the end: either they restore, or you have found out on a Tuesday instead of during an outage.

Version lifecycle: the slow-motion problem

PHP and WordPress versions do not break your site the day they go end of life. They stop receiving security patches, and the risk accumulates quietly until a vulnerability lands that will never be fixed on your stack.

Current state, as of this writing:

Each PHP branch gets two years of active support then two years of security-only fixes. The practical rule: on 8.1 you are running unpatched software today; on 8.2 you have a migration to schedule before year end rather than an emergency in January.

On the WordPress side, the current release is 7.1.2 (22 September 2026), and only the latest branch is actively maintained. WordPress 7.1 supports PHP 7.4 through 8.5 — a wide range, which is convenient and also why so many sites drift years behind on PHP without anything appearing to be wrong. Compatibility is not support.

The quarterly check is two questions: what PHP version is production actually running, and how many months of security support does it have left? A migration planned six months out is a staging test and a scheduled switch. The same migration in a panic is where the surprises live.

Database bloat: real, but not the emergency it is sold as

Database optimisation gets more attention in maintenance marketing than it deserves, because it is easy to sell a “cleanup” that produces a satisfying before-and-after number. It matters, but in one specific place: autoloaded options.

Every page load reads every row in wp_options flagged autoload = yes, before anything else happens. Plugins that were installed and removed leave rows behind, some of them large serialised blobs. WP Engine’s guidance is to keep total autoloaded data under 800 KB, and their platform treats a single autoloaded row over 1 MB as large enough to remove automatically.

Check where you stand:

SELECT ROUND(SUM(LENGTH(option_value))/1024, 1) AS autoload_kb
FROM wp_options WHERE autoload = 'yes';

SELECT option_name, ROUND(LENGTH(option_value)/1024, 1) AS kb
FROM wp_options WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC LIMIT 20;

The second query is the useful one — bloat is almost always a handful of large rows from a specific plugin, not a general fog. Expired transients and old post revisions are worth clearing too, but they affect table size more than they affect page generation time. Take a backup before any of it, and be wary of one-click cleanup plugins, which delete more indiscriminately than a targeted query does.

If the database is slow but autoload is small, the problem is almost certainly elsewhere — query patterns, a missing object cache, or an overloaded shared host. We cover how those symptoms present in why WordPress sites take eight seconds to load, and why the speed problem is usually not where people first look in what site speed actually costs you.

What maintenance does not do

Worth being straight about the limits, because maintenance is frequently sold as insurance and it is not.

A maintenance plan does not make a site un-hackable. With half of high-impact vulnerabilities exploited inside a day, a site on a popular plugin stack can be compromised between one Tuesday and the next by an attack that did not exist when you last updated. What maintenance does is shrink the window, make the compromise detectable early, and make recovery a restore rather than a rebuild.

It also does not fix architectural problems. A site with 40 plugins doing the work of 12 will stay slow no matter how diligently it is updated. Maintenance keeps a site in the state it is in — good or bad. Changing that state is different work, and any provider blurring the two is selling you the wrong thing.

Where to start if none of this is running

Highest return first: turn on uptime monitoring today, verify one backup actually restores this week, get the plugin stack current and set minor core updates to automatic, then audit for closed plugins and check your PHP version’s remaining support window. That sequence takes a few hours and removes most of the realistic ways a site goes dark for a day.

If you would rather not own the schedule — and for most teams it is the third thing that gets dropped when a quarter gets busy — talk to us about running it for you. The valuable part is not that someone clicks update; it is that the restore test happens every quarter whether or not anyone remembered to ask for it.