How to give reviewers proof of what was live on a given date

Sooner or later someone asks what the site showed on a particular date. A regulator asks it when a promotional website is updated and the sponsor has to say what changed since the original submission. A compliance officer asks it when a retail communication is pulled for review and the file has to show the date of first use and who approved it. A lawyer asks it when a page is disputed and the screenshot has to be authenticated before anyone looks at what is on it.

A folder of screenshots named final_v3 answers none of them. This guide is about what does: what a defensible record contains, why the two usual shortcuts fail, what each kind of reviewer needs from the record, and how to build one. It is written by RouteShot, which produces this record on every capture; the last section says what it does and does not do. It is not legal advice.

What “proof” has to contain

Strip the question down and there are six things a reviewer needs, and a screenshot on its own supplies one of them.

1. The artifact. The capture itself, at the widths and in the states that matter.
2. When. A timestamp the person who made the capture did not type by hand.
3. From where. The URL, and whether it was staging or live.
4. By whom. A named person, or a named system acting for one.
5. That it is complete. Which pages were in scope, which were captured, which failed, which were retried. A set with a gap is a set that proves the gap.
6. That it has not changed. The settings the capture ran with, kept as they were at the time, and a history that survives later edits to the project and later cleanup of the files.

The first item is what people think of as the evidence. The other five are what make it evidence.

Why the Wayback Machine is not the answer

The Internet Archive is invaluable and it is the wrong tool for this job, for reasons that have nothing to do with its quality.

• It crawls on its own schedule. You get whatever moments it chose, which are rarely the milestone you need.
• It cannot see what review needs to see. Staging sites, login-gated pages, an expanded ISI tray, a consent settings panel, a validation state on a form. Anything that needs credentials or a click is absent.
• It renders what it can. Script-dependent layouts, lazy-loaded images and consent overlays come back partial or wrong.
• Courts are not uniform about it. Some have taken judicial notice of Wayback pages, and the accepted route to admitting them has been an affidavit from an Internet Archive representative about how the archive captures and preserves content. Others have excluded Wayback screenshots where the proponent failed to lay a foundation under Rule 901. Building a compliance record on evidence you may need a third party’s affidavit to use is a poor bet.

Keep it as a backstop for public pages. Do not plan on it.

Why a screenshot folder is not the answer either

Manual captures fail the same six-item test in the opposite way. The artifact is there, and nothing else is.

• The timestamp is file metadata, which changes when the file is copied, or a date in a filename, which anyone can edit.
• There is no record of who took it, only of who owns the folder.
• There is no scope. Nobody can say which pages were supposed to be in the set, so nobody can say what is missing.
• There is no per-page outcome. A page that failed to load simply is not there.
• The settings are in someone’s head: which widths, which consent path, whether the ISI tray was hidden.
• Renaming, re-exporting and “cleaning up” between milestones rewrites the record with no trace.

This is why review teams re-run captures they have already run: not because the old ones are wrong, but because nothing about them can be shown to be right.

What each reviewer needs from the record

Pharma and the FDA. The submission rules make the date do work. A firm submits its entire product website at first use; an updated page or section is submitted afterwards with a cross-reference to the original submission and its date; a substantially revised site is submitted again in full. Choosing between “updated page” and “substantially revised” is only defensible with a dated capture of what was submitted before and a dated capture of what is live now. The record therefore needs page-level identity, a date on every set, and a way to say what changed.

Financial services and FINRA. Retail communications, which include public websites, must be kept for the retention period in SEA Rule 17a-4(b), three years with the first two in an easily accessible place, in a format that complies with 17a-4. The file has to show the date of first use and the registered principal who approved it. Since the 2022 amendments to 17a-4, firms can meet the electronic-records requirement with an audit-trail alternative to write-once storage: a system that keeps a complete time-stamped record of modifications and deletions, who made them, and enough to recreate the original. That is a description of a capture record with history, not of a folder.

Legal. Federal Rule of Evidence 901 requires the proponent to produce evidence sufficient to support a finding that the item is what they claim it is. For a website capture that is usually the testimony of the person who made it, or a description of the system and process that did, plus the when, where and how. The record supplies exactly the facts that testimony needs.

Government and public records. Retention schedules vary by jurisdiction, but the shape is the same: a dated, attributable, complete capture of what the public was shown, kept for the required period, with a history of changes.

The record, as a checklist

• Every capture set has a job record with who started it, when it was created, started and finished, and how it ended.
• The URL set and its source, sitemap or manual list, are recorded with the job.
• The settings the job ran with are snapshotted at creation: widths, above-the-fold and full-page flags, ISI handling, consent path. A later change to the project’s defaults must not rewrite them.
• Every page has its own status, attempt count, duration and captured-at time, and its failure reason if it failed.
• The files are named by page, width and state, and the record maps names to pages.
• Downloads and shares are recorded: who took a copy, when, in which form, and who was given a link, with what permissions and expiry.
• Comments and review decisions attach to the capture they are about.
• Changes to the project, its widths, its settings and its credentials are recorded with actor and time.
• The history survives cleanup of the capture files, so a job that has aged out of storage still shows what ran.
• The whole record can be exported, and the export itself is recorded.
• Retention matches the strictest rule the site falls under.

How RouteShot does it

RouteShot was built around the audit trail rather than adding one afterwards, because the record is the product for regulated review.

• Every job snapshots its settings at creation, including the resolved viewports, the capture flags and the URL source, so later changes to organisation or project defaults do not rewrite history.
• Every page carries its own record: status, attempt, duration, captured-at, assets, and the error when it failed. Failed pages retry on their own and the retry is part of the record.
• The audit trail records what people did, not only what the engine did: capture started, finished, finished with failures or failed; who downloaded which package; who created a share link, for whom, with which role, expiry and view count, and who revoked it; comments on captures; project created, viewports changed, settings changed, credentials updated; invitations and membership; support sessions by RouteShot staff on the account; and audit exports themselves.
• Organisation and project views, filterable by action, with export. Members see the projects they belong to; admins see the organisation.
• History survives asset cleanup. When capture files age out of storage the job and page records remain.

What RouteShot is not: a certified forensic capture service, a write-once archive, or a system that signs captures. Where a matter needs an affidavit, the record gives the person who ran the capture the facts to swear to. Where a firm needs 17a-4 storage, the record is the input to the archive, not the archive.

If your reviewers are asking what was live on a date and the honest answer today is a folder, request access and we will run one of your sites so you can see what the record looks like.

Sources

• FDA, Providing Regulatory Submissions in Electronic and Non-Electronic Format: Promotional Labeling and Advertising Materials for Human Prescription Drugs, April 2022, section VI.E on websites: first use, updated pages with cross-reference, substantial revision.
• FINRA, Rule 2210, Communications with the Public, paragraph (b)(4) on recordkeeping.
• SEC, Amendments to Electronic Recordkeeping Requirements for Broker-Dealers, October 2022, and the staff FAQ on the rule amendments, on the audit-trail alternative in Rule 17a-4(f).
• Federal Rule of Evidence 901, authenticating or identifying evidence.
• Norton Rose Fulbright, Using screenshots from the Wayback Machine in court proceedings.

Written by the RouteShot Editorial Team from primary sources, cited inline. How we write and review guides · Report an error