You pasted a new services section into the top of your homepage, clicked Update, and watched the page rearrange itself into something you didn’t intend. Maybe the hero heading vanished. Maybe the old intro copy is now sitting underneath a block of text that belongs somewhere else. Maybe you refreshed the live site and felt your stomach drop.
Take a breath. This looks worse than it is. The first thing to do is stop editing. Do not click Update again, do not try to fix it by pasting the old text back in from memory, and do not start changing theme settings to see if that helps. Every one of those moves creates another saved version on top of the one you want back.
WordPress keeps a record of each saved draft or published update, and the Revisions panel is the tool that lets you walk backward through those records and restore one. It is a content-level undo. It is not a site-level undo, and knowing the difference is what keeps this from turning into a much longer afternoon.
What the Revisions panel actually stores
The WordPress revisions system stores a record of each saved draft or published update, according to the WordPress.org Revisions documentation. By default, WordPress keeps track of changes to the title, author, content, and excerpt of a post or page. That is the boundary you need to hold in your head: revisions cover the words and blocks inside the page, not the design of the site around it.
Autosaves are part of this system too, but they behave differently from a normal save. The documentation notes that autosaves are enabled for all posts and pages but do not overwrite published content; they are stored as a special type of revision. In the revisions timeline, autosaves are marked with an Autosave label. If your browser crashed or your connection dropped mid-edit, WordPress may offer you a recovery link when you reopen the page. That is the autosave doing its job, and it is separate from the published revision history you are about to use.
Step one: open the page and find the Revisions number
Go to Pages in wp-admin and open the homepage you just broke. You are not going to edit anything yet. You are just going to look.
Open the Settings sidebar in the editor. Select the Page or Post tab. You will see a line labeled Revisions with a number next to it. Click that number.
That number is your first diagnostic. If it is there and greater than zero, you have history to work with. If the number is missing or zero, revisions may be disabled or limited on this site, and the recovery path shifts to a backup rather than the editor. That is a different problem, and I will come back to it.
Step two: read the comparison screen before you click anything
Since WordPress 7.0, clicking the revisions number opens a new revisions screen. If you are on WordPress 6.9 or earlier, you will see the classic revisions screen instead. Both do the same job; the layout is different.
On the newer screen, the Revision panel lists saved versions. You can select one from the list or use the slider at the top of the screen to move forward and backward through them. As you move, the display shows what changed: what was added, what remained unchanged, and what was removed. Lines added or removed are highlighted, and individual character changes get additional highlighting.
The color markers next to the scrollbar tell you what kind of change you are looking at. Added blocks are solid green. Removed blocks are red with forward-slanting diagonal stripes. Modified blocks are yellow with backward-slanting diagonal stripes. Click a marker to jump to that location. The Show changes icon on the left side of the slider toggles the colored highlights on and off, which is useful when the highlighting itself is making it hard to read the page.
Here is a hypothetical example of what that looks like in practice. You pasted a new services section over the top half of the homepage and updated. In the revisions screen, the blocks you displaced show up as red striped markers and the new section shows up as solid green. You slide back one revision, confirm the old hero and intro copy are intact, and stop there. You have found your target. Do not click Restore yet if you are unsure — slide forward and back a few times until you are certain which version is the good one.
Step three: restore the revision
Once you have the right version on screen, click Restore. That is the documented action: use the top slider to find the revision you want to restore, then click Restore.
Before you click, know what you are doing. You are telling WordPress to bring that version’s content back into the page. The documentation describes the restore action but does not state that the bad revision is deleted, so do not assume either way. What you can rely on is that the revision history is a list of saved versions, and restoring one is how you move the page’s content back to a version you trust.
After the restore, look at the page. Check the front end, not just the editor preview. If it looks right, you are done with the recovery. If it still looks wrong, go back into Revisions and try a different version. You are not making things worse by looking; you are only making things worse by saving over the history again.
If you are on the classic revisions screen
On WordPress 6.9 and earlier, clicking the revisions number opens the classic screen. It shows a side-by-side comparison of the HTML version of the content. You can drag the slider or use the Next and Previous buttons to move through versions. The classic screen also includes a Compare any two revisions mode, which gives the slider two handles — one for the revision you are comparing from and one for the revision you are comparing to — so you can see the changes between any two specific versions.
If you are on WordPress 7.0 or later and prefer the classic view, the documentation notes you can open it by clicking Open classic revisions screen in the sidebar. Neither screen is ranked above the other in the documentation; use whichever one you can read comfortably.
What Revisions will not fix
This is the part that saves you from wasting an hour on the wrong tool. The Revisions panel tracks title, author, content, and excerpt. It does not restore menus, widgets, theme settings, plugin settings, or files. If your homepage content is intact but the site’s typography, header layout, or navigation changed, you are looking at a different kind of problem.
For style changes, some sites offer a separate style revisions feature. The WordPress.com documentation describes restoring previous versions of styles through Appearance → Editor → Revisions, and notes that resetting styles resets typography, colors, and layout only — not content or site settings. That page is WordPress.com documentation, not WordPress.org documentation, so do not assume the same menu path exists on a self-hosted site. Check what your own site offers before you go looking for it.
If the damage is in menus, widgets, plugin settings, or theme files, the Revisions panel is the wrong tool. Your recovery path is a backup. That is a bigger move, and it is worth understanding what a backup actually contains before you reach for one.
Take a backup before and after the restore
The WordPress.org backup documentation is direct about this: there are two parts to backing up your WordPress site, the database and the files, and you need both to fully restore a typical WordPress site. The database contains your posts and a lot of data generated on your site, but it does not include core files, plugins, themes, and uploaded files.
Revisions live in the database. They are stored in the posts table as children of their associated post, according to the revisions documentation. That means a database-only restore is not the same thing as restoring a page revision, and a file-only restore will not bring your homepage copy back. If you are going to use a host backup as your fallback, confirm that it covers both parts.
The documentation also notes that most hosts back up the entire server, including your site, but it takes time to request a copy of your site from their backups. So a host backup is a real fallback, not an instant one. Do not treat it as a guarantee that is fast or available on every plan; check what your host actually provides.
The order I recommend is: stop editing, open Revisions, compare, restore, then take a backup of the now-good state. Restoring first and backing up second is acceptable here because the revision history itself is not removed by the restore action per the documentation’s description, but the documentation does not confirm what happens to the bad revision, so verify your history remains intact before relying on it. The backup protects you from the next mistake, not this one.
If the Revisions number is missing or zero
A missing or zero Revisions number is a diagnostic signal, not a dead end. It suggests revisions are disabled or limited on this site. The revisions documentation describes a setting in wp-config.php — define( 'WP_POST_REVISIONS', 3 ); — that limits how many revisions WordPress stores, and notes that old revisions are automatically deleted when the post is updated again. It also notes that revisions can be turned off entirely.
You do not need to edit wp-config.php yourself to act on this. What you need to know is that the editor is not going to be your recovery path on this page. Your fallback is a backup: a host-level restore, or a backup plugin your site already runs. If you are not sure which one you have, that is the question to answer before the next edit, not during this one.
A short habit checklist for next time
None of this is complicated, but it is easy to skip when you are in a hurry. The habits that prevent this situation are small.
- Before a large edit to a page you care about, save a draft first. That draft becomes a revision you can return to.
- Keep a recent full backup — database and files — and confirm it is actually running. The backup documentation recommends backing up regularly and always before an upgrade, and suggests keeping at least three to five recent backups with copies in different locations.
- Do not edit the live homepage in a rush. If you have a way to preview changes before publishing, use it.
- When something goes wrong, stop editing before you do anything else. The revision history is only useful if you have not buried the good version under five more saves.
You overwrote half your homepage. The Revisions panel is the first tool to try, and for content changes it is usually enough. If it is not, you now know why, and you know which tool to reach for instead.
FAQ
Does restoring a revision delete the bad version?
The WordPress.org documentation describes the Restore action but does not state that the bad revision is removed. Do not assume either way. What you can rely on is that the revision history is a list of saved versions and restoring one brings that version’s content back.
Why is my Revisions number zero?
Revisions may be disabled or limited on your site. The documentation describes a wp-config.php setting that limits how many revisions are stored and notes that old revisions are automatically deleted when the post is updated again. If the number is zero, use a backup as your recovery path.
Will Revisions fix a change I made to my theme or menus?
No. Revisions track title, author, content, and excerpt. Theme settings, menus, widgets, plugin settings, and files are outside that scope. For those, use a backup or the relevant feature your site provides.
Do I need a backup if I have revisions?
Yes. Revisions are a content-level undo stored in the database. A full backup covers both the database and the files, and the WordPress.org backup documentation notes you need both to fully restore a typical WordPress site. The two layers do different jobs.