How to back up your WordPress site before any theme change

01Why a backup is non-negotiable before a theme change

Installing a theme is harmless. Activating it is not. Activation swaps your entire front end in a single click — templates, menus, widgets, and theme settings all change at once. Most of the time it goes fine. The times it doesn't, you want a way back that takes minutes, not a panicked afternoon of rebuilding from memory.

A backup is that way back. With a known-good copy from five minutes ago, a broken theme switch becomes a non-event: you restore, the site looks exactly like it did before, and you try again more carefully. Without one, you're debugging live while visitors watch.

Theme changes are riskier than they look because so much hides in the database. A new theme can drop widgets the old one held, lose menu assignments, or clash with a plugin and trigger a white screen. None of that is visible until you activate — which is exactly why the safety net goes up first.

02What a full backup actually includes

The single most common backup mistake is thinking a copy of your files is a backup of your site. It isn't. WordPress stores your content, settings, menus, and theme options in a database — and a folder of files won't restore any of it.

A complete WordPress backup has two halves, and you need both to restore cleanly:

• The database — every post, page, comment, user, menu, widget setting, and theme option lives here, in a set of MySQL tables. This is the half people forget, and it's the half that holds your actual content.
• The files — your wp-content folder is the important part: uploads (every image and media file you've added), themes (the theme folders themselves), and plugins. The WordPress core files and wp-config.php round it out.

Think of it this way: the database is the words and the structure, the uploads folder is the pictures, and the themes/plugins folders are the machinery. Restore only one and you get a site that's missing something — broken images, vanished content, or a theme that won't load.

For a theme change specifically, the database matters most, because that's where your new theme's settings and your old theme's leftovers live. But always back up both — a half-backup is the kind you discover the limits of at the worst possible moment.

03The ways to back up your site

There are three realistic ways to capture a backup. They differ in effort and control, not in what they protect — any of them, done fully, gets you a restorable copy. Pick by what you already have.

1. Your host's built-in backups

Most decent hosts back up your site for you, and this is the lowest-effort option. Hostinger, for example, includes automatic weekly backups on its shared plans (daily on higher tiers), and you can trigger and restore them from the control panel. Cloudways takes automated server backups on a schedule you set and lets you restore from the dashboard, plus an on-demand backup button you can hit right before a risky change.

Honest caveat: a weekly automatic backup might be days old when you sit down to switch themes. Before any theme change, trigger a fresh on-demand backup if your host offers one — don't rely on the last scheduled run to be recent enough.

2. A backup plugin

A plugin like UpdraftPlus, Solid Backups, or Duplicator runs the backup from inside WordPress and can push the copy to remote storage (Google Drive, Dropbox, S3) automatically. The big advantage is the matching one-click restore — the same plugin that made the backup can put it back, database and files together, without you touching a database tool.

This is the best route for most people who don't want to live at the host control panel. Set it to back up both files and database, point it at off-site storage, and you've covered the two things that matter at once.

3. Manual backup (files + database export)

The manual method has two steps. Download your files over FTP/SFTP (at minimum the wp-content folder), then export the database from phpMyAdmin — open phpMyAdmin in your host panel, select your site's database, choose Export, and save the .sql file.

It's more work and easier to get half-right, but it's fully under your control and depends on no plugin. Just remember both steps: people routinely download the files, skip the database export, and end up with a backup that can't restore their content.

04Where to store the backup

A backup that lives only on the same server as your site is barely a backup. If the server fails, the account is suspended, or a bad actor gets in, your site and its only safety copy go down together. The fix is an idea worth keeping simple: get a copy off the server.

The classic version of this is the 3-2-1 rule, and you can apply a plain-English version of it without overthinking:

• 3 copies — your live site counts as one; keep at least two more backup copies.
• 2 different places — don't keep both backups in the same spot. Host storage plus cloud storage, for instance.
• 1 off-site — at least one copy somewhere completely separate from your hosting: Google Drive, Dropbox, S3, or your own computer.

For a single theme change, the practical minimum is one fresh copy somewhere that isn't your web server. Download the backup to your laptop, or let your plugin push it to cloud storage. That one off-server copy is what turns "the host had a bad day" from a catastrophe into an inconvenience.

05Test that the backup actually restores

This is the step almost everyone skips, and it's the one that decides whether your backup is real. A backup you've never restored is a guess. Plenty of people discover the hard way that their nightly backup was silently failing, or only ever saved the files and not the database — and they find out at the exact moment they need it.

You don't need to test every backup, but you do need to confirm the method works once, on purpose, before you depend on it. The clean way to do that is a staging site — a private clone of your site you can break freely.

• Spin up a staging environment (many hosts, including Hostinger and Cloudways, offer one from the dashboard).
• Restore your backup into it using the same method you'd use in an emergency — the plugin's restore button, the host's restore tool, or a manual files-and-database import.
• Load the restored staging site and click around: check the homepage, a few inner pages, images, menus, and that you can log in to the admin.

If the staging copy comes back looking like your real site, your backup and your restore process both work — that's the thing you actually wanted to know. If it doesn't, you've found the gap on a throwaway copy instead of during a live emergency, which is the entire point of testing.

06Restoring if the theme change goes wrong

If you switched themes and the site is broken, don't start frantically editing. You have a backup; the fastest path is usually to restore it, get back to a working site, and then retry the theme change more carefully. Match the restore method to how you backed up.

• Plugin backup — use the same plugin's restore button. It puts the database and files back together. If you can't reach wp-admin at all, some plugins offer an independent restore tool you can run without logging in.
• Host backup — open the host control panel and restore the snapshot you took before the change. With Hostinger or Cloudways this is a dashboard action, which is exactly why a pre-change on-demand backup is worth the thirty seconds it costs.
• Manual backup — re-upload the wp-content folder over FTP and re-import the .sql file through phpMyAdmin (drop the existing tables first, then import).

If the only problem is a white screen from the new theme and you can't log in, there's a quick rescue that needs no backup at all: rename the new theme's folder in wp-content/themes/ over FTP. WordPress can't find it, falls back to a default theme, and lets you back into the admin. Then restore properly or pick a different theme.

Whatever route you take, once the site is healthy again, take a fresh backup of that good state before you try the theme switch a second time.

07Automating backups going forward

Backing up by hand before a theme change is good. Backing up automatically all the time is better, because the risky moments you don't plan for — a bad plugin update, a hack, a fat-fingered edit — are the ones a manual habit misses.

Set up a schedule that runs without you. A backup plugin can capture both files and database on a daily or weekly cadence and ship each copy to off-site storage automatically. Most quality hosts also run their own scheduled backups — Hostinger's weekly/daily and Cloudways' configurable server backups both qualify — and the two together give you a belt-and-suspenders setup.

• Match the frequency to how often the site changes — a busy blog wants daily; a static brochure site can live with weekly.
• Always include the database, not just files. This is the setting people miss.
• Send copies off-site automatically so you're never relying on the server that holds the live site.
• Set a retention window (keep, say, the last 14 or 30 days) so one bad backup doesn't overwrite all your good ones.

Even with automation running, still take a manual on-demand backup right before a theme switch. It's cheap insurance, and it guarantees your rollback point is from minutes ago rather than whenever the last scheduled run happened to fire.

08FAQ

Do I really need a backup if I'm just trying out a theme?

On a brand-new site with no real content, the stakes are low — back up anyway out of habit, but a bad switch costs you little. On a live site that people visit, yes: trying a theme means activating it, and activating it is the moment things can break. Back up first, every time.

Is my host's backup enough on its own?

It's a solid foundation, but check two things. First, how recent it is — a weekly backup could be days old, so trigger a fresh one before a theme change. Second, whether you can actually restore from it; test that once so you're not finding out during an emergency.

Database or files — which matters more for a theme change?

The database, because your theme settings, menus, and widget assignments live there. But always back up both. Files alone can't restore your content, and a database alone can't restore your images or theme folders. A real backup is the pair.

How long does a backup take?

For a typical small site, a few minutes. A host's on-demand backup or a plugin run usually finishes quickly; a large media library takes longer. Either way it's far less time than rebuilding a broken site, which is the comparison that matters.

Where should I keep the backup file?

Somewhere that isn't your web server. Download it to your computer or push it to cloud storage like Google Drive, Dropbox, or S3. A backup stored only on the same server as the site disappears alongside the site if the server has a bad day.

One last note: this is an honest how-to, not financial or business advice. Your setup may differ, so test your backup and restore on a copy before you trust either in production.