A website maintenance plan should state what is backed up, how often, where copies are stored, who can restore them, and how recovery is tested. Ask for evidence of a recent successful backup and a recent restore test rather than accepting a checkbox that says backups are enabled.
Does the plan cover the whole site?
List the database, uploaded media, themes, plugins, application code, configuration, redirects, server rules, certificates, DNS records, and external service settings. Mark which items are inside the backup and which require a separate export. A host snapshot may not include the domain registrar, third-party forms, email service, analytics, or a source repository.
WordPress documentation explains that a typical site needs both its files and its database for a full restore. The files include core, themes, plugins, uploads, configuration, and server files, while the database lives separately. See WordPress Backups. Ask the maintainer to identify both parts and show that they belong to the same recovery point.
How are copies retained and separated?
Ask how many restore points are kept, how old the oldest usable copy is, and whether at least one copy is outside the production hosting account. WordPress recommends keeping multiple recent backups in different locations. Verify that encryption and account recovery do not depend on the same single administrator who manages production.
Record who can create, download, delete, and restore copies. Remove former vendors and unnecessary accounts only after confirming that the owner retains a working recovery path. Do not place database dumps in a public web directory.
Is an export actually restorable?
A database export is only one component. WordPress says a database export usually produces an SQL or compressed file, but a full-site backup still needs files such as themes, plugins, uploads, and `wp-config.php`. Its database guide also explains that restoring requires importing the dump into MySQL or MariaDB. See Backing Up Your Database.
Ask whether the restore process expects an empty database, matching credentials, a particular server version, or manual URL changes. Include expected recovery time and the person authorized to approve a production restore.
When does backup run?
Require a schedule plus event-based copies before core, theme, plugin, configuration, hosting, or migration changes. The WordPress maintenance guide recommends making backup part of the regular maintenance schedule and keeping copies on both the host and a local computer. See WordPress site maintenance.
How is recovery tested?
Restore into a private test environment. Check pages, media, login, forms, redirects, search, scheduled tasks, integrations, and administrative access. Record the backup identifier, start and finish times, errors, manual steps, and final verification. Never overwrite the live site for a routine drill without explicit approval and a separate rollback path.
A credible maintenance plan ends with measurable answers: complete scope, retention, separate storage, named access, documented procedure, tested restore time, and unresolved exclusions. Those details make the backup useful when the site actually fails.
Sources
- WordPress Backups — WordPress Developer Resources
- Backing Up Your Database — WordPress.org
- WordPress site maintenance — WordPress.org