What Should a Website Maintenance Plan Actually Cover?

A website maintenance plan should state which systems are covered, who keeps them working and what evidence you receive after changes or incidents. “Updates and support included” is too vague to establish whether the provider checks forms, restores backups or investigates a failed integration. Review the plan against the website's real dependencies and business journeys.

Separate preventive work, incident response and requested changes. They involve different responsibilities and may have different allowances. A clear agreement lets both sides understand what happens during an ordinary month, an urgent failure and a new feature request without relying on assumptions about what maintenance means.

Define the Website and the Support Boundary

List the hosting environment, CMS, frontend, database, media storage and external integrations. Include domain and DNS ownership, email delivery and any services needed for forms or transactions. The maintenance provider may not control every system, but the plan should identify who does.

A headless website needs particular clarity because the CMS and public frontend are separate applications. Updating WordPress does not automatically update frontend dependencies or verify content refresh. The agreement should cover the connection as well as the individual systems where that is part of the provider's role.

Mark Inclusions and Exclusions in Plain Language

Ask whether content edits, design adjustments, performance investigation and integration changes are included, limited or separately scoped. “Small changes” needs a definition. A short text update differs from changing a form field that affects CRM mapping and reporting.

Use a coverage matrix to avoid gaps between suppliers. The following is a buyer's worksheet, not a statement that every maintenance package should include every task at the same price.

Responsibility	Named owner	Evidence to request	Boundary to clarify
Hosting operation	Host or infrastructure team	Relevant service status and access	Application debugging may be separate
CMS and plugin updates	Maintainer	Versions changed and verification	Unsupported custom extensions
Frontend updates	Frontend maintainer	Build, release and regression results	New features versus maintenance
Backups and recovery	Agreed operator	Coverage and restore-test record	External systems and data gaps
Forms and integrations	Assigned technical owner	End-to-end synthetic test	Third-party availability and support
Content changes	Approved editor or provider	Exact change and review	Allowance, approval and exclusions

If a row has no owner, resolve it before signing. An excluded responsibility is manageable when the business assigns it elsewhere; an invisible responsibility often becomes an incident-time dispute.

Require Verification After Updates

Updating software is an action, not proof that the website still works. Ask how the provider evaluates a release, prepares recovery and checks the result. The level of testing should reflect the dependency and risk, with a more careful process for changes affecting forms, checkout or access.

Agree a representative regression set. It may include key page templates, navigation, enquiry submission, search and an editorial save-and-preview task. For a store or portal, add relevant payment or permission scenarios using authorised test methods.

Keep Accessibility and Layout Regressions in Scope

Changes can affect keyboard access, focus, mobile overflow or image layout without causing an obvious server error. Include practical checks on important journeys at suitable screen sizes. Automated tools can assist, but their coverage should be stated honestly.

Do not require a claim of complete browser QA when only an automated build ran. A useful report says which pages, devices or conditions were actually checked. This lets you distinguish a verified change from one that still needs review.

Verify Backup Coverage and Restoration

Ask what the backup contains, where it is stored, how access is protected and how it can be restored. WordPress's backup documentation distinguishes database content from site files. A typical recovery needs both, and a separate frontend or external media service adds further dependencies to review.

The schedule should reflect how often important data changes and how much loss the business can tolerate. A static brochure site and a busy store have different recovery needs. Avoid accepting a generic frequency without discussing the actual content and transaction pattern.

Ask for an Isolated Restore-Test Record

A backup-completed notification is useful but does not prove a working restoration. Request evidence of an appropriate isolated exercise, including representative content, media and essential functions. The restored environment should not send real emails, payments or webhooks unintentionally.

Record observed recovery time and gaps without converting one test into an unconditional guarantee. Confirm what would happen if the primary hosting account were unavailable. Access to a backup stored only within the failed account may not meet the intended recovery requirement.

Define Monitoring by the Failure It Can Detect

An uptime check can detect some availability problems, but a homepage returning success does not prove that enquiries reach the CRM. Identify which failures matter and how they will be observed. Include content refresh, certificate expiry or failed jobs where relevant to the site.

Agree who receives alerts and when they are reviewed. An alert sent to an unattended inbox is not a response process. State the escalation route if the primary person is unavailable and the conditions that justify urgent action.

Monitor Critical Journeys Without Creating Side Effects

Use appropriate synthetic checks and test destinations. A form monitor should not flood the sales pipeline, and a checkout check should not place unauthorised live orders. Define how test records are labelled, reconciled and retained.

For lead-generation sites, the website and CRM integration guide explains the difference between form acknowledgement and completed handoff. Maintenance coverage should reflect the actual business endpoint rather than stop at the easiest visible check.

Separate Response Commitments from Resolution Commitments

A response time describes when the provider acknowledges or begins handling an issue according to the agreement. Resolution depends on diagnosis, access and sometimes another supplier. Ask what each commitment means, which hours apply and how severity is determined.

Do not assume an urgent label guarantees a fix within the same period. Review dependencies and escalation obligations. Appropriate contractual advice may be useful for critical services; the operational goal is to ensure that both sides understand the commitment in practice.

Walk Through a Realistic Incident Example

Consider a hypothetical case where the site loads but new enquiries are not appearing in the CRM. Who checks the form record, who inspects the connector and who contacts the CRM provider? Who tells the business which enquiries may be pending and how they will be recovered?

Use that scenario to test the agreement. A host may confirm the server is available while the failure remains in application mapping. Without an application owner, the business can receive several technically correct responses and still have no functioning lead flow.

Clarify Authority for Changes and Emergencies

Define who can approve routine edits, dependency changes and urgent protective actions. Give the maintainer enough authority to perform the agreed work while preserving boundaries around deployment, accounts and sensitive data. Keep approval records for changes outside the standing scope.

State how emergency work is documented afterwards and how the business is informed. An urgent situation does not justify losing the record of what changed. The report should identify affected systems, verification and any temporary measures that require follow-up.

Preserve Business Ownership of Access

Keep domain, hosting, repository and important service accounts under appropriate business control. Use individual access where supported and revoke it when roles change. Do not rely on a provider's personal account as the only route to essential infrastructure.

Credentials should be handled securely, not pasted into routine maintenance reports. The handover should identify where access is managed and who can authorise it without exposing secrets. Recovery procedures need to work even when the original developer is unavailable.

Ask for Reports That Explain Work and Remaining Risk

A useful report lists the exact changes, reason, verification and unresolved items. It separates completed work from recommendations and pending approvals. A screenshot of several green indicators is not enough if it does not explain what those indicators cover.

Report entry	Useful evidence	Weak substitute
Software update	Component, previous and new version, tests	“Everything updated”
Backup verification	Included systems and restoration result	“Backup successful” alone
Form check	Synthetic submission and confirmed destination	Homepage screenshot
Incident	Cause, action, affected scope and follow-up	“Issue resolved” without explanation
Known risk	Impact, owner and next decision	Hidden exception outside the report

Keep reports concise enough to use, but retain detailed evidence where it matters. The business should be able to answer what changed, whether essential functions still work and which decisions remain outstanding.

Review Coverage When the Website Changes

Adding a booking system, client portal or separate frontend changes maintenance responsibilities. Review the agreement when those dependencies are introduced. Do not assume the original package automatically covers a materially different application.

Revisit recurring tools that no longer serve a purpose. The third-party script governance guide offers a practical owner register for that part of the site. Maintenance should prevent obsolete dependencies from accumulating unnoticed, while preserving approved functions.

Plan Provider Exit Before You Need It

Agree what documentation, backups, code and access records are handed over if the provider changes. Include unresolved incidents, renewal responsibilities and the current dependency inventory. Test that the receiving team can understand the setup before removing the previous access.

A controlled transition protects both the business and the outgoing provider. It avoids emergency reconstruction of undocumented settings and makes it clear when responsibility transfers. Keep necessary records without retaining unnecessary access or private copies of data.

Use the Matrix to Compare Maintenance Proposals

Compare providers against the same website inventory, critical journeys and response needs. Differences in price may reflect genuine differences in coverage, testing or availability. Choose with those boundaries visible rather than assuming every plan labelled maintenance provides the same service.

When agreeing maintenance coverage, bring the completed matrix and incident example. They turn a broad retainer into an understandable operating agreement with evidence, ownership and a practical route for change.