A website maintenance plan works when it keeps the supported site secure, recoverable, accurate, and usable with a predictable amount of effort. A checklist completed on schedule is evidence of activity, not evidence of protection. Define measurable outcomes, preserve test results, and review exceptions rather than marking every item green.
Define the supported surface
Inventory domains, hosting, content systems, plugins, themes, runtime versions, databases, forms, analytics, third-party scripts, certificates, DNS, backups, and responsible owners. Mark what the plan does not cover. An unknown component cannot be patched or restored deliberately.
Record a baseline for uptime or synthetic checks, page errors, form delivery, broken links, accessibility defects, security findings, stale content, backup age, restore-test age, and maintenance hours. Use several weeks where possible so one unusual incident does not become the baseline.
Measure patch and vulnerability work
NIST frames patch management as preventive maintenance and describes a lifecycle of identifying, prioritizing, acquiring, installing, and verifying patches in SP 800-40 Rev. 4. Measure each stage. Useful records include discovery date, affected asset, risk basis, owner, planned date, test evidence, deployment result, exception, and verification.
Prioritize with evidence rather than severity labels alone. CISA calls its Known Exploited Vulnerabilities Catalog an authoritative list of vulnerabilities exploited in the wild and recommends using it as an input to vulnerability prioritization. The catalog is an input, not a complete scanner or a substitute for knowing which software the site runs.
Track median and oldest open remediation age, critical exceptions, failed updates, and verification coverage. Do not claim a site is secure because its visible pages load after an update.
Test recovery and user journeys
Run scheduled backups and record whether they completed, but also restore a representative copy in an isolated environment on a defined cadence. Verify page content, database records, media, forms, redirects, access controls, and configuration. Measure recovery time from the beginning of the exercise to a verified usable result. Never overwrite the only production copy to prove a backup works.
Test the journeys that matter: home and key landing pages, navigation, search, contact or checkout flow where applicable, confirmation messages, mobile layout, keyboard access, and a deliberate missing page. Use synthetic tests and human review; each catches different failures. Record the exact URL, time, environment, expected result, observed result, and evidence.
Review content and ownership
Each month, sample high-traffic and high-consequence pages for current prices, dates, policies, contact details, claims, and destination links. Track stale findings to closure. Review users and service accounts against current responsibilities. Confirm that domains, certificates, hosting, and important integrations have named renewal and escalation owners.
Build a decision-ready scorecard
A useful monthly scorecard shows patch verification rate, oldest important exception, restore-test result and age, failed critical journeys, unresolved content defects, unexpected access, incident count, and maintenance effort. Include denominator and scope: `18 of 20 plugins verified` is clearer than `90 percent complete`.
Set thresholds before reviewing results. Escalate missed restore tests, actively exploited vulnerabilities affecting the stack, repeated form failures, expired ownership details, and unsupported components. When data is missing, label the result unknown rather than passing it. A maintenance plan is working only when its records demonstrate that the site can be kept current and recovered by the people assigned to it.
Sources
- Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology — National Institute of Standards and Technology
- Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency