Most writing about restoring backups assumes a calm afternoon. You are probably not having one. The site is down, you have a backup, and the question is whether restoring it is the right move at all.
That question comes first, because a restore is not a neutral action. It overwrites. Done in the wrong order, or for the wrong reason, it turns one problem into two.
Decide before you act: is a restore the right move?
Restore when the site is broken in a way you cannot identify, when the damage is to files or the database rather than a single setting, when the site has been compromised, or when you have already tried the obvious things and the outage is costing more than the lost content will.
Do not restore when you have not yet spent five minutes on diagnosis, when the fault is plainly a plugin you could deactivate, when your backup is untested, or when you do not know what will be lost.
The most common regret is restoring immediately over a problem that a single deactivation would have fixed, and losing a week of orders in the process. If an update caused it, our walkthrough of the critical error after an update covers the quick checks that are worth doing first.
Know what you will lose, in a sentence
A restore returns the site to the moment the backup was taken. Everything since then is gone unless you save it first.
Say out loud what that means for your site. Since the backup ran, have there been orders, form submissions, comments, new posts, user registrations, uploaded images? On many sites the honest answer is nothing important. On a shop, it is never nothing.
If anything happened that you cannot lose, capture it before you restore. Export the orders. Screenshot the form entries. Download the images uploaded since. Ten minutes here prevents the specific disaster where the fix destroys the thing the site exists for.
Take a backup of the broken site
This is the step people skip because it feels absurd. Back up a site that does not work?
Yes. It costs a few minutes and it is your undo button. If the restore goes badly, or restores the wrong point in time, or turns out to have restored the same fault, the broken-but-known state is somewhere you can return to. It also preserves the evidence, which matters if the site was hacked and you want to understand how.
If the site is too broken for the backup plugin to run, copy the database and the wp-content folder manually from your host's control panel. That is enough to reconstruct.
Put up a holding page, if you can
If visitors are arriving, a plain maintenance page is kinder than a broken one and buys you unhurried time. If you cannot reach the admin to switch one on, ask your host. Many can serve a static page in a minute.
This also protects the restore itself. A shop taking orders during a restore produces orders that exist in the payment processor and not in the site.
The restore, in order
The specifics depend on your tool, and the sequence does not.
One: know which backup you are restoring. Check the date, and check it is a successful run rather than an attempted one. Restoring the most recent backup is the reflex; restoring the most recent good backup is the correct move. If the fault has been present for a few days without you noticing, the newest backup contains it.
Two: restore files and database together. Restoring only files leaves you with old code and a newer database, which produces confusing half-broken behavior. Restoring only the database has the mirror problem. Unless you have a specific reason to do one, do both, from the same point in time.
Three: leave wp-config.php alone unless you must. It holds the database credentials for where the site lives now. If you are restoring onto the same host, the current file is correct and an old one may not be. Many restore tools handle this for you; if you are doing it by hand, this is the file to be careful with.
Four: let it finish. A restore on a large site takes time and interrupting it halfway leaves the site in a state that is neither the old one nor the new one. This is the point where knowing how long a restore takes, from having practiced one, pays for the practice.
After it finishes: check, do not glance
The home page loading is not proof. Check the same five things you would check when testing a backup.
- A recent post opens with its content intact.
- Images load rather than showing as broken.
- You can log in normally.
- The permalink structure works: open a post by its URL, not by clicking through.
- Plugin data is present, not just plugin code. Form entries, orders, settings.
If permalinks return 404 errors after a restore, that is a common and usually harmless symptom. Visiting the permalinks settings screen and saving without changing anything regenerates the rules.
Then clear every cache: the caching plugin, the host cache, the CDN, and your own browser. A cache serving pages captured during the outage is the reason a successful restore sometimes looks like a failed one.
Then ask why, because you have not fixed anything yet
A restore returns you to a working state. It does not remove the cause. If a plugin update broke the site and you restore, you now have the old plugin version back and the same update waiting to be applied again.
Before you resume normal use, work out what happened, and write it down. If it was an update, do not simply reapply it. If it was a compromise, restoring alone does not close whatever let the attacker in, and the same restore will be needed again shortly.
If the restore fails
Stop. Do not immediately try a different backup on top of a half-restored site, because layering restores produces states nobody can reason about.
You have the broken-site backup you took at the start. Put the site back to that known state, then get help with a clear description: what was broken, which backup you tried, and how far the restore got. That is a solvable situation. A site that has had three partial restores applied to it is a much harder one.
Version context. Written against WordPress 7.1, released 2026-08-19, the current major release on our record. Nothing here is version-specific. Release dates come from our own dated record of the WordPress.org release page, last read 2026-08-19. No backup or restore product is named or recommended on this page, deliberately.
