How to Restore Website from the Wayback Machine

Short answer: To restore a website from the Wayback Machine, check how much of the site archive.org captured, pick the most complete snapshot, download the archived pages and assets, strip the Wayback toolbar and web.archive.org URLs from the files, fix the links, images, and CSS, rebuild the pages in WordPress or as static HTML, and finish with redirects, a sitemap, and Google Search Console. The archive holds rendered pages, not your database, so text, structure, images, and URLs come back; user accounts, orders, and form data do not.

This guide walks through the seven steps in order, then covers what cannot be recovered and when it makes sense to do the work yourself versus hiring it out. It applies to any site that was publicly online: a business brochure site, a blog, a portfolio, or an online store whose product pages were crawled. If you only want to know whether your site is recoverable, run the domain through the free checker at Can My Website Be Restored? first.

How the Wayback Machine stores your website

The Internet Archive’s crawler visits public pages and saves the HTML it receives, along with the images, stylesheets, and scripts it can reach. Each visit is a snapshot with a timestamp. The archive never sees your server-side code or database; it only sees what a visitor’s browser would have seen. That is why a restoration is a rebuild from rendered pages rather than a restore from a backup.

Two consequences follow. First, coverage is uneven: popular pages get crawled often, deep pages rarely, and pages blocked by robots.txt not at all. Second, every page the archive serves has been modified: links are rewritten to point back into the archive, and a toolbar is injected at the top. A usable restoration has to undo both.

Step 1: Check archive coverage

Before anything else, find out how much of the site exists in the archive. Go to archive.org, enter the domain, and open the calendar view. Blue and green dots mark captures; more dots across more years usually means better coverage. Click a few captures from different dates and open inner pages, not just the homepage.

For a complete list of archived URLs, use the CDX index. Load this address in a browser, replacing the domain:

https://web.archive.org/cdx/search/cdx?url=example.com/*&output=txt&fl=original,timestamp,statuscode&filter=statuscode:200&collapse=urlkey

The result lists every unique URL that returned a 200 status, with the timestamp of a capture. Compare it against the pages you know the site had. If key pages are missing, you will need to plan around them.

The free checker at waybackrestore.com/can-my-website-be-restored/ performs the same coverage check and summarizes which pages have usable snapshots. It runs before any payment and is the same check Wayback Restore uses before quoting a rebuild. If the domain shows no captures at all, see recovery options when a website was never archived.

Step 2: Pick the best snapshot

The best snapshot is the most complete capture from the period when the site was healthy, which is often not the last one. Sites degrade before they disappear: plugins break, images go missing, and the final captures frequently show an error page, a hacked version, or a registrar parking page.

Work backward from the last capture and open each one until you find a date where the homepage, navigation, and the main inner pages all render with their styling. Note the 14-digit timestamp in the URL (for example 20230415083012). You can combine pages from different dates when a page was only captured earlier, but keep a record of which capture each page came from so the rebuild stays consistent.

Signs of a bad snapshot

• Injected spam links in the footer or hidden in the source (the site was compromised).
• Pages that redirect elsewhere inside the archive.
• Placeholder, “coming soon”, or parking content.
• A different business or design from the one you are trying to recover (an earlier or later owner of the domain).

Step 3: Download the archived pages and assets

There are two practical ways to download: pull the raw files directly using the archive’s id_ flag, or use a downloader tool that automates the fetching. Either way, you want the original bytes of each page, not the version with the toolbar.

The id_ trick for raw files

Insert id_ immediately after the timestamp in any Wayback URL and the archive serves the page exactly as it was captured, without the toolbar or rewritten links:

https://web.archive.org/web/20230415083012id_/https://example.com/about/

You can script this against the CDX list from Step 1: for each URL and timestamp, fetch the id_ version and save it to a matching folder path. The same approach works for images, CSS, and JavaScript files. A short loop with curl or wget handles a few hundred pages without difficulty.

Using a downloader

Downloader tools wrap the same process: you enter a domain and a date, and they fetch every archived file into a ZIP. They save time on the fetching but still hand you files that need the cleanup in Steps 4 and 5. The trade-offs are covered on our downloader vs restoration service page.

Step 4: Strip the Wayback toolbar and archive URLs

If you downloaded without the id_ flag, or used a tool that did not, each page contains injected code that must be removed. Look for the block between <!-- BEGIN WAYBACK TOOLBAR INSERT --> and <!-- END WAYBACK TOOLBAR INSERT --> and delete it, along with the <script> tags that load archive.org JavaScript and the wombat setup near the top of the <head>.

Next, fix the rewritten URLs. Archived pages reference assets as https://web.archive.org/web/20230415083012/https://example.com/style.css or with im_, cs_, and js_ suffixes on the timestamp. A find-and-replace across all files using a regular expression such as https?://web\.archive\.org/web/\d+[a-z_]*/ replaced with nothing restores the original absolute URLs. Then replace https://example.com/ with / so the links become relative and work on any host.

Step 5: Fix links, images, and CSS

With the archive wrapper removed, crawl the local copy to find what is still broken. A free link checker or a simple script that opens every page and lists missing resources is enough. The usual problems fall into a few groups.

• Missing images. Try other capture dates for the same image URL; the archive often has it from a different crawl. If not, use a lower-resolution copy from a thumbnail, a social preview, or another page, or replace it.
• Broken CSS. Stylesheets referenced from a CDN or a theme folder may not have been captured. Check the CDX list for the stylesheet URL, and fetch any @import or url() dependencies inside the CSS as well.
• Fonts. Google Fonts links usually still work. Self-hosted fonts need to be fetched from the archive or substituted.
• Internal links. After the URL cleanup, links should point to local paths. Any that still point to web.archive.org were missed by the replace step.
• Scripts. Sliders, menus, and contact forms depended on JavaScript that may be partially captured. Decide which features are worth reconstructing and remove the rest.

The common failure modes and how to handle them are discussed in more detail in our overview of the website restoration process.

Step 6: Rebuild in WordPress or as static HTML

At this point you have a clean set of files that could be uploaded as a static site. For a small brochure site that is a perfectly good end result. For anything you plan to edit, extend, or run a blog on, rebuilding in a CMS is the better choice, and WordPress is the usual destination because it is editable, widely supported, and can reproduce almost any layout.

Static HTML

Upload the cleaned folder to your host, keeping the same folder structure so URLs match. Add a 404 page, set the homepage index file, and test on mobile. This is the lightest option and the one behind Wayback Restore’s HTML restoration from $29.

WordPress

Install WordPress, choose a theme that can reproduce the original layout (or a page builder such as Elementor if the original was built with one), and recreate each page and post. Copy the content from the cleaned HTML, upload images to the media library, and set permalinks so that each page’s slug matches the old URL. Menus, widgets, and the footer are rebuilt by hand. Our WordPress restoration starts at $79 and Elementor restoration at $149; both deliver an editable site rather than a static copy.

For stores, the product pages the archive captured can be recreated as WooCommerce products with their descriptions, prices, and images, but inventory, orders, and customer accounts cannot be restored because they lived in the database. The WooCommerce restoration service rebuilds the catalog from the captured pages.

Step 7: Redirects, sitemap, and Search Console

The restoration is finished when search engines and existing links can find the rebuilt pages. Three tasks close it out.

1. Keep the old URLs, and redirect the rest. Every page that could be restored should live at its original path. For URLs you could not restore, add 301 redirects to the closest relevant page. Old .html extensions can be kept in WordPress with a rewrite rule so historical links keep working.
2. Restore titles and meta descriptions. The archived HTML contains the original <title> and meta description for each page. Copy them into the rebuilt pages so the site’s search snippets return as they were.
3. Submit a sitemap and request indexing. Add the domain to Google Search Console, submit an XML sitemap, and request indexing for the most important pages. Then watch the Pages report for unexpected 404s and the Links report to confirm old backlinks are resolving.

What cannot be recovered from the Wayback Machine

The archive is a collection of rendered pages, so anything that was never rendered into a public page is gone. Knowing this in advance avoids wasted effort.

• Databases. User accounts, comments stored but not displayed, order history, inventory counts, and form submissions.
• Content behind a login. Member areas, dashboards, and paid content the crawler could not see.
• Pages blocked from crawling. Anything excluded by robots.txt or never linked from a crawled page.
• Server-side code. PHP, plugins, theme functions, and custom applications. The output is captured; the code is not.
• Uncaptured assets. Large images, videos, PDFs, and CDN-hosted files that the crawler skipped or that were too new to be crawled.
• Email and DNS settings. These were never part of the website’s pages.

Partial recovery is still normal. A site with 80 percent of its pages captured can be rebuilt with the gaps filled by hand, and the content that mattered most is usually the content that was crawled most often. The full list of edge cases is in the restoration FAQ.

DIY vs professional restoration

Doing it yourself is realistic if you are comfortable with HTML, regular expressions, and a WordPress install, and if the site is small. The steps above are all achievable with free tools; the cost is time, and the risk is subtle breakage such as missed archive URLs or layouts that only fail on mobile.

A professional rebuild makes sense when the site is large, the archive is patchy, the layout is complex, or you need the result in a specific platform. Wayback Restore does every rebuild manually from the snapshot you choose, at fixed per-site starting prices: HTML from $29, WordPress $79, Elementor $149, WooCommerce from $249, Shopify, Wix, Webflow, Divi, Bricks, and Drupal $150, and redesign plus restore from $299. The archive is checked for free before you pay, the delivered site is editable, and the original URLs are kept. Full details are on the website recovery service page, and you can read about the team on the about page or ask a question via the contact form.

Frequently asked questions

Is it legal to restore my website from the Wayback Machine?

Restoring your own content is your right as the copyright holder. Restoring a site you bought as an expired domain is generally fine for the content that came with it, but remove the previous owner’s personal details, licensed stock images, and any claims you cannot stand behind.

Can I restore a WordPress site from the Wayback Machine?

Yes, but it is a rebuild, not a database restore. The archive has the rendered pages, so each page and post is recreated in a fresh WordPress install with the same slugs, and the theme appearance is reproduced. Plugins, user accounts, and settings have to be set up again.

How far back does the Wayback Machine go?

The archive has captures dating back to 1996. Whether your site is there depends on how long it was online and how often it was linked to; sites that were live for a year or more usually have at least some captures.

Why are images missing from the archived version of my site?

The crawler saves images on a separate schedule from pages, and skips large files and files served from some CDNs. Try other capture dates for the same image URL before concluding it is gone; it is often present under a different timestamp.

Will my old URLs and SEO come back after restoring?

If you rebuild each page at its original path and restore the original titles and meta descriptions, existing backlinks resolve again and search engines can recrawl the pages. Rankings are decided by search engines and are not guaranteed, but keeping the URL structure gives the restored site the best starting point.

How do I know whether my site can be restored before I spend any time?

Run the domain through the free checker at waybackrestore.com/can-my-website-be-restored/. It reports how many pages have usable snapshots and flags the gaps, which is the same check Wayback Restore performs before quoting a rebuild.