Step-by-Step: How to Archive Old Websites for Future Reference

A website disappears, changes ownership, gets redesigned, or quietly deletes half its content. Then you need that old version.

Too late.

That’s the annoying part of web preservation: people often start thinking about archiving after the evidence, design, documentation, or historical context has already vanished. A bookmark won't help. A screenshot won't preserve the navigation. Copying text into a document strips away structure, links, and often the very context that made the page useful.

For readers of Wiki Archives, the better approach is to treat a website as a historical artifact rather than a disposable webpage. This guide takes a practical, layered approach: capture the page, preserve the site, keep a local copy, and verify that the archive can actually be opened years from now.

The goal isn't simply to download a website.

It's to make sure future-you can still use it.

First, decide what you're actually trying to preserve

Before opening an archiving tool, answer one question: what must survive?

A simple article is easy. A JavaScript-heavy website, interactive map, online database, or login-dependent portal is not.

These are different jobs.

The distinction matters because a folder full of .html files is not necessarily a functional archive. Modern websites may load fonts, images, APIs, scripts, embedded media, and JSON data from dozens of URLs.

Miss one dependency and the replay can look strangely broken.

I've seen this happen with sites that appeared perfectly captured until the archive was opened offline: the page layout loaded, the article text was there, but every chart was blank because the JavaScript data request had never been captured.

So start with a target.

Write down:

• The site's main URL and important subdomains.

• The date and time you began preservation.

• Why the site matters.

• Pages or features that absolutely must work in replay.

• Whether the site is public, authenticated, region-specific, or personalized.

That tiny inventory becomes surprisingly useful later.

Step 1: Check whether an archive already exists

Don't assume an old website is gone just because its live domain now shows a parking page.

Search the Internet Archive Wayback Machine first. Existing captures can reveal the site's historical structure and help you identify important URLs before launching your own crawl.

Look for more than the homepage.

Check:

• /about

• /blog

• old category pages

• documentation

• downloadable files

• image-heavy galleries

• pages linked from old navigation menus

This reconnaissance step can save hours. It also helps prevent a common mistake: crawling only the current homepage and assuming the crawler will somehow discover pages that are no longer linked from the live site.

It won't.

If the historical URL is known, add it deliberately to your archive plan.

Step 2: Save the most important pages immediately

For a single public page, use Save Page Now. The Internet Archive describes it as a way to save an individual page, including images and CSS in many cases, while also making clear that it is not the same thing as capturing an entire website.

That makes it excellent for an emergency capture.

Suppose a local history organization announces that its website will close next week. Don't wait until you've designed the perfect archival workflow. Save the homepage, key exhibits, major announcements, and pages containing original research first.

Then build the deeper archive.

This is the first rule of practical preservation:

Capture the irreplaceable material before optimizing the process.

Also record the resulting archive URL in your notes. An archived page you can't find again is only marginally better than a forgotten browser bookmark.

Step 3: Use WARC or WACZ for a serious local archive

If you want something more durable than a collection of screenshots, learn two file formats: WARC and WACZ.

A WARC, or Web ARChive file, stores captured web resources and related HTTP transactions. Browsertrix can also generate WACZ packages, which bundle web archive data with indexes and metadata for portable replay.

Browsertrix Crawler 1.x is a browser-based system that uses Puppeteer to control Brave Browser instances and captures traffic through the Chrome DevTools Protocol (CDP). That browser-driven approach is particularly useful for modern websites that don't behave like old-fashioned static HTML.

The crawler's documented output can include WARC files, CDXJ indexes, JSON Lines page data, reports, browser profiles, and optionally a WACZ package.

That's a much richer preservation package than:

website-final-really-final.zip

We've all seen folders like that.

Nobody remembers what they contain six months later.

Step 4: Run a browser-based crawl

For a hands-on workflow, Browsertrix Crawler can run inside Docker.

The official quick-start example uses:

docker pull webrecorder/browsertrix-crawler

Then:

docker run -v $PWD/crawls:/crawls/ -it \

webrecorder/browsertrix-crawler \

crawl \

--url https://example.com \

--generateWACZ \

--text \

--collection example-archive

The crawler documentation notes that the --generateWACZ option creates a WACZ archive, while --text enables automated text extraction. The finished archive can then be opened in ReplayWeb.page-compatible software.

For a first crawl, don't immediately point the crawler at an enormous domain.

Start small.

Try the homepage and a clearly defined section. Review the results. Then expand.

Browsertrix Crawler also supports limits that can stop a crawl before it consumes more resources than expected:

• --limit P limits the number of pages.
  

• --sizeLimit sets a maximum capture size in bytes.
  

• --timeLimit sets a maximum runtime in seconds.
  

• --workers N runs multiple browser workers, although more workers also demand more CPU and bandwidth and do not guarantee a faster crawl.
  

For example:

docker run -v $PWD/crawls:/crawls/ -it \

webrecorder/browsertrix-crawler \

crawl \

--url https://example.com \

--limit 500 \

--timeLimit 7200 \

--generateWACZ \

--text \

--collection example-archive

Two hours. Five hundred pages. A defined stopping point.

Much safer than launching an unlimited crawl on a Friday evening and discovering on Monday that a calendar, search parameter, or infinite URL pattern sent the crawler wandering into thousands of near-duplicate pages.

Step 5: Be ruthless about crawl scope

Scope is where good archives and bloated archives start to diverge.

A crawler follows rules, not intuition.

If you tell it to capture an entire domain, ask what happens to:

• 
  search-result pages
  

• 
  tracking URLs
  

• 
  print views
  

• 
  calendars generating endless dates
  

• 
  language variations
  

• 
  embedded social media
  

• 
  external links
  

Browsertrix provides configurable crawl scopes and supports URL blocking rules. Its documentation also describes a one-hop option for following directly linked external pages and newer smart scoping rules for supported social platforms.

For historical preservation, I usually recommend beginning with the smallest scope that captures the story you're trying to preserve.

You can always run another crawl.

Undoing 300 GB of unnecessary capture data is less fun.

Don't archive secrets by accident

Authenticated crawling needs special care.

Browsertrix supports browser profiles and login-based workflows, but its documentation warns that HTTP Basic Auth credentials included in a crawl URL can be written into the archive. Use dedicated archival accounts where possible, and never assume a WARC is safe to publish simply because the original website required a login.

Archive copies can preserve more than you intended.

Cookies. Private pages. Personal details.

Inspect before sharing.

Step 6: Test the archive before declaring victory

This step gets skipped constantly.

Don't skip it.

Open the WACZ or replay environment and behave like an ordinary visitor:

1. 
   Open the homepage.
   

2. 
   Follow the most important internal links.
   

3. 
   Check images, navigation, documents, media, and search or interactive elements.
   

4. 
   Compare a few archived pages against screenshots or notes from the live site.
   

Browsertrix Crawler includes quality-assurance capabilities that can compare aspects of captured pages with their replay, including screenshots, extracted text, and page resources. The documented QA features are available in Browsertrix Crawler releases 1.1.0 and later.

This is particularly useful for JavaScript-heavy sites.

A successful crawl is not automatically a successful preservation.

Those are different things.

Step 7: Keep at least two copies, ideally in different places

Once you have a working archive, organize it like any other valuable research collection.

A practical structure might look like this:

website-archive/

├── 2026-08-22-original-crawl/

│ ├── archive.wacz

│ ├── crawl-notes.md

│ └── checksums.txt

├── screenshots/

├── source-notes/

└── README.md

The README.md should explain:

• 
  what was archived
  

• 
  when it was captured
  

• 
  which crawler and version were used
  

• 
  crawl limits and scope
  

• 
  known missing features
  

• 
  how to replay the archive
  

Specific versions matter. Browsertrix's own deployment documentation, for example, warns that versions before v1.22.8 were affected by a security issue and recommends upgrading affected installations; it also recommends Browsertrix Crawler v1.13.0 or later for instances pinned to older crawler versions.

Preservation isn't just about keeping the file.

It's about preserving enough context to understand how that file was created.

For important collections, keep one local copy and one independent backup. A NAS, external drive, or reputable cloud storage location can all work, but don't place both copies inside the same failure domain.

One synced folder is still one mistake away from disaster.

Step 8: Archive changing websites more than once

A website is often a moving target.

The first crawl may capture a redesign. The second may preserve content that disappears a month later. The third can reveal exactly when a policy, dataset, biography, or public statement changed.

Browsertrix supports scheduled workflows for recurring crawls, and its platform is designed around archiving, replaying, organizing, and reviewing evolving web content.

For an active website, establish a simple schedule:

Don't capture constantly just because you can.

Capture when the historical value justifies it.

Frequently Asked Questions

Is downloading a website the same as archiving it?

Not necessarily. A downloaded HTML folder may miss scripts, external assets, network responses, metadata, and replay context. WARC- and WACZ-based workflows are generally better suited to preserving captured web activity and making it replayable later.

Can I archive an entire website with Save Page Now?

Not through the basic single-page workflow alone. Internet Archive's documentation explicitly distinguishes saving one page from capturing a whole site.

Why does my archived site look different from the original?

Dynamic content may load after interaction, depend on third-party services, use personalized data, or request resources outside your crawl scope. Run a test replay, identify what's missing, then adjust scope or browser behavior and crawl again.

What is the best format for long-term web preservation?

There is no magic file that guarantees permanence, but WARC is an established web archiving format, while WACZ packages can make captured content and indexes easier to transport and replay. Keeping documentation alongside the archive is just as valuable.

Should I archive the original website or rely on a public archive?

For material that matters to your research, organization, or personal history, use more than one layer when possible. A public capture is useful for citation and discovery; an independently stored local archive gives you another copy and more control over preservation.

Start with the page you'd hate to lose

Don't begin by trying to archive the entire internet.

Pick one vulnerable website. Map its important pages. Save the irreplaceable material immediately, run a controlled crawl, test the replay, and store the resulting archive with enough notes that someone else could understand it years from now.

Then do it again when the site changes.

That repetition is where a pile of old web files becomes an actual archive.