WordPress Backup and Restore Checklist: Files, Database, Testing, and Recovery

Overview

A complete WordPress backup should contain everything required to rebuild the site in a clean hosting environment. That normally means the WordPress core files, the wp-content directory, the configuration file, and a database export. Depending on the site, you may also need server configuration, custom deployment scripts, scheduled-task definitions, redirects, DNS notes, and credentials stored in a secure password manager.

The database contains structured content such as posts, pages, users, settings, comments, and plugin data. Files contain themes, plugins, uploaded media, generated assets, and configuration values. A backup that includes only one of these layers may be useful for a limited repair, but it is not a dependable full-site recovery copy.

Use at least two storage locations: one accessible through your hosting account or backup system, and another separated from the production server. Off-site storage reduces the risk that a compromised account, failed disk, or accidental deletion affects both the live site and its backup. Protect backup archives because they may contain database records, private uploads, configuration secrets, or user information.

Before selecting a backup method, document the site’s operating assumptions: PHP version, database engine, WordPress version, active plugins, theme, domain names, SSL setup, scheduled jobs, and any external services. A short recovery document can save time when the normal administrator is unavailable.

Checklist by scenario

Routine scheduled backup

• Back up the database: Export the complete WordPress database using your hosting control panel, a database utility such as phpMyAdmin, a command-line client, or a reputable backup plugin. Confirm that the export completes rather than assuming a scheduled task succeeded.
• Back up the files: Include wp-content/uploads, themes, plugins, must-use plugins, and custom files. Include wp-config.php in a protected archive, even if your backup tool treats it separately.
• Record the backup time: Use a consistent timestamp and site identifier in the filename. Note whether the archive is a full backup, database-only backup, or files-only backup.
• Copy it off-site: Transfer the archive to approved remote storage and verify that the upload completed. Do not rely on a backup that exists only on the same server as the live site.
• Check retention: Keep enough restore points to cover delayed discovery of a problem. A practical policy may include recent daily copies, less frequent long-term copies, and a protected copy before major changes. Choose periods that match the site’s publishing and operational needs.

Before a WordPress update or major change

1. Run a fresh full backup immediately before updating WordPress, a plugin, a theme, or server components.
2. Confirm that the database export is readable and that the files archive contains the current uploads and active code.
3. Write down the planned changes and the intended rollback point.
4. Update in a controlled order, then check the front end, administrator area, forms, checkout or membership functions, and important integrations.
5. If the change causes a problem, avoid repeatedly applying random fixes. Preserve logs, compare the change with the last known-good state, and restore only after identifying the appropriate recovery point.

Before migrating to new hosting

Create a migration package containing the database, all required files, domain and DNS notes, SSL details, scheduled tasks, email dependencies, and a list of integrations. Lowering DNS time-to-live may help coordinate a planned change, but it does not replace a backup or guarantee immediate propagation. For a detailed workflow, see How to Migrate WordPress to New Hosting Without Losing SEO or Data.

Keep the original hosting account available until the new site has been tested and traffic is reaching the intended environment. Record the old and new database credentials separately, and remove temporary migration files after the cutover.

Emergency recovery

1. Identify the symptom and approximate time it began. A blank page, redirect loop, missing media, database error, and unauthorized change may require different recovery points.
2. Restrict unnecessary access and preserve relevant access, web-server, PHP, and WordPress logs.
3. Put the site into maintenance mode only if doing so prevents additional data changes or protects visitors.
4. Choose a clean recovery environment or staging site when possible. Do not overwrite the only copy of the current site before preserving it.
5. Restore files and database data as a coordinated set, then test URLs, media, login, forms, transactions, and integrations.
6. After recovery, rotate exposed passwords, API keys, salts, and other credentials where compromise is possible.

What to double-check

Database completeness: Confirm that all tables were exported, including tables created by plugins. If a tool offers options for routines, views, character sets, or compression, record the settings used and test a sample import.

Uploads and generated files: The media library is usually stored under wp-content/uploads, but plugins may use additional directories. Check custom upload paths, downloadable products, and files generated outside the standard WordPress structure.

Configuration and secrets: Review wp-config.php, environment variables, web-server rules, PHP settings, cron jobs, and deployment files. Store sensitive material with restricted access rather than in an unsecured shared folder.

Domain and URL behavior: After a restore or migration, verify the site URL, home URL, canonical behavior, redirects, HTTPS, mixed-content issues, and serialized data. Avoid broad search-and-replace operations on a live database unless the tool understands serialized WordPress data.

Recovery testing: A backup is unproven until it has been restored. Schedule a test on staging or an isolated environment. Measure how long it takes to obtain the archive, import the database, copy files, configure the site, and complete functional checks. This provides a realistic recovery time estimate without treating it as a guarantee.

Monitoring after restoration: Watch error logs, uptime checks, application alerts, search visibility signals, and important user journeys. The Website Uptime Monitoring Guide can help organize alert thresholds and incident follow-up.

Common mistakes

• Backing up only the database: This leaves themes, plugins, images, and custom code behind.
• Keeping every copy on one server: A server-level failure or compromised account can affect all local copies.
• Trusting a success email without verification: Check archive size, timestamps, logs, and—periodically—a real restore.
• Using an old backup after publishing new content: Record the recovery point clearly and understand what data will be lost.
• Restoring directly over a damaged site: Preserve the current state first when investigation or forensics may matter.
• Ignoring scheduled jobs: WordPress tasks, server cron entries, queues, and external automation may need to be recreated after migration.
• Leaving temporary archives exposed: Remove migration dumps and test files from public directories, and restrict access to retained backups.
• Failing to document ownership: Make sure more than one authorized person knows where backups are stored and how restoration works.

When to revisit

Review this WordPress backup and restore checklist before seasonal planning cycles, major redesigns, plugin or theme changes, hosting migrations, domain changes, and high-volume publishing periods. Revisit it whenever your hosting dashboard, backup plugin, deployment pipeline, database process, or storage provider changes.

At minimum, set a recurring review for three actions: confirm that scheduled backups are still running, verify that off-site copies can be retrieved, and complete a test restore. Update the recovery document when paths, credentials, responsible owners, integrations, or infrastructure change. If the site handles orders, registrations, bookings, or other frequent transactions, choose backup timing and retention around the cost of losing recent data rather than around convenience.

Use this final action list before your next maintenance window:

1. Create a fresh full backup of files and database.
2. Verify the archive and copy it to protected off-site storage.
3. Record the recovery point, site version, and restoration steps.
4. Test the change on staging when practical.
5. Afterward, inspect the site and monitoring alerts.
6. Schedule a restore test before the process becomes urgent.

For related infrastructure planning, review the Technical SEO Hosting Checklist and the Website Migration Checklist.