How to Back Up and Restore a WordPress Website: A Hosting Recovery Checklist

Overview

WordPress recovery depends on two different types of data. The database contains posts, pages, comments, settings, users, and much of the content created through the dashboard. The files include WordPress core files, themes, plugins, media uploads, and configuration files such as wp-config.php. A complete WordPress backup normally needs both.

Keeping only a database export may preserve written content but leave the site without its theme, plugins, or uploaded media. Keeping only a file archive may preserve the installation but omit recent posts and configuration changes. Treat the combination as the minimum useful recovery set.

Your hosting environment may provide backups through a control panel, managed WordPress service, server snapshot, or a WordPress backup plugin. These methods can complement one another, but they are not automatically interchangeable. Check what each method includes, where it stores the copy, how long it retains it, and whether you can download or restore it independently.

For a practical hosting backup strategy, aim for copies that are automated, separate from the live site, protected from unauthorized access, and tested periodically. A backup that has never been restored is an assumption, not a recovery plan.

Before changing hosting or rebuilding a site, also review the website hosting migration guide. Migration and disaster recovery overlap, but each requires its own checks for files, databases, DNS, SSL, and email.

Checklist by scenario

Routine WordPress backup

• Record the site name, domain, hosting account, WordPress version, PHP version, active theme, and important plugins.
• Save a full copy of the WordPress files, including the wp-content directory and its uploads, themes, and plugins.
• Export the WordPress database using the hosting control panel, database utility, or a trusted backup tool.
• Confirm that the backup completed rather than assuming that a scheduled task ran successfully.
• Store at least one copy outside the hosting account, such as secured local storage or a separate cloud storage location.
• Label the backup with the site, date, time, and whether it is a full backup, file backup, or database backup.

Keep credentials and backup files protected. A backup can contain customer information, administrator accounts, unpublished content, and configuration secrets. Limit access and avoid placing downloadable archives in a publicly accessible website directory.

Before a WordPress core, theme, or plugin update

• Run a fresh full backup immediately before the change.
• Check that the backup includes both the database and the current file set.
• Note which component you are updating and record its previous version where practical.
• Confirm that you can reach the hosting account, database tools, and backup storage if the dashboard becomes unavailable.
• Update one logical group at a time rather than changing many unrelated components without a checkpoint.
• Test the homepage, key landing pages, login, forms, search, checkout, and other functions after the update.

If an update causes a visible failure, first preserve evidence: note the error, time, changed component, and affected URLs. If the site remains accessible, disable or roll back the suspected change according to the tool's documented process. If not, restore from the last known-good copy.

After a hack or suspected compromise

• Do not immediately overwrite the affected site if you may need logs or forensic evidence.
• Contact your hosting provider or administrator and restrict access where possible.
• Change hosting, WordPress, database, FTP or SFTP, and email credentials from a clean device.
• Preserve a copy of the compromised environment for investigation, clearly marked as untrusted.
• Restore only from a backup created before the suspected compromise, not simply the newest available backup.
• Patch WordPress, themes, plugins, and server components before reconnecting the restored site to normal traffic.
• Review administrator accounts, scheduled tasks, redirects, injected code, and DNS changes after restoration.

A restore alone does not remove the cause of a compromise. For related checks, use the website security and performance maintenance checklist and verify that SSL remains correctly configured. The SSL certificates guide can help when HTTPS errors appear after a hosting change.

When the hosting account is unavailable

If you have an independent copy of the files and database, select a clean hosting environment and restore there rather than waiting indefinitely for the original account. Upload the files, create a database and user, import the database, update connection settings, and test the site before changing DNS. If the domain points elsewhere, review its A, CNAME, and nameserver records carefully; the DNS records guide provides a useful reference.

What to double-check

Backup completeness: Check that media uploads, custom themes, must-use plugins, server configuration files, and other application-specific directories are included. Some tools exclude files to reduce backup size.

Database compatibility: Confirm that the database export is readable and that the target server supports the required database engine and WordPress configuration. A successful file upload does not prove that the database can be imported.

Restore order: A common sequence is to create the target database and user, upload the files, import the database, verify wp-config.php, and then test the site. Exact steps vary by hosting platform, so follow its current documentation.

URLs and DNS: A restored copy may use the production domain, a temporary address, or a staging URL. Avoid careless search-and-replace operations, especially where serialized WordPress data is involved. Before changing DNS, confirm that the restored site works on the intended domain and that email records will not be disrupted.

SSL and permissions: Check HTTPS, redirects, file ownership, directory permissions, scheduled tasks, and writable upload directories. If the restored site is on a new host, certificates may need to be issued again. See the cPanel SSL setup walkthrough if that is your control panel.

Retention: Define how many daily, weekly, or monthly recovery points you need based on how often the site changes. A site that publishes every day may need more frequent backups than a rarely updated brochure site. Keep enough history to cover delayed discovery of accidental deletion or compromise.

Common mistakes

• Relying on one location: A backup stored only on the same hosting account may be lost with the live site or account.
• Backing up only before major updates: Recent content, orders, comments, and user changes can be lost between manual backups.
• Ignoring restore tests: Corrupt archives, missing credentials, incompatible server settings, and incomplete exports often appear only during recovery.
• Restoring over the live site first: When possible, restore to staging or a separate temporary location so you can inspect the result before switching traffic.
• Keeping every backup forever: Unmanaged retention increases storage use and the number of sensitive copies that require protection. Define a schedule and remove copies safely.
• Restoring infected files: The newest backup may contain malicious code. Choose a clean recovery point and update the software before going live.
• Forgetting non-WordPress services: Domain registration, DNS, email, SSL, analytics, payment services, and external integrations may require separate recovery records.

When to revisit

Review this checklist before major seasonal campaigns, redesigns, plugin or WordPress updates, hosting changes, domain transfers, and other high-impact maintenance. Revisit it whenever your hosting control panel, backup plugin, storage provider, or server stack changes. A tool update can alter schedules, included files, retention settings, or restore steps.

At least periodically, perform a controlled restore to a staging environment. Record how long it takes, which credentials are required, what failed, and who is responsible for approving the restored site. Update the recovery notes while the process is fresh.

Action checklist:

1. List every WordPress site and its backup method.
2. Verify that each method captures files and databases.
3. Download or inspect a recent backup and confirm its date.
4. Check that an independent copy exists outside the live hosting account.
5. Test one restore on staging or another isolated environment.
6. Document the restore sequence, access details, DNS plan, SSL steps, and post-restore tests.
7. Schedule the next review before the next major update or planning cycle.

This routine turns WordPress backup and restore from an emergency guess into a repeatable hosting recovery process.