WordPress restore validation: prove a backup can rebuild the site

Restore into an isolated destination

Use a temporary hostname or private mapping so the test does not overwrite production. Restore the database and wp-content/code/config according to the backup design, then record any manual steps required.

Avoid running restored cron, payment, marketing, or outbound email against live external services.

Verify content and application state

Check recent posts/orders/users or other known records around the backup timestamp, media uploads, plugin/theme versions, permalinks, admin login, and application-specific tables.

A homepage rendering does not prove the database or uploads are complete.

Exercise dynamic paths

Test forms, authenticated pages, ecommerce/cart in sandbox mode, search, scheduled jobs, REST/API endpoints, image processing, and any plugin integrations appropriate to the site.

Review PHP/web/database logs for warnings that the browser does not expose.

Measure recovery time and missing prerequisites

Time the restore from access to usable test site and document DNS/TLS/runtime steps not contained in the backup. Add those gaps to the backup runbook so recovery does not depend on memory. Record the exact archive timestamp and restored database version so the test can be repeated against a later backup and compared consistently.

• Restore away from production.
• Check known recent data.
• Test dynamic features.
• Record recovery time and missing dependencies.