Website Maintenance Plans: What's Included

A maintenance plan is a scope document, not a feeling of safety. Two proposals can both promise to keep a website healthy while covering very different work, and the gap only becomes visible during an incident or a busy month. Reading the plan as a list of obligations — who does what, how often, within what time frame, and with what evidence — is the difference between a service and a slogan that renews every month whether or not anything happened.

The first month of any plan should look different from the tenth. Onboarding includes an inventory of the current stack, a review of accounts and access, a baseline measurement of performance, and a written list of known risks. That audit is what lets a provider make commitments with a straight face; without it, the first incident is managed by guesswork. Ask to see the onboarding checklist before signing, and treat its absence as a signal that the plan is priced from a template rather than from your site.

Updates are the first item to pin down. Core, plugin, and theme updates each carry compatibility risk, so the plan should say whether updates happen on a staging copy first, who tests the result, and what happens when an update breaks a template or a checkout flow. Some environments update weekly, others monthly with a security exception path. The policy matters more than the frequency: an automated update that silently breaks a form is worse than a scheduled one with a rollback plan and someone watching.

Backups need three properties to mean anything: they must be offsite, they must be verified, and they must have been restored at least once. A plan that lists a backup plugin but never tests a recovery is offering a file that may not open when it is needed. Ask where backups live, how long they are retained, whether database and uploads are both included, and how long a restore takes. A monthly restore rehearsal on a staging environment is inexpensive insurance for the day the real thing is required.

Security work should be visible in the plan rather than assumed. Hardening covers login protection, user roles, file permissions, and disabling unused entry points; monitoring watches for known vulnerabilities, malware, and unusual file changes. When something happens, the response path — who is contacted, how the site is contained, and how recovery proceeds — should already be written. A maintenance plan without an incident procedure quietly transfers that planning work back to the site owner at the worst possible moment.

Monitoring covers more than whether the homepage loads. Uptime checks should watch the pages that matter, including forms and checkout where relevant, and performance should be tracked against a budget rather than admired occasionally. Certificate expiry, DNS changes, broken links, and failed form submissions all belong on the watch list. Alerts should route to a person who can act on them, with a documented answer to the question of what happens at two in the morning versus during business hours.

Content changes are where expectations most often diverge. Plans typically include a pool of small edits per month — text swaps, image updates, new staff members, campaign pages from existing templates — with a defined turnaround and a clear boundary around larger work. Redesigns, new templates, and third-party integrations are projects, not maintenance, and pricing them as maintenance is how plans become unprofitable and unresponsive. The boundary should be written down before the first request arrives, not negotiated during it.

Reporting is the evidence that the plan is doing something. A useful monthly report lists what was updated, what was monitored, any incidents and how they resolved, performance trend lines, and recommendations for the month ahead. It should be written for a business reader rather than a server administrator. If a provider cannot show what changed and what was checked, the plan is being paid for on faith, and renewals deserve a harder look.

Response times and availability need honest definitions. Business-hours response, next-business-day response, and round-the-clock coverage are different products at different prices, and each should be stated with the clock that applies. The same applies to maintenance windows: a plan that promises 99.9 percent uptime should explain how scheduled updates and emergency work fit inside that number. Vagueness here is not generosity; it is a dispute waiting for its moment.

Before signing, ask who owns the domain, hosting, CMS accounts, and repository, and what happens to all of it if the relationship ends. A good provider keeps those assets in the client's name and hands over documentation on exit. Compare plans on the same checklist — updates, backups with restore tests, security response, monitoring, edit hours, reporting, and exit terms — and the choice usually stops being about price and starts being about fit for how your team actually works.