How to download a website from the Wayback Machine.

What a “Wayback Machine download” actually is

The Internet Archive’s Wayback Machine, at web.archive.org, stores point-in-time captures of public web pages going back to 1996. When people say they want to “download from the Wayback Machine”, they almost always mean one of these three things:

• Recover their own site after a host crashed, a domain lapsed, or a developer wiped the database.
• Check what a site looked like at a particular date — for legal, journalistic, or due-diligence reasons.
• Pull a static copy of an old brochure site so it can be re-hosted somewhere cheaper, like a plain static host.

In every case the output is the same: a folder of HTML, CSS, JavaScript and images that renders the captured page the way it looked on that date, without the archive’s overlay toolbar and without links that still point back at web.archive.org.

Step 1: Find a capture that is actually complete

Go to web.archive.org and type the domain (or the exact page URL) into the search box. The archive shows a calendar view with a dot on each date it has captures.

The trap most people fall into is clicking the most recent capture and assuming that’s the best one. Often it isn’t. Common reasons to pick an earlier date:

• The latest capture is a parking page, a 404, or a hack defacement.
• Important sub-pages stopped being captured after a theme change.
• You specifically want the pre-redesign version.

Step 2: Copy the timestamped URL cleanly

Once you’ve opened a capture, your browser’s address bar shows a URL in this format:

https://web.archive.org/web/20130425054636/http://example.com/

That 14-digit number (20130425054636) is the capture timestamp: year, month, day, hour, minute, second. It’s important because a good downloader pins the whole job to that timestamp, so your restored site doesn’t turn into a stylistic frankenstein of multiple years.

Copy the whole URL — don’t strip the trailing slash, don’t simplify it, don’t remove the protocol in front of example.com. The archive stores URLs exactly as they were requested; a slightly different path is a different record.

Step 3: Pick a downloader that fits the job

There are three realistic routes:

a. A hosted, browser-based downloader

For a single site, nothing beats a hosted tool — no local install, no Ruby version manager drama, no fighting 429 rate limits yourself because the tool already does the backoff for you.

We use the free tool at wayback.download (our own, so we obviously think it’s good — but even if you prefer something else, use a hosted tool over a local script for anything bigger than a single page).

b. The classic Ruby gem

If you already have Ruby installed and you’re comfortable at the command line, the open-source wayback_machine_downloader gem by hartator still runs. It gives you a raw copy of the HTML — no link rewriting, no toolbar removal — and will hit 429 rate limits on medium-to-large sites.

Fair comparison and modern alternatives: Ruby gem alternatives in 2026.

c. wget plus a wrapper script

For a quick one-off, people do sometimes use wget --mirror pointed at https://web.archive.org/web/{timestamp}/http://example.com/. It works for very small captures. It doesn’t rewrite internal links, and the resulting files are still full of web.archive.org references. You end up doing a lot of manual cleanup.

Step 4: Let the downloader do its thing

With a hosted tool, you paste the URL, add an e-mail (that’s where the ZIP link lands), and watch a live preview while the engine works. Under the hood, a well-behaved downloader does this:

1. Snapshot fetch. Pulls the archived HTML of the capture you pointed it at.
2. Toolbar strip. The archive injects a Wayback toolbar and a small set of tracking scripts into every page it captures. Those are removed so the restored page looks like the original did.
3. Link rewrite. Every internal link, stylesheet and script reference is rewritten from https://web.archive.org/web/{ts}/http://example.com/path.html to a plain relative path (path.html). That’s what makes the extracted folder open standalone.
4. Smart page selection. For free previews, most tools walk the site tree and pick the homepage plus the most link-dense internal pages — typically About, Services, Products, Blog index — so you get a representative sample fast.
5. Asset budget. CSS and JavaScript always come down. Images are budgeted so the ZIP stays small enough to be instant. Full-site packs expand the image budget.

Step 5: Open, verify, and re-host the folder

Extract the ZIP. You’ll see a folder structure that roughly follows the original site:

example.com/
  index.html
  about/
    index.html
  services/
    index.html
  assets/
    style.css
    main.js
  images/
    hero.jpg
    logo.png
  readme.txt

Open index.html in your browser. The homepage should render exactly as it did at that capture date. Click a navigation link — it should take you to about/index.html (or wherever the link pointed), not to web.archive.org.

If the folder passes that smoke test, you’re done: you have a working static copy of the site at that point in time.

Three common failure modes (and how to spot them)

1. The snapshot was always broken

If the archive captured the site while it was already down or mis-configured, the download will reproduce that mis-configuration. Fix: pick a different capture date (see Step 1).

2. Half the assets are blank or 404

Usually this is the Wayback Machine itself rate-limiting your fetcher. If you’re using a local tool, you’ll see a stream of 429 responses in the log. Fix: throttle, retry with backoff, or switch to a hosted downloader that handles this server-side. Full guide: Fixing 429 Too Many Requests.

3. Internal links still point at web.archive.org

That means your downloader wasn’t rewriting links. wget and the stock Ruby gem both behave this way. Either pick a tool that does link rewriting, or do a find-and-replace on the extracted folder.

Where to put the folder once you’ve downloaded it

You have a working static site. You can host it almost anywhere:

• Any ordinary shared hosting account (just upload into public_html/).
• Any static-site service that lets you drag a folder in.
• A plain file server behind a reverse proxy.
• Your own machine for offline browsing (double-click index.html).

If you need the recovered site to live on top of a CMS (WordPress, most commonly), the download is your starting point, but you’ll need a conversion step — see the “when it’s not enough” section below.

When the free download isn’t enough

Most people who need a Wayback Machine download fall into one of three buckets:

• Small, static site — small budget. The free download usually fits. If you need more pages or a bigger image budget on the same snapshot, the self-serve plans on wayback.download upgrade the same job — no re-crawl, no re-upload.
• Needs to be a working WordPress install. The download gives you HTML — it does not auto-convert to WordPress. For that, our team at waybackrevive.com delivers a working WordPress site from $110, Elementor from $149, WooCommerce from $249. Pricing and terms are on that site.
• You want it looked after once it’s back. Restored sites tend to break again for the same old reasons — expired plugins, forgotten updates, a host that quietly loses the backup. Revive Guard is our WordPress care plan from the same team: off-host backups, safe updates, uptime checks and recovery if anything goes wrong. It’s optional — only worth it if ongoing care would actually help you.

Open the free downloader →   Next chapter: fixing 429 errors