How Can I Preserve a Website Before It Disappears?

Preserve a website before it disappears by deciding exactly what matters, saving the pages or files with an appropriate tool, and testing the copy while the original is still available. Record the original URLs, capture dates, publisher, and known omissions. Keep copies in more than one place. A saved homepage or screenshot is useful evidence, but neither is a complete website backup.

If you own the website, preserve its source code, content, database, uploaded assets, configuration instructions, and rights to the domain as well as a browsable archive. If you are researching someone else's public website, first consider permissions, privacy, copyright, site rules, and the scope of collection. Do not use archiving tools to bypass authentication, access controls, or a publisher's restrictions.

The right method depends on whether you need one historical article, a complex interactive page, a collection of public pages, or a site you may have to rebuild later.

Decide what you want to preserve

The word website can mean many different things. A browser sees rendered pages; the server may hold a database, software, files, and credentials that are invisible in the browser.

Preservation goal	Useful approach	Important limitation
Reference one public page later	Wayback Machine Save Page Now	Saves the requested page, not a complete site crawl
Save interactive public pages you can browse	ArchiveWeb.page	Captures what was visited and loaded, not every hidden state or link
Collect a larger permitted public site	Browsertrix Crawler with bounded scope	Dynamic content, third-party assets, and rights constraints can still leave gaps
Rebuild a website you own after a failure	Source repository, database export, media files, configuration and restore test	An archived web view cannot reconstruct private server behavior or missing data
Preserve citations and historical context	Archive URLs, page titles, publisher details, timestamps and notes	Metadata supports provenance but does not prove factual accuracy

The Library of Congress explains in its web-archiving FAQ that crawlers often miss material requiring user input, subscription access, dynamically generated database queries, interactive maps, and some streamed media. Planning around those limits is more reliable than assuming a tool saves everything.

Step 1: choose a lawful and manageable scope

Start with an inventory of the important pages: homepage, About page, dated articles, product or project documentation, key downloads, images, and the pages other researchers cite. Record the exact original URLs, not only the current domain.

If this is your own site, inspect what should be public and what should remain private. Customer databases, draft content, payment receipts, API tokens, owner-only dashboards, and personal information should be handled with separate, access-controlled backups—not fed into a public archiving service.

If the material belongs to someone else, narrow the capture to material you may lawfully access and retain. Respect applicable law, the site's terms and license, rights-holder requests, and the tool's access restrictions. A public page is not necessarily available for unrestricted copying or redistribution. The U.S. Copyright Office distinguishes reproduction and distribution rights from merely being able to see a work online.

Archiving and republishing are separate decisions. You may be able to inspect or preserve a copy for a legitimate purpose without having permission to publish a mirror or sell its files. Where the project involves substantial third-party material, seek permission or relevant legal advice rather than making a blanket assumption about fair use.

Before any larger permitted crawl, define an upper bound on pages, depth, and frequency to avoid unnecessary traffic. Do not bypass passwords, paywalls, CAPTCHAs, or anti-bot controls to expand the collection.

Step 2: save individual pages with the Wayback Machine

For a public page that you want to reference, start with the Internet Archive's Save Page Now instructions. Enter the precise page URL, initiate the capture, then open the resulting snapshot.

Save Page Now captures one requested page, not the entire site. Its help documentation says a capture can include page assets such as images and CSS, but it does not follow all outgoing links and cannot initiate a full-site crawl. A successfully saved homepage does not establish that the site's subpages, PDFs, or downloads were preserved.

Make a short priority list and capture the pages that matter individually. After saving, verify that the archive displays the expected text and images. If there is a historical citation or quoted passage, record the snapshot URL with its capture timestamp rather than linking only to the live address.

There are limitations. The Wayback Machine help center warns that capture can fail, resources may not be archived, and archived pages may not replay as expected. Nor does a one-time submission guarantee that the page will be recaptured in the future.

A Wayback snapshot is a useful public reference, not an emergency backup for a website you control. The Archive explicitly says it cannot guarantee that a site has been or will be captured or package up missing sites for general restoration.

Step 3: use browser recording for a page that needs interaction

A plain page capture may miss text that loads only after scrolling, opening a tab, or interacting with the interface. For public content you have permission to preserve, Webrecorder's ArchiveWeb.page provides an interactive capture tool as a Chromium browser extension or standalone application.

Its capture instructions describe starting a recording session, browsing the page, and interacting with the content you want included. The tool records resources encountered during that session rather than claiming to understand every possible state of the website.

After the capture, you can export a WARC or WACZ file and open the material in ReplayWeb.page. Webrecorder's official product documentation explains that these exports support portable replay.

The important precaution is to avoid capturing and publicly sharing confidential sessions. A recording can contain URLs, session-dependent requests, or material visible only after a personal login. Keep any necessary authorized private preservation segregated, inspect exported content before sharing, and follow the relevant permissions and privacy requirements. Do not treat a browser archive as automatically scrubbed of secrets.

This approach is strongest when you know which interactive pages matter. It will not automatically inventory every page in a large site.

Step 4: plan a bounded crawl for a larger site

A browser-based crawler is more appropriate when a permitted collection contains many linked public pages. The Browsertrix Crawler is an open-source, Docker-based system that records sites through a browser. Its official guide documents generating portable WACZ archives and replaying them.

Instead of simply pointing it at a domain and hoping for the best, configure a scope. Its crawl-scope documentation distinguishes one-page, URL-prefix, domain, and other inclusion strategies. Crawls can also be limited by depth or total page count.

For a small site under your control, an appropriate process might be:

1. Identify the homepage and the exact document sections that matter.
2. Set a crawl scope that excludes admin routes, search-result loops, private URLs, large downloads you do not need, and unrelated third-party domains.
3. Select conservative page and time limits.
4. Capture the permitted public pages.
5. Replay the result and inspect representative pages, images, documents, and navigation.
6. Revise the scope only to address verified gaps.

The Browsertrix user guide provides an example Docker command that produces a WACZ output, while its quality-assurance features can help compare crawl and replay behavior. Those are useful starting points, not a guarantee that a visually accurate replay has recovered an entire underlying application.

A crawler can make requests faster than a person, so pay attention to server load and the publisher's policies. There is a genuine difference between archiving your own pages with authorization and indiscriminately scraping somebody else's website.

What do WARC and WACZ actually preserve?

The WARC (Web ARChive) format holds web resources and related harvesting records in a standard archival container. The Library of Congress's WARC format description explains how it can preserve HTTP responses, metadata, dates, and other records collected during web harvesting.

WACZ (Web Archive Collection Zipped) packages resources and indexes for portable replay and sharing. The Library's Recommended Formats Statement for Web Archives lists WARC as preferred and WACZ as an acceptable format for preserved web content.

These files are not equivalent to a website's complete source repository, database, secrets, DNS records, or live backend. They are evidence of what the capture process encountered, not everything that once existed on the server.

For simple static pages, a WARC/WACZ capture may preserve readable text and layout remarkably well. For web applications, it may retain enough network responses to replay common views but not a working account system, private search backend, submission form, or payment integration.

Archive for replay when the goal is historical viewing; back up software and data separately when the goal is restoration.

A site owner needs a real backup, not only snapshots

If the website belongs to you and you may need to relaunch it, protect its underlying components in addition to external captures:

• Application and source files: The deployed version, theme, templates, dependencies, and a record of how to build or deploy it.
• Database exports: The actual authored content and application records necessary for restoration, stored securely. A code repository usually does not contain them.
• Uploaded media: Images, PDFs, audio, and attachments needed to reconstruct the site.
• Infrastructure instructions: Domain and DNS details, required services, runtime versions, server configuration, and non-secret configuration examples.
• Credentials and recovery material: Backed up separately in an appropriately protected system; never put live passwords, private keys, recovery phrases, or API tokens in a public archive or code repository.
• Independent evidence: A Wayback capture or local web archive to document the public appearance and address of key pages.

Keep separate copies with restricted access in locations that do not share one failure mode. A copy stored only on the same server as the website may disappear with the server. An automatic backup job is not proven to work until you have restored representative data in a safe test environment.

When retiring a domain, consider keeping redirects and documentation of the move if you still control it. The Library of Congress's preservable-websites guidance specifically recommends stable URLs and redirects when addresses change.

Make the original site easier to archive

Some preservation failures can be reduced before an archive crawler visits.

The Library of Congress's guide to creating preservable websites recommends accessible standards-based HTML, transparent links, stable URLs, a sitemap, sustainable formats, and careful handling of crawler exclusions.

A crawler that cannot discover a link cannot reliably find its destination. If the only way to reach an article is to fill out a search form or trigger a complicated JavaScript event, a traditional crawler may overlook it. Linking to important documents through ordinary navigation provides more than a convenience: it improves the chance of preservation.

Robots rules require context. A site's /robots.txt can ask compliant crawlers to avoid certain URL paths, but it is neither a privacy boundary nor a universal legal rule. Some crawlers honor robots exclusions, some collections operate under special permission or legal policies, and practices vary. The Library of Congress notes that its institutional crawl procedures can bypass robots exclusions for selected permitted collections. Do not assume a robots rule provides confidentiality or gives third-party collectors unrestricted permission. Protect private content with real access controls.

Site owners should also avoid putting sensitive personal information or private links into public HTML merely to make an archival snapshot more complete.

Inspect the capture: what did it miss?

Do not call a collection finished simply because a tool reported success. Open the saved archive in its replay interface and compare it with the live website while that is possible.

Check representative pages for:

• Text and titles, including the full article and footnotes.
• Images, captions, stylesheets, and responsive layouts.
• Linked PDFs, downloads, and large media files.
• Internal navigation, redirects, and links to external sites.
• Interactive tabs, scrolling content, forms, maps, and search features.
• Dates and whether resources might have been pulled from a different capture time or live site.

The Library of Congress web-archiving FAQ identifies dynamic applications, streaming media, deep-web material, and database-driven pages as recurring preservation challenges. A page can look correct in a screenshot while its important links or data are missing.

If you find a gap, capture the specific permitted asset or page separately when possible, or document the omission. An explicit record of missing content is better than silently treating a partial capture as complete.

Write a small preservation manifest

A future researcher needs to know what was collected and where it came from. Keep a plain-text README or a structured manifest next to the preserved material.

For an illustrative project, the record could contain:

Project: [site name]

Original domain: [domain and relevant path]

Publisher/owner: [verified name or “not established”]

Capture made: [date, time zone, and tool used]

Scope: [pages, directories, exclusions, known restrictions]

Evidence files: [archive filename, size, and location]

Snapshot URLs: [public Wayback or institutional capture addresses, if available]

SHA-256: [checksum of the retained archive file, calculated after capture]

Replay tested: [date, viewer, selected URLs, results]

Known gaps: [uncaptured images, scripts, document links, dynamic views]

Rights and access: [license, permission, or restricted-use note]

A SHA-256 digest provides a baseline for detecting later byte-level changes to the captured file. It cannot prove that the original site was accurate or that the publisher owned the content. The Library's WARC and preservation guidance treats contextual metadata as part of a usable web archive.

For researchers, a complete manifest also prevents confusion between publication date, capture date, and the day a file was downloaded from an archive.

Keep copies independent and review them

A practical retention plan has several layers: a working archive you can open, at least one additional protected copy, and a record of where those copies are stored. For important work, consider an offline or otherwise isolated copy in case an account, server, or storage provider becomes unavailable.

Periodically check that the files can be read, that checksums match earlier recorded values, and that the replay software still opens the archived content. File formats and tools change. Saving something once does not guarantee future usability without maintenance.

If you update the site later, preserve another dated capture where that change matters. Do not overwrite the older snapshot and pretend the site has always looked the way it does now.

Where CacheRat can help

CacheRat is oriented around digital salvage, overlooked websites, documentation, and researched resources. A discovery index can help researchers locate older project names, archival services, surviving mirrors, and references to material that is no longer widely linked.

That is different from operating a universal web backup service. A CacheRat listing does not establish that CacheRat captured an entire third-party website, holds its files, owns redistribution rights, or can restore it. Follow the linked source and verify each specific resource.

If you are preserving something now, the most useful gift to a future reader is a traceable link or archive, an exact identity, and a candid account of what remains missing. That record makes digital-salvage research substantially more reliable.

For related topics, see Switchboard's web discovery and digital research collection and its guide to copyright and reuse of archived internet material.

The test is whether someone can use the copy later

A successful preservation effort answers four questions: What was saved? From where? When? And does it still open?

A public snapshot can preserve one page. An interactive archive can preserve views you visited. A carefully scoped crawler can gather a larger public collection. An owner-controlled backup can support rebuilding a site. None guarantees that every file, interaction, or historical state has survived.

Preservation is more than downloading HTML. It means retaining evidence, context, and usable copies without claiming rights or completeness you cannot verify.