A website maintenance plan is only useful if it still protects the site after a major change. A new host, theme, plugin, administrator, update policy, or backup service can create gaps that are not visible on the homepage. Verification should combine front-end checks, administrator checks, and a recovery test.
Define the changed scope
Record the date, change owner, affected domain, host, content system, theme, plugins, integrations, and maintenance responsibilities. Save the previous plan and mark which tasks moved to a new provider or schedule. Confirm who now owns the domain, hosting, backups, administrator accounts, monitoring, and emergency contacts.
Capture a baseline before or immediately after the change. Include software versions, active theme and plugins, key page URLs, forms, redirects, scheduled jobs, user roles, backup time, and search-indexing settings. For WordPress sites, the Site Health screen reports critical issues, recommended improvements, passed tests, and technical information about themes, plugins, server, database, and file permissions. Export or retain that information as part of the verification record.
Verify the public site
Visit the homepage and important landing pages on desktop and mobile. Check navigation, images, fonts, headings, contact details, calls to action, legal links, accessibility basics, and HTTPS. Test old URLs and redirects. Confirm that staging or maintenance pages are not indexed and the live site is not accidentally discouraging search engines.
Submit every critical form using owner-controlled test details. Verify validation, confirmation pages, email delivery, spam protection, routing, and stored submissions. Test booking, checkout, account, or download flows when they are part of the site's purpose. Do not use real payment details in a live test unless the owner has authorized a controlled transaction.
Verify maintenance and security behavior
Check update settings for the core platform, themes, plugins, and server software. Confirm that monitoring can detect downtime and certificate problems. Review logs for errors introduced by the change. Test scheduled jobs, backups, cache clearing, security scans, and renewal reminders.
WordPress says its Site Health feature checks website health and can surface configuration errors related to plugins and themes. The project recommends checking Site Health regularly. Treat it as one signal, not a substitute for testing forms, integrations, and business workflows. Record each unresolved critical or recommended issue with an owner and due date.
Review permissions. Confirm that current maintainers have individual accounts and only the access they need. Remove former vendors and unused administrators. Check recovery email, multifactor authentication, API keys, deployment credentials, and ownership of analytics and search tools. Make sure the emergency procedure works without depending on a departed contractor.
Verify backup and recovery
A backup must cover the parts required to rebuild the site. WordPress's backup guidance says a complete site relies on both files and database data and recommends backing up before an upgrade or move. The guidance treats files and database created around the same time as one backup set. Confirm that the plan covers media, themes, plugins, code, configuration, and the database, plus external items such as DNS and form-provider data.
Restore a recent backup to an isolated staging environment. Record the backup date, restore time, warnings, and checks performed. Verify pages, media, user roles, forms, redirects, scheduled tasks, and integrations. Protect or remove the staging copy when the test ends so it does not expose submissions or compete with the live site in search.
Accept or repair the plan
Create a checklist with expected result, actual result, evidence, severity, and owner. A maintenance plan passes when required tasks have clear owners and schedules, the live site works, security and update signals are reviewed, backups are current, and a restore has been demonstrated.
If the plan fails, prioritize access, backups, forms, checkout, and public security problems. Preserve the last known-good site and change record. Repair the smallest affected component, then repeat the tests. The final plan should state what is maintained, by whom, how often, how failure is detected, and how the site is restored.
Sources
- Site Health screen — WordPress.org
- Site Health: keep your website healthy — WordPress.org
- WordPress Backups — WordPress Developer Resources