What WordPress maintenance includes, and how to check that it was done

"WordPress maintenance" means five jobs done on a schedule. Updates to WordPress, its plugins and its themes are installed, and someone looks at the site afterward. Backups are kept off the server and have been restored at least once as a test. A monitor watches whether the site is up. A scan looks for signs of a break-in. A report says what was done. It does not mean hosting, design, new features, writing or SEO.

Each of the five leaves a trace you can read yourself, in your own dashboard or in an account you own. This page takes them one at a time: what is done, why, how often, and how to confirm that it happened. The jobs themselves, step by step, are in the WordPress maintenance checklist.

Updates, and the look afterward

What is done. WordPress, every plugin and every theme release new versions. A round of updates installs what is waiting. Then a person opens the site and looks: the home page, the pages that bring in work, each form, and on a store the cart and checkout. If something broke, the update is undone, or the site is restored from the backup taken before the round.

Why it exists. WordPress's hardening guide gives the reason. When a vulnerability is fixed in a new release, the details needed to exploit it are almost certainly public, so a site still on the old version becomes an easier target. Only the latest version of WordPress is officially supported. Plugins are the same: Site Health reports plugins waiting for an update, on the grounds that plugins have deep access to a site.

The look afterward exists because updates break things. WordPress's documentation names a plugin with a compatibility problem, and a theme, among the causes of a blank white page. It also says an old plugin that does not work with new code may be behind a site that looks scrambled after an upgrade. WordPress catches only the worst case by itself: when a plugin or a theme causes a fatal error, it emails the site's administration address. A form that stopped sending, or a layout that shifted, raises no error at all.

What WordPress already does alone. By default, WordPress installs its own minor releases, the maintenance and security ones, in the background. A site first installed on WordPress 5.6 or later takes major releases the same way by default. Plugins and themes can be switched to automatic updates one at a time. WordPress then runs those twice a day and emails the site owner the result.

None of that includes anyone looking at the site afterward. That look, and a way back when it goes wrong, is what a service adds. A plan that only switches on automatic updates has added nothing WordPress does not already do.

How often. A round every week and a round every month can both be defended. WooCommerce's own documentation says a monthly schedule works well for most stores, and that a release with a security fix should go on sooner than the schedule says. The second half is the rule that matters: a security release does not wait for the round.

How to check it was done.

• Go to Dashboard, then Updates. The top of the screen shows "Current version" and "Last checked on" with a date and a time. Select "Check again." Right after a round you should read "You have the latest version of WordPress.", "Your plugins are all up to date." and "Your themes are all up to date." Between rounds, a few items waiting is normal. Anything that has waited longer than the schedule you were given should be in the report as held back, with a reason.
• On the same screen, read the line about automatic updates. "This site is automatically kept up to date with maintenance and security releases of WordPress only." means WordPress installs its own minor releases. On the Plugins screen, the "Automatic Updates" column gives each plugin a link that reads "Enable auto-updates" or "Disable auto-updates". If everything is automatic, ask who looks at the site after an update, and when.
• Go to Tools, then Site Health, and open the Info tab. It lists the version of WordPress, of the active theme and of every plugin, and it can copy the whole list to the clipboard. Save a copy each month. The differences between two months should match the report's list of what was updated.
• Ask which pages and functions were looked at after the last round, and what was done the last time an update broke something.

The method a careful round follows is in how to safely update WordPress, and what to do when one goes wrong is in the failed update runbook. Some plans try each update on a private copy of the site first. How to set up a WordPress staging site explains what that copy is.

Backups, and a restore that proves them

What is done. On a schedule, the site is copied and the copy is sent somewhere other than the server the site runs on. A backup has two parts, the database and the files, and WordPress's documentation says you need both to restore a typical site in full. The copies are kept for a stated number of days. At least once, one of them is restored to a private copy of the site to prove that it works.

Why it exists. The database holds every post, comment and link. WordPress's documentation says it can be erased or corrupted for reasons you do not control, and that a proper backup of the database and the files lets you put things back quickly. It also says why the host's own backup is not enough to lean on. Most hosts back up the whole server, but asking for a copy takes time, and a fast recovery is the point.

How long the copies are kept matters as much as how often they are taken. The hardening guide gives an example: with regular snapshots, a site broken into on May 1 and noticed on May 12 still has copies from before the break-in to rebuild from. A plan that keeps only seven days of copies would have none.

How often. WordPress's documentation suggests once a week for a small site with few posts and daily for a busy one, always before an upgrade, with at least three to five recent backups kept in different places. A store needs backups more often than a brochure site does. A restore takes the site back to the moment of the backup, and every order placed since then is missing from it.

How to check it was done. Ask these in writing:

• Where are the backups kept? The answer should name a place that is not the site's own server.
• How often are they taken, and how many days are they kept?
• Does each one hold both the database and the files?
• When was one last restored as a test, and what was seen?
• Can I download one myself?

Then look. Open the list of backups, in the backup plugin or in your hosting panel, and read the date of the newest one. A schedule says what should happen. The list says what did. WordPress's update instructions call checking that a backup is there and usable essential, and its backup documentation recommends a manual backup now and then to confirm that the automatic ones are working.

Once, ask for the newest backup to be restored to a private copy, and look at the copy yourself. You should be able to log in, find something published in the past few days, and see the images load. How to schedule automatic WordPress backups covers the three places a schedule can live and how the test is done.

Uptime monitoring, and who answers the alert

What is done. A service outside your server requests the site at a fixed interval and alerts someone when it gets an error or no answer. That is half the job. The other half is what the person alerted does next.

Why it exists. WordPress cannot report that its own server has stopped answering, because it runs on that server. Its error emails cover a fault inside WordPress, not a site that is unreachable. An outage also costs more than the visits lost while it lasts. Google's documentation says server errors make its crawlers slow down, and that pages already in its index are kept at first and eventually dropped.

How often. All the time, with a request every few minutes. The interval decides what the monitor can see: one that asks every five minutes can miss an outage that lasted two. An uptime percentage means little without the interval beside it.

How to check it was done.

• Ask which monitoring service is used, how often it checks, and which pages it requests.
• Ask who receives the alert, what they do then, and in which hours a person acts on it. An alert nobody reads until morning is a record, not a response.
• Ask for the monitor's own log, or for read access to it. The report should list each outage with its date and its length.
• For a second opinion, open Google Search Console, select Settings, then "Crawl stats", and read "Host status". It says whether Google met availability problems while crawling the site in the past 90 days. Google describes the report as one for advanced users, and it records only what Google's crawler ran into, so it does not replace a monitor. A problem that shows there and not in your monthly report is worth a question.

Security scanning, and what happens after a finding

What is done. Software compares the site with what should be there and reports the differences. WordPress's documentation describes two kinds. One runs inside the site as a plugin. The other requests the site's pages from outside and reads what comes back. They look for different things. The documentation says no single one is the best approach, and that together they improve the odds.

Scanning finds. It does not clean. Removing what a scan found is separate, skilled work: Google's help for site owners says fixing a malware problem takes the ability to read and understand code, and possibly web server configuration. Whether a plan includes that cleanup is one of the first things to ask.

Why it exists. The hardening guide says prevention is sometimes not enough and a site may still be broken into, and that monitoring lets you react faster, find out what happened and recover. It adds that an attack leaves traces, in the logs or as new and changed files. A scan is how those traces are found before a visitor or a search engine finds them for you.

How often. A scan runs unattended, so it can run as often as the backups do. How often matters less than what happens when it finds something.

How to check it was done.

• Ask what kind of scan it is, how often it runs, who reads the result, and what is done about a finding.
• In Search Console, open the Security issues report. With nothing found, it shows a green check mark. Google says to rely on this report as the source of truth for whether it has found a security issue on the site.
• Go to Users. The Role column shows each account's role, and the links above the table filter the list by role. Every administrator should be someone you can name. WordPress's documentation counts a user nobody authorized among the clear signs of a hack.
• For a check from outside that needs no login, run the hacked site check. The fuller set of checks, inside and out, is in how to check whether your WordPress site has been hacked.

Keep your own view of the site

You can check the work only while you can still see the site. Three things keep that true.

• Your own administrator account. An administrator has access to all of a site's administration features. Whoever maintains the site needs that role. So do you.
• An administration email you read. Go to Settings, then General. "Administration Email Address" is where WordPress sends its notices about updates, recovery mode and fatal errors. If that address belongs only to the person maintaining the site, those notices never reach you.
• Search Console under your own Google account, so the two reports above are yours to open.

What a monthly report should show

A report is the part of maintenance you actually receive. A useful one can be checked line by line against the screens above. It shows:

• What was updated, from which version to which, on which date. Anything held back, and why.
• What was looked at after each round.
• How many backups were taken, the date of the newest, where they are kept, and the date and result of the last test restore.
• The monitor used, how often it checks, and each outage with its date and length.
• What the security scan checked, what it found and what was done.
• The changes you asked for and the time they took, if the plan has an allowance of time.
• Anything that needs a decision from you.

Two things should make you look harder. A count of "attacks blocked" is not a scan result: it says how many requests a tool turned away, not whether the site is clean. And a report whose words are the same every month was not written about this month.

The monthly maintenance report template shows each section filled in and where each figure comes from. Ask a service for a sample report before you sign, and compare the two.

What is maintenance, what varies and what is a separate job

No rule defines the word, so read the list and not the name. The first group below is the five parts above, with the way back that updates need. A plan without one of them leaves that job with you. The second group is inside some plans and an extra in others. The third is different work: it changes the site, where maintenance keeps it as it is.

As one example of where the lines fall, every plan in our WordPress maintenance service includes weekly updates to WordPress core, plugins and themes, with a visual check afterward and a rollback if something is wrong, daily offsite backups, uptime monitoring, security scanning, a restore if an update breaks the site, and a monthly report. Hosting, redesigns and new features are not part of a plan.

To compare services on these points, how to choose a WordPress maintenance service has the questions to put to each one in writing.

What maintenance does not promise

No plan can rule out an attack or an outage. WordPress's hardening guide says the same of security in general: it is risk reduction, not risk elimination. Each part has a limit worth knowing.

• Updates close holes that have been found and fixed. They do nothing about a hole that has no fix yet.
• A backup takes the site back to the moment it was made. Whatever was added after that is not in it.
• A monitor reports an outage. It does not prevent one. The server is the host's to keep running.
• A clean scan lowers the odds. It is not proof. Each kind of scan looks at only part of a site.

What maintenance changes is how soon a problem is noticed, how far back you can go, and whether someone is already responsible when it happens.