WordPress Backup and Restore Checklist: What to Save Before You Break Something

Overview

A complete WordPress backup is not just one file or one export. In practice, you need enough data to rebuild the site as it actually runs: content, media, themes, plugins, configuration, and the environment details that connect the application to your hosting stack.

For most sites, that means backing up these layers:

• Database: posts, pages, settings, users, comments, WooCommerce orders, form entries, and much of the site configuration.
• wp-content directory: uploads, themes, plugins, and sometimes custom mu-plugins.
• Core configuration files: especially wp-config.php, plus any custom server or application files.
• Server and hosting settings: PHP version, caching rules, cron jobs, redirects, SSL details, staging notes, and deployment settings.
• DNS and domain notes: not part of WordPress itself, but often critical during a restore or migration.

If you only save the database, your content may return but your media, theme, and plugin code may not. If you only save files, your content and settings may be missing. If you rely only on a host snapshot, restoration can be slower or broader than you want, especially when you need to recover one site, one directory, or one database state.

A useful rule is simple: back up what you would need if your current host panel disappeared and you had to rebuild elsewhere.

Before you make any risky change, aim to have:

• One current full backup
• One backup stored off-server
• A quick way to identify which backup was taken before the change
• A basic restore plan you have reviewed before an emergency

If you are also planning a host move, keep this checklist alongside a broader website migration checklist. If performance work is the reason you are touching the site, it also helps to review WordPress speed and caching basics before changing multiple layers at once.

Checklist by scenario

Use the scenario that matches what you are about to do. The core idea stays the same, but the risk points change depending on whether you are updating, migrating, or repairing a broken site.

1. Before a routine WordPress update

This is the minimum safe checklist before updating core, plugins, or themes.

• Export a fresh copy of the database.
• Save the full wp-content directory, including uploads, active theme, child theme, plugins, and mu-plugins if present.
• Save wp-config.php and any custom files in the web root, such as .htaccess or custom redirect files.
• Write down the current versions of WordPress core, theme, and key plugins.
• Record PHP version and any unusual server settings.
• Take screenshots or notes of critical settings pages: permalink structure, reading settings, ecommerce settings, cache rules, and active integrations.
• Confirm where the backup is stored and that it is not only on the same server.
• Label the backup clearly, for example: site-name_before-plugin-updates_2026-06-11.

If the site is revenue-generating or high traffic, consider creating a staging copy first. Managed WordPress hosting often makes staging and rollback easier; if you are comparing that tradeoff, read what managed hosting typically includes.

2. Before changing themes or page builders

Design changes can affect templates, widgets, menus, CSS, image sizes, and plugin compatibility.

• Back up everything in the routine update checklist.
• Export any theme options or builder templates if your theme or builder offers it.
• Save any custom CSS, code snippets, header scripts, and tracking code.
• Document current menus, widget areas, homepage assignments, and template mappings.
• Take front-end screenshots of the homepage, key landing pages, archive pages, product pages, checkout, and contact forms.

The screenshots are not part of a technical restore, but they are extremely helpful when you need to confirm whether the recovered site is truly back to normal.

3. Before a plugin cleanup or troubleshooting session

Bulk deactivation, security cleanup, and conflict testing are common moments when a site gets accidentally broken.

• Back up the database right before you begin.
• Back up the full plugins directory.
• Export settings from security, SEO, backup, redirect, forms, and ecommerce plugins when possible.
• Record which plugins are active and their versions.
• If you use a firewall or cache layer at the host or CDN level, note that too.
• If malware cleanup is involved, keep a copy of the current state before changing files, even if the site is compromised. That copy may help with forensics or recovering content later.

4. Before migrating to a new host

A host move is where many partial backups are exposed as incomplete. Treat migration as both a backup event and an infrastructure event.

• Back up the database.
• Back up all website files, not just wp-content, in case there are custom root-level files.
• Save wp-config.php, .htaccess, Nginx notes if applicable, and any custom rewrite rules.
• Record the current PHP version, memory limits, cron setup, SSL behavior, and cache configuration.
• List any connected services: CDN, SMTP provider, external image storage, search service, payment gateway, and web application firewall.
• Save current DNS records or export your zone if your provider supports it.
• Note where email is hosted before changing DNS. This is a common failure point during migrations.
• Lower-risk teams also create a staging or temporary URL validation plan before switching traffic.

For deeper migration planning, pair this article with the host migration checklist, the DNS propagation guide, and the email DNS checklist.

5. Before editing DNS, SSL, or domain settings

These changes are adjacent to WordPress, but they often cause the outage that makes you think WordPress failed.

• Back up the site as usual.
• Export or copy current DNS records: A, AAAA, CNAME, MX, TXT, and any verification records.
• Document current nameservers and where DNS is actually hosted.
• Save any SSL certificate notes, redirect behavior, and mixed-content fixes already in place.
• Record canonical URL settings in WordPress and any hardcoded domain references.

If HTTPS work is involved, keep the SSL setup guide nearby so you can separate certificate issues from application issues.

6. Before restoring a hacked or broken site

When a site is already in trouble, do not rush straight into overwrite mode.

• Take a copy of the current broken state first.
• Identify the last known good backup and note its date.
• Confirm whether the issue is from WordPress code, database corruption, host outage, DNS, SSL, or third-party service failure.
• Check whether restoring files, restoring the database, or both is appropriate.
• Prepare a maintenance mode plan if you need to avoid customer actions during recovery.
• If ecommerce is involved, identify any data created after the backup, such as orders or submissions, so you know what may need manual reconciliation.

For WooCommerce sites, restoration has higher stakes because a backup may roll back inventory, orders, customer accounts, or checkout changes. Review your store setup and hosting tolerance for downtime using this WooCommerce hosting guide.

What to double-check

Having a backup is not the same as having a restorable backup. Before you trust it, verify the parts that usually fail silently.

Can you actually access the backup?

• Confirm the file is present.
• Confirm it opens or extracts without errors.
• Confirm the database export is readable and not obviously truncated.
• Confirm credentials or storage access are available to more than one trusted person if needed.

Is it current enough for the change you are making?

• Check timestamps on uploads and database exports.
• Make sure the backup was taken after the most recent content, orders, or configuration changes you care about.
• If the site changes throughout the day, note the expected data gap if a restore becomes necessary.

Is the backup complete?

• Make sure uploads are included, especially if the media library is large.
• Make sure premium themes or plugins installed manually are included.
• Make sure custom code outside the default WordPress structure is included.
• Make sure environment-specific settings are documented somewhere even if they are not in the archive itself.

Do you know how restoration would work on your host?

• Know whether your host offers file restore, database restore, full account restore, or snapshots.
• Know how long a restore usually takes and whether it overwrites existing data.
• Know whether you can restore to staging first for verification.

If you are still deciding on infrastructure, articles on shared vs VPS vs cloud hosting and small business hosting tradeoffs can help you evaluate what level of backup control you really need.

Have you tested recovery at least once?

The strongest backup habit is a periodic test restore. It does not need to be elaborate. Even a restore to a staging site or local environment can answer the question that matters: if production fails, can you get the site back with the assets and settings you expect?

Common mistakes

Most WordPress backup failures are not dramatic. They are small assumptions that only show up when restoration begins.

• Relying on one backup source: If your only copy lives on the same server, it may disappear with the server problem.
• Saving only the database: This misses uploads, themes, plugins, and custom files.
• Saving only files: This misses site content, settings, users, orders, and form entries stored in the database.
• Not labeling backups clearly: In an emergency, vague filenames slow down recovery and increase the risk of restoring the wrong version.
• Ignoring off-site storage: A backup should survive the loss of the primary hosting account.
• Not documenting environment details: PHP version, rewrite rules, cron jobs, object cache, and CDN settings can all matter after restore.
• Assuming host snapshots equal application backups: They may be broader, less frequent, or harder to restore selectively.
• Forgetting ecommerce or form data created after the backup: Restoring may solve the outage but introduce data reconciliation work.
• Changing too many things at once: If you update plugins, switch themes, move hosts, and change DNS together, rollback becomes harder to reason about.
• Never testing restoration: A backup strategy without restore testing is partly unverified.

If pricing is influencing whether you rely on host features, plugin-based backups, or a managed platform, it is worth comparing the long-term tradeoffs rather than only intro pricing. This web hosting pricing guide is a good companion read.

When to revisit

Your backup checklist should not stay static. Revisit it whenever the site, team, or hosting workflow changes.

At minimum, review your process in these situations:

• Before major WordPress core updates
• Before plugin audits or theme changes
• Before launching a redesign or new store feature
• Before seasonal traffic periods or campaigns
• Before changing hosts, domains, DNS, or SSL configuration
• After adding ecommerce, memberships, bookings, or forms that create valuable database data
• When switching backup plugins or moving to managed hosting
• After any incident where restoration was slower or messier than expected

A practical way to keep this evergreen is to maintain a short internal runbook with four items:

1. What we back up: database, files, configuration, and DNS notes.
2. Where it is stored: host snapshots, plugin backups, cloud storage, or another off-site location.
3. How we restore: step-by-step for staging and production.
4. Who verifies it: one owner responsible for periodic checks.

Before your next risky change, take ten minutes and run this final pre-flight:

• Create a fresh full backup.
• Store a copy off-server.
• Confirm the backup date and label.
• Note current plugin, theme, and PHP versions.
• Capture screenshots of critical pages.
• Document DNS, SSL, and email dependencies if infrastructure is involved.
• Know exactly which backup you will restore if the change fails.

That habit is usually the difference between a short maintenance window and a long night of reconstruction. WordPress does not need a complicated backup philosophy. It needs a complete backup, a clear restore path, and a checklist you will actually use every time.