A capture audit answers a narrow question before a website rebuild begins: does this exact Wayback Machine capture contain enough reliable evidence for the requested result? It is not a visual score and it is not a promise that the public archive contains a complete backup. The audit records what was requested, what responded, what is missing, and which gaps need an owner decision.
Use this checklist on one dated capture first. The result should be a small evidence file that a developer, editor, and site owner can read without guessing how the conclusion was reached.
Record the capture identity
Start with the complete replay URL copied from an opened capture, not a wildcard calendar URL. Preserve the 14-digit timestamp, original scheme, hostname, path, and query string. Record the final replay URL too, because an archived redirect can move the request to another host, path, or capture date.
| Field | What to record | Why it matters |
|---|---|---|
| Submitted capture | Full replay URL and timestamp | Makes the starting point reproducible |
| Original URL | Scheme, host, path, and query | Defines the page that the archive attempted to preserve |
| Final response | Status, MIME type, and final URL | Separates a page from a redirect or saved error document |
| Recovery scope | Approved hosts, paths, and date policy | Stops discovery from expanding into unrelated properties |
Sample pages by function, not at random
A homepage alone cannot represent a complete site. Select a small sample that exposes different risks. Include the homepage, a deep navigation destination, an image-heavy page, a downloadable file, and one page from every unusual layout. If the old site had search, accounts, forms, checkout, maps, or other interactive features, include the visible entry page for each feature.
What the sample can prove
The sample can show whether public HTML, text, navigation, layout evidence, and referenced files were captured. It can also reveal repeated templates and likely route families. This is enough to estimate recovery work and to decide which parts can become static pages or reusable components.
What the sample cannot prove
A captured form does not prove that its server endpoint, recipient, validation rules, or stored submissions survived. A product page does not recover inventory or orders. A login screen does not contain user accounts. List these as current implementation requirements rather than recovered features.
Inspect page and asset responses
For each sampled page, inspect the main HTML plus its stylesheet, logo, representative images, fonts, scripts, and important downloads. Record the requested replay URL, response status, content type, byte size, and capture timestamp. A file named logo.png can contain an HTML error page, so the extension is not evidence that an image was recovered.
- Usable response: the status, MIME type, and content match the requested resource.
- Redirect: record every hop and decide whether the final destination remains in scope.
- Replay wrapper: remove archive navigation from the deliverable, but keep the source URL in the manifest.
- Missing response: keep it in the missing-file report even if its broken page element is later removed.
- Nearby substitute: record the requested timestamp, supplied timestamp, reason, and affected pages.
Check date coherence
Archive pages and their assets are often captured at different times. A nearby asset can be a reasonable substitute when the approved policy allows it, but the substitution must be visible. Compare navigation labels, copyright text, product names, design changes, and file hashes. These signals help detect an asset from a different site version.
Do not choose a file only because it makes the screenshot look complete. Prefer the nearest response that matches the page structure and approved time window. If the evidence conflicts, mark the item for owner review rather than presenting a guess as recovered history.
Classify the recovery outcome
Use a simple disposition for each sampled route. This produces a useful scope decision without inventing a percentage that appears more precise than the evidence.
- Recover as captured: the page and required public assets are coherent.
- Recover with documented substitutions: specific gaps have suitable nearby evidence.
- Reconstruct from evidence: content and presentation survive, but implementation needs new code.
- Owner source required: a critical image, document, or current business detail is absent.
- Exclude: the route is outside the approved scope, obsolete, unsafe, private, or unsupported.
Produce a capture audit record
The finished record should name the authorized domain, exact starting capture, pages sampled, asset checks, redirect findings, date substitutions, dynamic features, privacy concerns, and unresolved decisions. Add a recommended rebuild scope and list the evidence that supports it. Keep this record beside the later URL manifest so changes in scope remain traceable.
A useful conclusion is specific. For example: the five public content templates have coherent HTML and CSS, two shared images require dated substitutes, the contact form needs a new endpoint, and account pages are excluded. That statement is more actionable than saying the site is 90 percent recoverable.
Stop and request review when evidence conflicts
Pause when the capture changes host unexpectedly, important pages come from incompatible site versions, a recovered file contains personal information, or the requester cannot confirm rights to republish the material. Also stop when a dynamic feature affects payments, authentication, private data, or legal commitments. Technical recovery does not decide ownership or current business policy.
Use the audit to choose the next workflow
If the sample is coherent, continue with a complete URL inventory and the website restoration workflow. If the main uncertainty is the capture date, compare snapshots using the snapshot selection guide. When the evidence is ready, the Archive.org website rebuilder can turn the approved scope into a project configuration.
Primary references
The Internet Archive explains how replay URLs and saved pages work. Google Search Central documents the crawl and URL signals that matter when the recovered site is published under current URLs.
- Internet Archive: Using the Wayback Machine
- Internet Archive: Save Pages in the Wayback Machine
- Google Search Central: Canonicalization
Inspect an exact archive capture
Validate the timestamp and original hostname before configuring an authorized recovery.
Open the Wayback downloader