Wayback Restore: Get Your Lost Site Back in 5 Steps

Your site is gone. The hosting lapsed, the database got wiped, or the agency that built it stopped answering email. The good news: the Wayback Machine probably has a copy. A wayback restore pulls your pages, images, stylesheets, and scripts out of the archive and rebuilds them into a working site you can host anywhere. This guide is the short version, no theory, just five steps from dead site to live site, with the numbers to check at each stage so you know it worked. For a small site the whole job takes most people under an hour.

What a wayback restore actually includes

A restore is more than saving one HTML page. A real one fetches every page the crawler captured, plus the assets those pages reference: images, CSS, JavaScript, PDFs, fonts. On a typical small business site that comes to 300–3,000 files. A WooCommerce store I handled last spring came back with 11,400 files, most of them product images the owner had written off as lost.

• Every archived page, rewritten so internal links point at your domain instead of web.archive.org
• Images, CSS, and JavaScript downloaded locally instead of hot-loaded from the archive
• Optional cleanup that strips old analytics, ads, and third-party iframes
• A file manifest showing exactly what came back and from which capture date

One caveat: the archive stores what a browser received, not your server code. WordPress PHP, databases, and admin panels do not come back. What you get is the front end, the pages as visitors saw them. For most brochure sites, blogs, and forums that is 95% of the value. Dynamic features like carts and contact forms need to be rewired or replaced after the restore.

Step 1: Find the right snapshot

Open web.archive.org and enter your old URL. The calendar view shows capture density as blue circles, bigger circles, more captures that day. Do not grab the newest capture by default. The last snapshot of a dying site is often a parked page, a for-sale notice, or a hosting-suspended error. Pick the last date where the homepage actually looks like your site, then spot-check three or four internal pages from around the same month.

Watch the URL variants too. If the site lived at www.example.com, snapshots of bare example.com may be thin. Copy the exact URL of the good snapshot, you will paste it into the restore tool next. And if the site went through several redesigns, decide which era you want before touching anything. Restoring a 2012 design by accident is a real thing that happens, and re-running the job costs another fee. Thirty seconds of calendar browsing is cheaper.

Step 2: Get a wayback restore estimate

This is where people overpay or get surprised. Before spending anything, you want three numbers: how many files the archive holds for your site, how large the download will be, and what the restore costs. this free tool gives you a free instant estimate with all three, exact archived file count, total size, and a locked price, before you pay anything. The price is fixed at estimate time, so the number you see is the number you pay.

Billing is pay per restored file, the first file is free, and there is a small flat fee per restore. You top up your balance once, by card or crypto; nothing recurs, no subscription. If a restore fails, the refund hits your balance automatically, no support ticket, no waiting on an agent.

Step 3: Choose your restore options

Options look like checkboxes, but a few decide whether the restored site ranks or rots. The ones that matter most:

Date-range selection deserves special attention. If a site ran from 2010 to 2019 but looked its best between 2015 and 2017, fence the restore to those years. You avoid mixed footers, mismatched navigation, and the strange time-travel effect where a 2011 price list sits next to a 2018 homepage. Planning to edit content later? Also tick the structured article export (XML, CSV, or JSON) and the JSON/SQLite file manifest. Future you will be grateful.

Step 4: Download the restored archive

When the job finishes you get a zip of the rebuilt site. Open it before uploading anything. Check the homepage renders, click two levels into the navigation, and open a page that used to carry a contact form. Look for leftovers: archive.org toolbar scripts, absolute links back to web.archive.org, missing images. A decent restore strips the toolbar and rewrites the links for you. Missing images usually mean the crawler never captured them, and no tool can invent what was never archived.

The file manifest shows the capture timestamp of every file, so you can see at a glance if one page came from 2014 and its neighbour from 2019. Keep the zip after you upload, too. It is your offline backup of the restored site, and re-uploading from a local copy is faster than re-running anything.

Step 5: Upload the site to your hosting

Two routes. Manual: unzip locally and push the files over FTP or SFTP into your web root, fine for a 50-page brochure site, tedious at 5,000 files. Automatic: let the service deploy for you. Restorix deploys in one click to SSH/SFTP VPS, FTP/FTPS shared hosting, or S3. Credentials are AES-256-GCM encrypted and SSH host keys are pinned, so the next deploy goes to the same server you approved the first time.

1. Point DNS at the hosting before you deploy, propagation takes minutes to hours
2. Deploy, then load the site over HTTPS and click through the main navigation
3. Submit the restored sitemap in Google Search Console
4. Redirect any old URL variants you are not keeping

Shared hosting or VPS?

Shared hosting over FTPS is fine for restored static sites, there is no database to manage and traffic is usually modest. A VPS over SSH/SFTP makes sense when you want server-level redirects, aggressive caching, or you are restoring several sites at once. S3 works for pure static hosting with no PHP, which also means no CMS, pick it only if you never plan to edit the site.

Deploys include the free Restorix CMS, a single PHP file at /webarchive-cms.php with content editing, search and replace, and a file manager. The per-site admin password is randomly generated and shown in your dashboard, and safe mode is on by default. The day you need to fix outdated pricing across 200 pages, that search-and-replace pays for the habit of installing it. The tutorial walks through it.

After upload, test the five pages that mattered most on the old site: homepage, top service page, contact page, one blog post, one deep link from an old bookmark or email. If those work, the long tail almost always works.

Wayback restore mistakes that cost you money

Most failed restores fail in the same five places:

• Restoring the latest snapshot instead of the last good one, parked pages look convincing in thumbnails
• Skipping the estimate and discovering mid-job the archive holds 40,000 files, not 4,000
• Leaving old analytics and ad scripts in place, leaking referrers to domains you do not control
• Forgetting to canonicalize www versus non-www and splitting your link equity in half
• Uploading straight to production without clicking through the site on a staging URL first

None of these are exotic. Every one shows up in support inboxes weekly, and every one is avoidable with the checks in steps 1 and 2. The pitfalls guide goes deeper on each failure mode.

A restore takes an afternoon. Fixing a sloppy restore takes a week. Spend the extra ten minutes on snapshot selection.