Website archiving for compliance: what a timestamped snapshot needs to hold up

Website archiving becomes a compliance problem the first time someone outside your company asks what a page said on a specific date. A regulator examining marketing claims, opposing counsel in discovery, an auditor testing your records program: none of them will accept "the site looks like this now" as an answer. And the screenshot someone remembered to take, sitting unlabeled in a shared drive, is barely better. This post is for the legal-ops and compliance people who own that question. It covers what a web archive has to be able to prove, the concepts a program gets measured against, and what to demand from any capture method before you rely on it.

Why website archiving is different from document retention

Most retention programs grew up around documents that hold still: contracts, emails, filings. A web page is the opposite. It changes without notice, renders differently for different visitors, and leaves no trace of its old self when it changes. Your CMS history is not an archive either: it stores templates and content fields, not what a visitor actually saw once scripts ran, prices loaded, and banners displayed. If your pricing page, product claims, terms of service, or disclosures live on the web, the only reliable record of what they said is a capture made at the time, by a process you can describe.

Regulated industries already know this. Broker-dealers preserve business communications, including websites and social posts, under SEC and FINRA recordkeeping rules that require tamper-resistant storage. Pharmaceutical and medical device marketers archive promotional pages for regulator review. Financial promotions regimes in the UK and EU carry similar expectations. But you do not need to be in a regulated industry to need this: any company that publishes prices, guarantees, or terms is one dispute away from wishing it had a dated copy.

The concepts your archive will be measured against

E-discovery and preservation

When litigation is reasonably anticipated, a duty to preserve relevant evidence attaches, and that includes relevant web content. In discovery, you may be required to produce what your site said during the period in question. If no archive exists, you are reconstructing from memory, backups never designed for this, or third-party crawls you do not control.

Legal hold

A legal hold suspends normal deletion for material relevant to a matter. Your archiving system must be able to exempt specific captures from retention schedules and keep them until the hold lifts. If your "archive" is a folder someone tidies up quarterly, you cannot honestly say a hold is enforced.

Spoliation

Spoliation is the destruction or alteration of evidence someone had a duty to preserve, and courts can sanction it with adverse-inference instructions or worse. A site redesign that quietly wipes the old pages during active litigation is a spoliation problem. Routine, documented, schedule-driven archiving is the defense: it shows content was preserved and disposed of by policy, not by convenience.

Authentication under FRE 901

Under Federal Rule of Evidence 901, whoever offers a web capture as evidence must show it is what they claim: that this content really appeared at this URL on this date. In practice that means testimony or system documentation about how the capture was made, when, and how it has been protected from alteration since. A capture with an embedded timestamp, source URL, and a content hash computed at capture time gives a witness something concrete to stand on. An unlabeled screenshot gives them a shrug.

Retention schedules

Keeping everything forever is its own liability; old content is discoverable too. A defensible program assigns retention periods by content type, marketing claims kept for one period, terms and disclosures for another, disposes on schedule, and documents both. Your archiving tool has to let you set and prove those periods; our website archiving page walks through how retention control should look in practice.

What a compliance-grade snapshot needs

Strip away vendor language and a defensible capture has five properties:

• A capture method you can explain. Someone may eventually have to describe, on the record, how the snapshot was made. "A real browser rendered the page and the system saved the result" is explainable. A pipeline of hand-run tools with undocumented settings is not.
• A trustworthy timestamp. Recorded by the capture system at capture time, stored with the record, not inferred from file metadata that changes on every copy.
• Integrity you can verify. A cryptographic hash computed when the capture is made, so you can demonstrate the record has not been altered since. Regulated recordkeeping goes further and requires storage that prevents alteration outright.
• Retention and hold you control. Schedules by content type, deletion that happens by policy, and the ability to place holds that override the schedule.
• Fast retrieval. An archive you cannot search or export under a discovery deadline fails at the moment it exists for. Retrieval by URL and date range is the baseline.

Comparing capture methods

Method	Reliable timestamp	Integrity evidence	Retention control	Scales past a few pages
Manual screenshots	No	No	No	No
Print-to-PDF by hand	Weak	No	No	No
Public web archives	Yes	Some	None (not your system)	Coverage is unpredictable
Self-hosted crawler (WARC)	Yes, if built	Yes, if built	Yes, if built	Yes, with engineering staff
Archiving API / managed service	Yes	Yes	Yes	Yes

Two of these deserve a closer look. Public archives like the Wayback Machine are valuable, and courts have accepted their captures with proper foundation, but you cannot control what they crawl, when, or whether a capture exists for the date you need, and pages behind logins or heavy scripts often render incompletely. They are a supplement, not a program. Self-hosted crawling with the WARC format is the archivist's gold standard and genuinely works, but you inherit the same headless-browser operations burden engineering teams complain about in the rendering world, plus storage integrity and retrieval tooling. Our post on self-hosting versus using an API covers what that fleet really costs to run.

PDF as the archive format compliance actually uses

Archivists prefer WARC because it preserves the raw responses. Compliance work, in practice, runs on PDF: it is what you attach to an audit response, hand to outside counsel, or put in front of a witness. A page frozen as a PDF, paired with capture metadata (URL, timestamp, hash), is legible to every stakeholder without special software. The weakness of PDF-only workflows has never been the format; it is that ad-hoc conversion records nothing about its own provenance. A person pressing Ctrl+P produces a document, not a record, which is why we wrote a whole post on keeping a dated copy when you convert a web page to PDF. The fix is to make the capture system stamp and store the metadata itself, every time, with no human in the loop to forget.

Questions to ask any website archiving vendor

• How is the page captured, and could you explain it to a court? A real browser render is the defensible baseline; see how our capture flow is designed for the shape of a good answer.
• Where do timestamps come from, and can they be altered after the fact?
• Is a content hash computed at capture time, and can I export it with the record?
• Can I set retention by content type, and place legal holds that override deletion?
• How fast can I retrieve and export everything for one URL across a date range?
• How is the archive protected: encryption, access control, tenant isolation? A vendor should answer this in writing, the way we do on our security page.

Where Sitepdf fits, stated honestly

Sitepdf is being built on one idea: the render and the record should be the same event. It is an HTML to PDF API where every render is also archived as a timestamped snapshot with retention you control, so the invoice, the terms page, or the marketing claim becomes a retrievable record the moment it becomes a document. We are in early access: the API is not live yet, there are no customers to point to, and we hold no certifications to wave around, so we will not claim any of that. What exists today is a free in-browser converter and a planned pricing page where archive retention scales by tier up to multi-year periods with legal hold in the enterprise plan. If you are the person who owns this problem, early access is how you get a say in what the retention and hold controls look like before launch.