WordPress maintenance: what it includes, plus a checklist
WordPress maintenance is the routine work that keeps a site secure, recoverable and working: updating WordPress core, themes and plugins, keeping tested backups, watching for security problems and downtime, and removing what you no longer use. Most of it is small, regular jobs. This guide lists each task and how often to do it.
It covers what a site owner or whoever looks after the site needs to do, based on WordPress.org’s own documentation, PHP’s support policy and the Canadian Centre for Cyber Security’s guidance for small organizations. If you would rather have it done for you, our website maintenance page explains how we handle it.
What WordPress maintenance includes
Five jobs make up almost all of it: updates, backups, security, monitoring and housekeeping. None is complicated. The risk is that each one is easy to put off, and nothing visibly breaks until the day it matters.
Updates
There are four things to keep current: WordPress core, plugins, themes and PHP.
Core. WordPress.org’s upgrade documentation says automatic updates are enabled on most sites by default. Existing installations receive minor core updates automatically. New installations from WordPress 5.6 onward get major updates too, while older installations keep their previous behaviour unless major auto-updates are switched on. Check which behaviour your site has: if it does not take major updates by itself, someone has to run them.
Plugins and themes. Core’s automatic updates do not cover them in general: the same page says they happen only in special cases. Since WordPress 5.5 an administrator can opt in plugin by plugin and theme by theme, and by default WordPress then runs those updates twice a day and emails the site owner the result, according to the plugin and theme auto-updates documentation. The same page tells you to update plugins and themes to the latest version to keep the site secure, and suggests making sure you can roll back to a previous version of the site before you enable auto-updates, in case things go wrong. In practice: back up, update, then open the site and test the pages that matter.
PHP. PHP is the language WordPress runs on, and your host controls the version. WordPress.org’s requirements page recommends PHP 8.3 or greater. It says WordPress also works with PHP 7.4 and later, but that those versions have reached end of life and may expose the site to security vulnerabilities. PHP’s own policy gives each branch two years of active support and two more of critical security fixes only; after four years it is no longer supported, and users may be exposed to unpatched security vulnerabilities. Look up your branch on that page and ask your host how to move to a supported one.
Backups
A backup is only useful if you can restore from it.
- Take both parts. WordPress.org’s backup guide says a site has two parts, the database and the files, and that you need both to fully restore a typical WordPress site.
- Choose a frequency. The same guide says to back up before every upgrade, and suggests weekly backups for smaller sites and daily for high-activity ones.
- Keep copies in more than one place. It lists the hosting server, cloud storage and a local computer as separate locations.
- Control who can reach them. The Canadian Centre for Cyber Security’s baseline controls for small and medium organizations (control 3.7) say to back up essential systems, make sure recovery actually restores them, and limit who can access the backups.
- Test the restore. The same control says organizations should have clear procedures for restoring from backups. A copy that has never been restored is a guess. Restore it somewhere that is not your live site, and write the steps down.
Security
Most of site security is the other four jobs done on time. A few habits are specific to security, all from WordPress.org’s hardening guide unless noted:
- Keep plugins updated, and delete any plugin you are not using.
- Use strong passwords and turn on two-step authentication. Avoid obvious usernames such as
admin. - Require HTTPS for the admin area, and use SFTP instead of plain FTP if your host offers it.
- Give each person only the access their work needs. The Cyber Centre’s control 3.12 sets out the same principle of least privilege, and its control 3.5 asks for two-factor authentication on high-value accounts, administrator accounts among them.
For a business that needs more than site-level hygiene, such as written security policies, a risk register or ISO 27001 certification, see our security and ISO 27001 page.
Monitoring and performance
WordPress has a built-in check. The Site Health screen (Tools, then Site Health) groups results into critical issues, recommended improvements and passed tests. Among the problems it can report are an outdated PHP version, plugins waiting to be updated, background updates that are not working, and a site that cannot reach WordPress.org to fetch updates. It also recommends removing inactive themes you do not plan to use.
Two things Site Health cannot do are tell you that the site is down, and tell you that a form has stopped delivering. For the first, use an external uptime monitor that emails or texts you. For the second, submit your own contact form and checkout on a schedule. Page speed also depends on what is installed and what is uploaded, so removing unused plugins and resizing images before upload are the first places to look.
Housekeeping
The remaining tasks are small and easy to forget: review who has an account, remove people who have left, click through your own links, renew the domain name and the HTTPS certificate before they expire, and read the notification emails WordPress sends, since they are how you learn that an automatic update failed.
A WordPress maintenance checklist
The frequencies below are our suggested rhythm, not a WordPress.org standard. The one exception is backup frequency, where the backup guide above gives its own suggestion. Adjust upward if the site takes orders or changes daily.
| When | Task | Why |
|---|---|---|
| Weekly | Take a backup, then run pending core, plugin and theme updates | The backup is your way back if an update breaks something |
| Weekly | Open the site and test the pages that earn money: the contact form, the checkout, the login | Site Health cannot see a form that quietly stopped working |
| Weekly | Read the update emails and the Site Health Status tab | The emails report failed automatic updates, and Site Health flags background updates that are not working |
| Monthly | Confirm backups are running and that a copy is stored away from the web server | A backup on the same server is lost with the server |
| Monthly | Review user accounts and roles; remove anyone who no longer needs access | Least privilege limits what a stolen password can do |
| Monthly | Delete unused plugins and themes | Each one is code to keep patched |
| Monthly | Check the PHP version against the supported branches | Unsupported branches get no security fixes |
| Quarterly | Restore a full backup to a test copy and write down the steps | It proves the backup works, before an emergency |
| Quarterly | Review each plugin: still needed, still maintained, still updated | A plugin nobody updates is a standing risk |
| Quarterly | Check renewal dates for the domain name, HTTPS certificate and hosting | A lapsed certificate or domain takes the site offline |
| Quarterly | Review administrator accounts and turn on two-factor authentication where it is missing | Administrator accounts are the high-value ones |
What goes wrong without maintenance
Each item below follows from the sources above.
- Known holes stay open. WordPress.org’s hardening guide says older versions of WordPress are not maintained with security updates, and the Site Health screen notes that plugins have deep access to your site, so keeping them updated is vital.
- Updates silently stop. Plugin and theme auto-updates rely on WordPress’s scheduled tasks to run, and Site Health reports when background updates are not working. A site nobody opens can fall behind without anyone noticing.
- The server runs unsupported PHP. PHP says users of an end-of-life branch may be exposed to unpatched security vulnerabilities.
- There is nothing to restore from. A site needs both its database and its files to be fully restored, and an untested backup may turn out to be incomplete.
- A bad update has no way back. Plugin and theme updates can go wrong, which is why the documentation says to be able to roll back first.
- Nobody finds out. Without monitoring, the first sign of an outage or a broken form is a customer telling you.
What to do if your site shows “Briefly unavailable for scheduled maintenance”
During an update, WordPress puts the site into maintenance mode. According to the developer reference for WP_Upgrader::maintenance_mode(), it does this by creating a file named .maintenance in the WordPress root directory, and it deletes the file to turn maintenance mode off. While the file exists, visitors see the message “Briefly unavailable for scheduled maintenance. Check back in a minute.”, sent with a 503 status, as wp_maintenance() documents. A file named maintenance.php in the wp-content directory replaces that default screen with your own, but only while WordPress is already in maintenance mode: the file does not switch the mode on.
If the message does not clear after an update has finished, wait about ten minutes. The wp_is_maintenance_mode() reference says WordPress is in maintenance mode only if the .maintenance file was created less than 10 minutes ago, so a leftover file stops counting on its own. If the message is still there after that, check the site’s root folder through your host’s file manager or SFTP and make sure the file is gone, and ask your host whether a cached page or a plugin is showing the message. Take a backup first. If the site still misbehaves, the update may not have finished: run it again, or restore your backup.
Doing it yourself or getting help
A small site with a few plugins can follow the checklist above itself. It gets harder as the site gains plugins, languages, customers or integrations, and when the person who does it is also running the business. Before handing it to anyone, ask for the same things in writing: what is backed up, how often, where the copies are kept, whether a restore has been tested, who applies updates and who is told when something fails.
The cost depends on the provider, the plan and the size of the site, so we do not quote a figure here. Our guide to what you keep paying after launch explains how to ask for it as its own line.
Frequently asked questions
What should a WordPress maintenance plan include?
Updates for core, plugins and themes; backups, with a tested restore; security checks; uptime monitoring; and housekeeping such as removing unused plugins and reviewing user accounts. The checklist above breaks each one into a weekly, monthly or quarterly task.
How do I maintain a WordPress site?
Back up, update, test, and read what WordPress reports. Follow the weekly tasks first, since they catch most problems, then add the monthly and quarterly ones.
How often should I update WordPress?
WordPress installs minor core updates automatically on most sites. For plugins, themes and major releases, check at least weekly, and update on the day a security release is announced if you can.
How do I put WordPress in maintenance mode?
WordPress core enters maintenance mode by itself during updates, using the .maintenance file. A maintenance.php file in wp-content only customises the screen visitors see while that mode is on; it does not turn the mode on. WordPress core has no setting for planned maintenance mode, so for planned work people use a plugin or their host’s own tools.
How much does WordPress maintenance cost?
It depends on the site and the provider, so we do not give a number. Get each recurring cost in writing as its own line.