WordPress maintenance: what to do, how often, and what you can automate

Why a WordPress site needs maintenance

Most of the risk is in plugins. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than in 2024: 91% were in plugins, 9% in themes, and only 6 in WordPress itself. 46% had no patch yet when they were disclosed, and for the vulnerabilities attackers target most, Patchstack puts the median time to the first exploit at 5 hours.

WordPress itself moves fast too. Version 7.1.4 came out on 28 October 2026, WordPress plans three major releases in 2026, and the project officially supports only the latest version. Older branches get security fixes only as a courtesy.

None of this needs daily attention from a person. It does need a routine, a few things switched on, and a way to notice when an update breaks something.

Updates: WordPress, plugins and themes

WordPress already updates part of itself. Since version 3.7 it installs minor and security releases and translation files in the background, and since 5.6 new installations get major releases automatically as well; older installations stay on minor updates unless an administrator turns major updates on. Plugins and themes are different: they update automatically only if you switch it on, one by one, which WordPress has offered since 5.5. Auto-updates run twice a day and email the administrator what happened.

Since 6.6, WordPress also undoes a plugin auto-update that breaks the site badly: it loads the home page after the update, and if that shows a PHP fatal error, it restores the previous version and emails you. That only covers fatal errors. An update that empties the cart, breaks a form or shifts the layout loads without an error and stays installed.

So update promptly, security releases first, and back up before you do. Update one plugin at a time so you know which one caused a problem, and check the pages that make you money afterwards: the checkout, the contact form, the sign-in. Our guide on whether to turn off WordPress auto-updates covers the trade-off in detail.

Plugins and themes: fewer, maintained, removed when unused

Every plugin is code that has to be kept up to date, so the cheapest maintenance is fewer of them. Delete plugins and themes you don't use instead of only deactivating them; Site Health recommends removing inactive themes too. Keep one default theme as a fallback.

Watch for plugins that are no longer maintained. When WordPress.org confirms a security issue in a plugin, it usually closes it immediately, and a closed plugin pushes no updates until its developer fixes it. The notice is shown on the plugin's page on wordpress.org, and the reason is added after 60 days. A plugin page that says the plugin hasn't been tested with the latest three major releases of WordPress is another sign: it may no longer be maintained.

Replace abandoned plugins before they become a problem, and buy premium plugins from their developer, never from a site that redistributes them.

PHP and the server

WordPress recommends PHP 8.3 or greater, MariaDB 10.11 or MySQL 8.0 or greater, and HTTPS. It still runs on PHP 7.4, which has been its minimum since WordPress 7.0; sites on PHP 7.2 or 7.3 stay on the 6.9 branch. Running an old PHP version is one of the issues Site Health reports.

PHP versions have dates, so this is easy to plan. PHP 8.1 reached end of life on 31 December 2025. PHP 8.2 gets security fixes only until 31 December 2026, so a site on 8.2 should move now. PHP 8.3 is in security-only support until the end of 2027, and PHP 8.4 is fully supported until the end of 2026 and gets security fixes until the end of 2028.

Change PHP on a staging copy first if you can, or at a quiet time with a fresh backup, because an old plugin is the usual thing that breaks. Your host's control panel usually lets you switch back.

Backups you can restore

WordPress's own handbook is clear about what a backup is: the database and the files, because you need both to restore a site. The files are WordPress itself, themes, plugins, uploads, wp-config.php and .htaccess. Back up the database first, then the files; to restore, put back the files first, then import the database.

On frequency, it suggests weekly for smaller sites and daily for busy ones, and always before an upgrade. Keep copies in different places, such as your host, cloud storage and your own computer, and keep several: at least three to five recent database backups and three of the files.

A backup only counts if it restores. The handbook asks you to verify that backups are there and usable; the simplest proof is to restore one to a staging site now and then, and to make a manual backup occasionally to confirm the automatic ones still work.

Site Health and the warnings WordPress already gives you

Tools > Site Health is WordPress's own maintenance report. Its critical issues include background updates that aren't working, a site that can't reach WordPress.org, an outdated PHP version, plugins waiting for updates, errors shown to visitors or logged to a file that may be public, and a loopback request that fails, which WordPress needs to run scheduled tasks.

Its Info tab lists the WordPress and PHP versions, directory and database sizes, active and inactive plugins and themes, and whether each plugin auto-updates. Read it once a month; a new critical issue usually means something changed on the server or in a plugin.

Security housekeeping

Review who can sign in. Remove administrator accounts nobody uses, give people the lowest role that does their job, and look for accounts you don't recognise; our guide to WordPress user roles explains what each role can do.

Keep debug output off on the live site: Site Health warns when errors are displayed to visitors or written to a log file that may be readable from the web. And renew what expires: the domain registration and, if your host doesn't do it automatically, the SSL certificate.

If something does go wrong, our WordPress hacked checklist covers what to do first.

How Relvato helps

Relvato watches a WordPress site between maintenance sessions and right after updates. The Vulnerability monitor checks WordPress, plugins and themes against known vulnerabilities and flags plugins closed or abandoned on wordpress.org. The WordPress health monitor runs Site Health's own tests on a schedule and watches PHP end of life, database size and free disk space. The Backups monitor reads your backup plugin and reports when the last backup failed or stalled, when none is scheduled, or when backups are only stored on the server.

After an update, the monitors that were passing run again, so an update that breaks the checkout, a form, a page's layout or causes a PHP error is reported the same day, not when a customer complains. The Admin roster monitor flags a new or hidden administrator. On the Business and Agency plans, safe auto-updates update plugins one at a time in a weekly window, re-run the monitors after each one, and roll back and hold an update that breaks something, not only one that causes a fatal error.

Relvato doesn't make or restore your backups, and monitoring doesn't replace them: keep a backup plugin and off-site copies. For agencies, Relvato's client reports and status pages turn the same monitoring into a monthly maintenance report.