Most people think of a restore as one button. Something breaks, you pick last night's backup, you press restore, and the site goes back to how it was. That works often enough that nobody questions it. But every restore is a trade. You get back the thing that broke, and you give up everything that changed after the backup was taken. Orders, comments, new users, edits someone made this morning, a plugin setting your developer changed yesterday afternoon. All of it goes.

The size of that trade is decided by one choice that most site owners never make on purpose: the scope of the restore. Do you put back one row, one page, one file, one folder, the database, or the whole site? This article is about making that choice deliberately. It covers how to read the damage, the two ways a restore goes wrong, a ladder of restore sizes from smallest to largest, and the version-drift trap that catches people doing partial restores.

What does "restore scope" actually mean?
A WordPress site is not one thing. It is a set of parts that depend on each other, and each part can be put back on its own if your backup is stored in a usable format. Roughly, from smallest to largest:
A single database row, such as one option in wp_options or one post.
A single page or post, which in practice means its row in wp_posts plus its rows in wp_postmeta and any term relationships.
A single file, such as a theme template or .htaccess.
One plugin or theme directory.
The uploads folder, or one year or month inside it.
One or more database tables.
The whole database.
The whole site: all files plus the whole database.
A rebuild on a clean server, with content poured back in.
Scope is simply where on that list you choose to stop. Small scope protects the data you want to keep. Large scope gives you more certainty that the problem is gone. The skill is choosing the smallest scope that still fixes the real problem.

Is it damage or an intrusion? Answer this before anything else
One question overrides everything else in this article. Is the site broken, or has someone got into it? A bad plugin update, a deleted page or a corrupted table is damage. An unknown admin account, spam pages you never wrote, redirects that only fire for visitors coming from Google, or PHP files sitting in the uploads folder point to an intrusion.
If anything points to an intrusion, partial restores are off the table. You cannot surgically put back one page on a site where an attacker may have left a backdoor somewhere else, because the backdoor will still be there after your neat little restore. The right move is a full wipe and a restore from a copy taken before the compromise began, done with official core and plugin downloads rather than trusted backup code. BackupYourSite has a step-by-step guide on how to restore a hacked WordPress site from a clean backup that walks through containment, credential rotation, wiping and the Google review afterwards. One point from it is worth repeating here because it is the whole reason scope matters in a hack: restoring files over an infected install leaves every file the attacker added in place, since a restore only replaces files that exist in both sets.
Everything below assumes you have ruled that out. If you are not sure, treat it as an intrusion. Being wrong in that direction costs you some lost data. Being wrong the other way costs you the site, again, a few days later.

The two ways a restore goes wrong
Restores fail in one of two directions, and they feel very different when they happen.

Over-restoring: fixing one thing and losing ten
This is the common one. A single page looks wrong, so someone restores the whole database from last night. The page comes back. So does last night's version of everything else. On a blog that might mean a few lost comments. On a store or a membership site it is worse, and it is quiet. Nothing shows an error. The orders placed this morning are simply not in the admin any more, the customer who registered at 9 a.m. cannot log in, and the password reset someone completed an hour ago has been undone.
The damage from over-restoring tends to surface days later, as support tickets, payment records that do not match any order, and people asking why their account vanished. By then the live data that would have fixed it has been overwritten by newer activity. It is the most expensive kind of mistake because it looks like success at the moment you make it.

Under-restoring: fixing the symptom and keeping the cause
The opposite mistake is restoring too little. You put back the page content, but the layout lived in postmeta you did not touch. You put back a plugin folder, but the plugin had already changed its database tables during the update that broke it. You put back the theme, but the real fault was a must-use plugin in wp-content/mu-plugins/ that never appears on the Plugins screen.
Under-restoring usually shows itself quickly, which makes it less dangerous than over-restoring. The page still looks wrong, or it looks right for an hour and then breaks again. The cost is time, and a growing temptation to "just restore everything", which takes you straight back to the first mistake.

Map the damage before you pick a scope
Ten minutes of mapping saves hours of restoring the wrong thing. You are trying to answer three questions.

When was the site last known to be good?
You need a time boundary. Not "yesterday-ish" but the latest moment you can say with some confidence that the thing now broken was working. Sources that help: the time of the last plugin or theme update, the last time someone saved the affected page, your uptime monitor's history, form submissions that arrived correctly, and the modification times of files in the affected directory. File times can be misleading after a migration or a bulk copy, so treat them as a hint, not proof.
The time boundary decides which backup you can use at all. A backup taken after the break is useless, however recent it is. A backup taken well before it will carry more loss with it. Pick the newest backup that is safely before the boundary.

What changed, and what changed it?
Narrow down the cause. A few places to look:
The page's revision history, for content changes.
The builder's own history panel, if the page was made with a page builder, since many builders keep their history separately from WordPress revisions.
An activity log plugin, if the site runs one.
The list of plugin versions now compared with what you expected. With WP-CLI, wp plugin list shows each plugin's status and version in one go.
The PHP error log, which often names the exact file and line that is failing.
Your host's access log, if a change happened at a time when nobody on your side was working.
The answer shapes scope directly. A content edit points at the database. A fatal error naming a theme file points at the filesystem. A plugin update can touch both.

What has been written since the backup?
This is the question people skip, and it is the one that decides how much a large restore will cost. Make a quick list of what the site has collected since the backup you are considering. New orders. New users. Comments. Form entries stored in the database. Media uploads. Settings changes. Edits to other pages. If the list is empty, a large restore is cheap and you can be generous with scope. If the list is long, every step up the ladder below has a real price, and you should work hard to stay low.

The scope ladder: start at the bottom
Work up from the smallest restore that could plausibly fix the problem. Only climb a rung when the one below has failed or clearly cannot reach the cause.

Rung 1: Undo it inside WordPress
Before you open a backup at all, check what WordPress already kept. A deleted page goes to the Trash first, and WordPress empties the Trash after 30 days by default (the EMPTY_TRASH_DAYS constant controls this, and some sites set it lower or turn the Trash off). Changed text can often be rolled back through revisions in the editor, unless the site limits them with WP_POST_REVISIONS. Page builders often have an undo history of their own.
This rung costs nothing. No other data is touched, nothing is overwritten, and it takes minutes. It also fixes a surprising share of "the site is broken" reports, because many of them turn out to be one page that someone edited.

Rung 2: One page or post from a backup
When revisions do not reach back far enough, or the page was permanently deleted, the next step is to pull just that page out of a database backup. This is where most people make the over-restoring mistake, because importing the whole database feels simpler than extracting one page from it.
The extraction is fiddly but well within reach. The safe pattern is to load the full database dump into a throwaway database, not the live one, and take out only the rows for that page's ID: its wp_posts row, its wp_postmeta rows, and any term relationships. Then you import those few rows into the live site. If you want the full method, including the mysqldump --replace flags and the postmeta cleanup step that stops old and new layout data mixing, BackupYourSite's walkthrough on restoring one page without a full rollback covers it, along with the no-SQL route through WordPress's own export and import tools.
Two things make this rung worth the effort. The page keeps its ID, so its URL, menu entries and internal links survive. And nothing else on the site moves, so the morning's orders and comments stay exactly where they are.

Rung 3: One file
If the editor shows the page correctly but the front end is blank, throws a fatal error or uses the wrong template, the database was probably never wrong. A file is. A theme template saved with a syntax error in the built-in editor, or a PHP file cut short by an interrupted upload, will break pages without changing a single row of content.
Here the right scope is one file. Open the files archive from your backup, take out that single template or include, and put it back over SFTP. Do not restore the database at all, since that would bring loss with no gain. Clear any page cache and PHP opcache afterwards, because a restored file can keep looking broken until the old compiled version is flushed.

Rung 4: One plugin or theme directory
When an update breaks something and you cannot pin it to one file, the next size up is the whole plugin or theme folder. In many cases you do not even need your backup for this. If the plugin is hosted on WordPress.org, you can usually install the previous version directly. WP-CLI accepts a version flag, for example wp plugin install some-plugin --version=1.2.3 --force.
Be careful with this rung. Plenty of plugins run database upgrade routines when they update, changing table structures or rewriting stored settings. Rolling the files back does not roll those changes back. That is the version-drift problem, covered in its own section below, and it is the main reason a folder-level rollback sometimes makes things worse.

Rung 5: The uploads folder, or part of it
Media problems are usually file problems. A careless sync, a cleanup plugin that removed "unused" images, or a migration that skipped a folder can leave posts full of broken images while the database is fine. WordPress organises uploads into year and month folders by default, which makes it possible to restore only the months that are affected instead of the whole folder.
Check the attachment records too. If the images were deleted through the Media Library, their attachment rows may be gone from the database as well, and putting the files back will not make them reappear in the library. In that case you need both the files and the matching rows.

Rung 6: One or a few database tables
Sometimes a single table is the problem: a table marked as crashed, a plugin's data table that a failed migration left half-written, or a settings table filled with junk by a misbehaving plugin. Restoring just that table from the backup leaves the rest of the database current.
The catch is that WordPress tables reference each other. Posts point to users, postmeta points to posts, comments point to posts, and term relationships tie posts to categories. Restore wp_posts on its own and you can end up with postmeta rows pointing at posts that no longer exist, or posts that lost their metadata. On WooCommerce sites, orders may live in the posts tables or, on newer installs using high-performance order storage, in their own dedicated order tables. Either way, restoring one table in a related group usually means restoring the whole group, and at that point you should be honest about whether you are really doing a full database restore in disguise.

Rung 7: The whole database
A full database restore makes sense when the damage is spread across many tables, or when a plugin update changed the database in ways you cannot unpick table by table. It is also the right call on a site where nothing important has been written since the backup, such as a brochure site with no forms storing data and no logins.
Before you do it, export what you are about to lose. At the very least, export any orders, users and form entries created since the backup, so they can be re-entered or reconciled afterwards. And restore over a copy of the live database you have just taken, not over the only copy, so you can go back if the restore turns out to be the wrong move.

Rung 8: The whole site
Files plus database, together, from the same moment. This is the right scope when the damage touches both, when you cannot work out what changed, or when the site will not load at all and you need a known-good starting point quickly. Restoring files and database from the same backup also avoids a subtle mismatch, where the files come from one day and the database from another.
Restore into a staging copy first if you can, check it, and then promote it. And remember that a full restore over the top of an existing install only replaces files that exist in the backup. Files added since then, including any you did not expect, stay behind unless you clear the directory first.

Rung 9: Rebuild on clean ground
The top of the ladder is not a restore at all. It is a fresh server or a fresh hosting account, official WordPress core, fresh plugin and theme downloads, and only your own content and uploads carried over from the backup. This is the scope for a confirmed compromise, for a site whose host account is suspended or unreachable, or for a site that has been patched and patched until nobody trusts it any more.

Version drift: the quiet trap in partial restores
Partial restores assume the pieces still fit together. Often they do not, because the site kept moving after the backup was taken.
WordPress core records its database version in the db_version option in wp_options, and many plugins store their own schema version in a similar way. When core or a plugin updates, it compares the stored version with its own and runs whatever upgrade steps are needed. That is fine going forward. Going backwards is where it bites.

Three combinations to watch for:
Old files, new database. You roll a plugin's files back to last week but keep today's database. The plugin's tables may already be in a newer format the old code does not understand. Symptoms range from missing data to fatal errors.
New files, old database. You restore an older database under current plugin files. The plugins see an old schema version and run their upgrade routines again. Usually this is harmless. Occasionally it rewrites data in ways you did not expect.
Mixed-date pieces. Files from Monday, a table from Wednesday, the rest from today. Each piece is internally fine and the combination has never existed before, so nobody has ever tested it.
The practical rule is simple. When you restore a plugin's files, ask whether its update changed the database. If it did, either restore the plugin's tables and settings from the same backup, or accept that you need a larger scope. And when in doubt, test the combination on a staging copy before it goes anywhere near the live site.

Five common situations, and the scope each one needs
These are typical patterns rather than case histories, but most real restore requests look like one of them.
What happened Smallest scope that fixes it What to watch for
An editor rewrote a page and the old version is wanted back Revisions, or a single-page restore if revisions are capped The builder layout may live in postmeta, not in the revision
A plugin update broke the layout on several pages The previous plugin version, then the plugin's tables if needed Database upgrade routines that already ran
Images disappeared after a cleanup tool ran The affected upload months, plus attachment rows if they were deleted Image sizes generated after the backup
A table is marked as crashed A repair first, then that table and its related tables from backup Rows that point at other tables
Spam pages and an unknown admin user appeared A full wipe and clean restore, or a rebuild Backdoors outside the WordPress folder

Notice how only the last row demands the top of the ladder. Most problems that feel like a full-restore emergency at first are really rung two to five problems.

Set up your backups so small restores are possible
You can only climb down the ladder if your backups let you. A few things decide that, and they are all much easier to arrange before you need them.

Plain formats you can open without the tool
A backup stored as an ordinary SQL dump and an ordinary file archive can be opened with standard tools on any machine. You can load the dump into a spare database, pull one file out of the archive, or grep for a table. A backup wrapped in a proprietary package often has to be restored whole through the tool that made it, which forces you towards a larger scope than you wanted. Check what your backups actually look like when you download one.

Files and database kept separate
When the database dump and the file archive are separate pieces, you can restore one without the other. That alone covers rungs three to seven. A single combined archive is fine as long as you can extract the parts; it becomes a problem only when the tool insists on restoring everything at once.

Enough history to reach past the problem
Some problems are found weeks after they start. If your retention only keeps a handful of recent copies, the newest backup safely before the break may already have rolled off. Longer retention gives you more choice of restore point, which matters most for slow problems like gradual data corruption or a compromise that sat unnoticed.

Copies stored away from the site
A backup sitting in the same hosting account as the site shares its fate. If the account is suspended, the server fails or an attacker deletes local archives, those backups go too. An offsite copy is what keeps every rung of the ladder available on the bad day.

A place to practise
Every rung above the first is easier on a staging copy. Loading a dump into a throwaway database, testing an older plugin version, checking a restored page before it goes live: all of these need a safe space. If you do not have one, a local install or a temporary subdomain will do.

Notes you can find in a hurry
Write down the site's table prefix, where backups are stored, how to log in to that storage, and how to reach the database. Small restores need small details, and those details are hard to find under pressure.

A short checklist before any restore
1.Rule out an intrusion. If there is any sign of one, stop here and do a full clean restore instead.
2.Set the time boundary: the last moment you know the broken thing was working.
3.Identify what changed and whether it lives in files, the database, or both.
4.List what has been written since the backup you plan to use.
5.Take a copy of the current live state, even though it is broken.
6.Pick the lowest rung on the ladder that reaches the cause.
7.Check for version drift if you are restoring plugin or theme files on their own.
8.Test on staging when the scope is a table or larger.
9.After the restore, clear every cache layer and check the result as a logged-out visitor.
10.Write down what you restored, from which backup, and why. The next person will thank you.

Conclusion
A restore is not an undo button. It is a decision about how much of the present you are willing to give up to get a piece of the past back. When that decision is made by default, it is nearly always made too large, and the cost shows up later as missing orders and confused users.
The fix is not complicated. Rule out an intrusion first, because that is the one case where large scope is mandatory. Then map the damage, start at the bottom of the ladder, and climb only when you have to. Keep your backups in formats you can take apart, stored somewhere the site's problems cannot reach, with enough history to get behind slow problems. Do that, and most of your restores will be small, quiet and over in minutes, which is exactly how a restore should feel.