What a Website Maintenance Plan Should Include: A Checklist

Most website maintenance quotes arrive as a single monthly figure with a few bullet points underneath. That makes them hard to compare, because two quotes at the same price can describe very different work: one may include tested restores and a named person who answers when the site is down, while the other amounts to switching on automatic updates and hoping for the best. The useful question is therefore not "how much per month" but "which duties are written down, who performs them, how often, and what evidence do I receive".

This checklist is written for owners of small business websites, whether the site runs on WordPress, TYPO3, Shopware or something custom. Where we describe WordPress behaviour we rely on the official WordPress handbook pages and on the PHP project's support table, all opened in October 2026. Everything else in this article is a working practice rather than a published rule, and we mark it as such so you can judge it for yourself.

Use it in two ways. If you already pay for maintenance, tick off what your current provider does. If you are comparing quotes, send the table in section six to each provider and ask them to fill in the gaps. A provider who answers line by line is usually easier to work with than one who replies with a brochure. For an overview of what we offer, see website maintenance.

Updates are the part of maintenance most people picture, and also the part most often done carelessly. The WordPress handbook describes four kinds of automatic background update: core, plugin, theme and translation files. Automatic background updates have existed since WordPress 3.7, and translation files are updated automatically by default. For core, the handbook explains that before WordPress 5.6 every site received automatic updates for minor releases only, while new installations from 5.6 onward receive both minor and major core updates by default unless WordPress detects a version-control checkout. Existing installations keep the older behaviour unless an administrator, a constant or a filter changes it.

That has a practical consequence for your plan. Two WordPress sites of the same age can behave differently, so do not assume that "automatic updates are on". Ask the provider to state, for your site, which update types are automatic and which are applied by a person after a check. The handbook also says that disabling the automatic minor and translation updates completely is strongly discouraged, so a plan that switches everything off should come with a clear reason.

Plugins and themes need their own rule. The WordPress documentation shows that auto-updates can be enabled plugin by plugin from the Installed Plugins screen, which means you can choose automation for low-risk plugins and manual, tested updates for the ones that control checkout, forms or the page layout. A sensible plan records that choice in a list rather than leaving it to habit.

What to write into the plan

• Which update types run automatically and which are applied by hand.
• Whether updates are tried on a staging copy first (practice, not a rule: for shops and booking sites we would insist on it).
• How quickly a security release is applied once it is published.
• Who restores the site if an update breaks it, and how long that takes.

A site can be fully updated at the application level and still sit on an unsupported server. The WordPress requirements page currently recommends a host that supports PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, and HTTPS. It adds that WordPress also works with PHP 7.4 and above and MySQL 5.5.5 and above, but that those versions have reached end of life and may expose a site to security vulnerabilities.

The PHP project publishes the support calendar for each branch. Each release branch is fully supported for two years and then receives critical security fixes only for two more. According to the table the PHP project shows today, branch 8.2 receives security support until 31 December 2026, branch 8.3 until 31 December 2027, branch 8.4 until 31 December 2028 and branch 8.5 until 31 December 2029. If your site runs on 8.2, that date is close, and a good plan includes a dated upgrade step before it arrives rather than a scramble afterwards.

Put the following into the plan: the PHP version the site runs on today, the date that branch stops receiving security fixes, the month in which the provider will test and move to a newer branch, and who pays for the compatibility work if an old plugin does not run on the newer version. That last point is where disputes start, so settle it early.

The WordPress handbook is direct about what a backup must contain: a typical site has two parts, the files and the database, and you need both to restore it fully. Backing up the files does not back up the database. It suggests weekly backups for smaller sites with few posts and daily backups for busy sites, and advises keeping at least three to five recent backups in different places, for example one on the hosting server, one in cloud storage and one downloaded to a local computer. It also recommends taking a manual backup now and then to prove the automatic process still works.

The UK National Cyber Security Centre gives matching advice for small organisations. It suggests considering two backups, online and on a separate storage device, in case one is lost or fails, and protecting online backups with 2-step verification. It also says that after making a backup you should know how to restore it and check that it contains all your important data.

Turn this into plan wording. Ask for the backup frequency, the number of copies kept, where they are stored (and whether any copy sits outside the hosting account that could be compromised), how long copies are kept, and how often a restore is rehearsed. A restore test on a staging copy once or twice a year is cheap and is the only real proof that the backups work. If a provider cannot tell you when they last restored one of their own backups, treat that as a warning sign.

For shops and booking systems, add one more question: how much data can you afford to lose? A weekly backup means up to a week of orders could be gone. Such sites usually need daily database backups, and some need more frequent ones.

Updates and backups are preventive; monitoring tells you when something has gone wrong anyway. These items come from common agency practice rather than from a single published standard, so treat the frequencies as starting points to agree with your provider.

• Uptime checks. An external monitor requests the home page and a key transactional page every few minutes and alerts a named person.
• Certificate and domain expiry. HTTPS is a stated WordPress requirement, so an expired certificate is an outage in all but name. Agree who owns the renewal and who holds the domain login.
• Security scanning. Regular scans for changed core files and known malware signatures, with a note of who is told and how fast.
• User and permission review. Remove accounts of people who have left, and make sure every administrator uses two-step sign-in.
• Form and email delivery tests. Contact forms often fail silently after a mail-provider change. A monthly test submission catches this.
• Broken links and error logs. A short report of new 404 pages and server errors.

The NCSC's small-organisation guidance also reminds owners to keep the devices that manage the site up to date and to replace equipment that no longer receives updates. That sounds like a different topic, but a laptop with an old browser and a saved administrator password is one of the realistic ways into a site, so include "devices used for administration" in your own housekeeping.

Send this table to every provider you are comparing. The frequencies are our suggested starting points for a small business site; a larger shop will want tighter ones. The right-hand column is the evidence you should expect to receive, because a duty without a report is difficult to check.

If a provider does not offer a line, that is fine as long as it is stated. A plan that says "no restore tests" lets you decide; a plan that stays silent leaves you to find out during an emergency.

The second half of any maintenance quote is the service level. Three phrases deserve precise definitions.

Response time. This is how long until a person acknowledges a problem, not how long until it is fixed. Ask for both numbers, and ask whether they differ for a site that is completely down versus a cosmetic fault.

Support hours. If the plan covers weekdays only, and your shop trades on Sunday, you need to know that. Ask what happens outside those hours and whether an emergency line exists, and at what cost.

Included hours. Many plans include a small pool of hours for changes. Check whether unused hours roll over, whether content edits count against them, and how extra work is charged. Content changes, new features and redesign work are normally separate from maintenance, and the plan should say where the boundary sits.

Also look for exclusions. Typical ones are problems caused by third-party plugins the provider did not install, hacked sites where the original cause predates the plan, and hosting failures where the host is a separate company. None of these is unreasonable, but you should know about them in advance. A plan that excludes recovery of a hacked site, for example, may still be right for you if you buy that service separately; it is wrong only if you assumed it was covered.

When quotes arrive, strip them down to the same structure before you look at the price. Write each provider's answers into the table above, then add three rows of your own: who has access to your hosting and admin accounts, who owns the backups, and what happens if you leave.

Ownership matters more than it sounds. You should hold the domain registration, the hosting account or at least an administrator login to it, and a copy of the latest backup. If all of these sit under the provider's own account, switching later becomes a negotiation. This is a point of contract rather than technology, so put it in writing.

Be wary of two patterns. The first is a very low monthly price with unlimited "support" and no listed duties; the work behind such a price is usually a bulk update run across many clients at once, with no testing. The second is a long list of tools and acronyms with no frequencies or reports. Neither is proof of poor work, but both make it hard to hold anyone to account.

Finally, ask for a trial period or a short initial term. A first month in which the provider documents your site's plugins, versions, hosting and backup set-up is valuable in itself, because it produces the inventory that every later decision depends on. If you would like us to quote against your own checklist, use the quote form, and see pricing for how simple websites are priced.

Whatever you decide about providers, five actions will improve your position within a week.

1. List every plugin, theme and integration on the site, with its version. Delete anything unused.
2. Find out your PHP version and the date its security support ends, using the PHP project's table.
3. Take a full backup of files and database, store a copy outside your hosting account, and then try restoring it on a spare copy of the site.
4. Check that every administrator account belongs to a current person and uses two-step sign-in.
5. Write down who owns the domain, the hosting, the DNS records and the certificate, with renewal dates.

With that inventory in hand you can read any maintenance quote critically. A plan is good when you can see what is done, when it is done and what proof you receive. If you want help turning this into a written plan for your site, contact us.

• Upgrading WordPress, including automatic background updates (WordPress Developer Resources)
• Backups (WordPress Advanced Administration Handbook)
• WordPress requirements
• Manage plugins (WordPress documentation)
• PHP: Supported Versions
• Backing up your data (NCSC small organisations guide)
• Protecting your devices (NCSC small organisations guide)