How to Restore a Website to a Previous Version

To restore a website to a previous version, use the newest copy that still holds the version you want, in this order: the version history built into your platform (page revisions or site history), then backups made by a plugin or your hosting company, then a staging or version-control copy, and only when none of those exist, archived captures in the Wayback Machine. The first three can put the site back exactly as it was. An archive can only give you the public pages, which you then rebuild.

Before you press any restore button, decide how far back you need to go and what you are prepared to lose. A rollback replaces everything that changed after the backup point, including orders, comments, form entries and new posts. This guide walks through each route, how to choose between them, and how to roll back without damaging the live site.

First, decide what “previous version” means for you

People ask to turn back the clock for very different reasons, and the right method depends on which one applies:

• One page went wrong. Someone edited the homepage, deleted a section or published the wrong text. You only need that page back.
• An update broke the site. A theme, plugin or core update caused errors or a broken layout. You need the code back, not necessarily the content.
• A redesign was a mistake. The new design went live, and the business wants the old one back, sometimes weeks later.
• The site was hacked or overwritten. Files or content were changed by an attacker, a bad migration or a staging push.
• The site is gone. Hosting expired or the account was deleted, and the only thing left is the memory of how it looked.

Write down the date of the last good version, as precisely as you can. Every route below starts with that date.

Route 1: Use the version history your platform already keeps

Most site platforms keep some history automatically. It is the safest route because it restores the original content with its settings, links and formatting intact.

• WordPress revisions. WordPress saves a revision each time you update a post or page. Open the editor, find Revisions in the sidebar, compare versions side by side and restore the one you want. Revisions work per post or page, not for the whole site, and they do not cover theme or plugin settings. The WordPress revisions documentation explains the screen.
• Page builder history. Builders such as Elementor keep their own revision history for each page, which can undo layout changes that WordPress revisions do not show clearly.
• Hosted builders. Wix has Site History, which lists saved and published versions you can preview and restore. Other builders have similar tools with different limits, and some only keep page-level history. Our guide to Wix site history and archive rebuilds covers what to do when the version you need is older than the history goes.

If the version you want is in this history, you are done in a few minutes. If it is not, because the change happened too long ago or the history only covers single pages, move to backups.

Route 2: Restore a backup without overwriting new data

Backups are the usual way to restore a whole site. They come from three places: a backup plugin, your hosting control panel, or a managed host’s daily snapshots. Check all three, because they often have different retention periods and one may reach further back than the others.

The danger with backups is that they are all-or-nothing by default. Restoring last month’s full backup brings back last month’s design, and also last month’s database, which means every order, sign-up, comment and post since then disappears. On a brochure site that changes rarely this may not matter. On a shop or membership site it can cost real money.

Work like this instead:

1. Take a fresh backup of the current site first, even if it is broken. It is your way back if the restore goes wrong.
2. Restore the old backup to a staging copy or a separate folder, not over the live site. Many hosts offer one-click staging; otherwise use a subdomain with its own database.
3. Compare and copy across only what you need. If the problem is the design, bring back the theme files and settings. If it is content, copy the affected pages. Leave newer orders and posts untouched.
4. Only restore the full backup over live when the site has had no meaningful changes since the backup date, or when those changes can be re-entered by hand.

Backups are not always complete. Some plugins skip the uploads folder or exclude large files, and some host snapshots hold files but not the database. Our checklist for incomplete website backups shows how to test what a backup really contains before you rely on it.

Route 3: Roll back code with staging, version control or update rollback

When an update caused the problem, you usually want to restore code, not content.

• Plugin and theme updates. Deactivate the plugin that changed, or install its previous release from the developer’s version archive, then test. Since WordPress 6.6, an automatic plugin update that triggers a fatal error is rolled back automatically, but manual updates and theme updates are not covered by that safety net.
• Version control. If the site’s theme or code lives in Git, check out the last good commit and redeploy it. This is the cleanest rollback there is, but it only covers files in the repository, not the database.
• Staging pushes. If a staging push overwrote live, the host’s staging tool may keep a copy of the live site from before the push. Our guide on what to do when staging overwrote the live website covers this case step by step.

Route 4: Restore a website to a previous version from the Wayback Machine

When there is no version history, no backup and no code repository, public archives are the remaining source. The Wayback Machine stores captures of public pages over time, so you can open your homepage as it looked on a chosen date and browse from there. The Internet Archive’s help pages explain how to search captures by URL and date.

Be clear about what an archive can and cannot give back:

• It can give you the visible text, headings, images, page structure, menus, and often the CSS and JavaScript that made the design look the way it did.
• It cannot give you the database, admin accounts, orders, customer records, form submissions, server-side code, or pages the crawler never reached.

So an archive does not restore the site in the way a backup does. It gives you the material to rebuild the earlier version: either as a static HTML copy or as a working site in a CMS such as WordPress. Captures can also be patchy, with missing images or pages captured on different dates, so pick a date range rather than a single day and check the key pages one by one. Our full guide to restoring a website from the Wayback Machine covers the rebuild in detail.

How to choose the right route

Checks after any rollback

Restoring an earlier version is not finished when the old pages appear. Run through these checks before telling anyone the site is back:

• Clear every cache. Caching plugins, server caches and CDNs can keep showing the version you just replaced, which makes it look as if the restore failed.
• Test forms, checkout and logins. Old versions sometimes point to retired payment settings, API keys or email addresses.
• Update software. A backup from six months ago brings back six-month-old plugins, some with known security issues. Update them on staging first.
• Check URLs and redirects. If page addresses changed between versions, add redirects so links and search results still land on the right page.
• Re-enter lost data. List any orders, posts or sign-ups created after the backup date and add them back, or export them from the newer backup you took at the start.
• Take a new backup of the restored site and confirm your backup schedule is running, so the next problem is easier to undo.

When to get help

Rolling back is quick when the platform or host kept a copy. It gets hard when the only good version lives in an archive, when the site was built with a page builder or theme you no longer have, or when you need the old design and the new content together. In those cases our website recovery service rebuilds the earlier version from archived captures into a working site at its original URLs. You can first check whether your website can be restored from the captures available for your domain.

On pages built with Elementor, the editor keeps its own list of saved versions; our guide to Elementor revision history shows how to preview and apply one, and what to do when the list is empty.

If the site is long gone and you want an old design or old content back rather than last week’s version, our guide on how to restore an old website covers archive snapshots and what a rebuild can realistically recover.

Frequently asked questions

Can I restore my website to a previous version without a backup?

Partly. Without a backup you can still use page revisions or builder history if your platform kept them. If it did not, archived captures let you rebuild the public pages as they looked on an earlier date, but not the database or anything that was never public.

Will restoring an old version delete my recent orders or posts?

A full restore over the live site will. Restore to a staging copy first, copy across only the parts you need, and keep a fresh backup of the current site so newer data can be recovered.

How far back can I go?

That depends on the source. Platform history and host backups usually cover days to months. Wayback Machine captures can go back many years, but how often your site was captured varies by site.

Why does my site still show the new version after I restored the old one?

Usually caching. Clear the caching plugin, any server cache and your CDN, then check in a private browser window.