How to Prove What a Website Said
By BlockchainSignPublished
Web pages change, and the version that mattered is usually the one that no longer exists. Proving what a page said on a particular date comes up in advertising disputes, contract arguments about published terms, defamation, infringement claims and compliance work — and the usual methods are weaker than people expect.
Why the obvious options fall short
A screenshot is an image file. It can be edited in a browser's developer tools before capture, or in any image editor afterwards, and nothing about it resists either. It is the most common evidence of this kind and among the weakest.
A saved PDF or MHTML captures more, and is equally editable, and carries a date your own machine wrote.
The Wayback Machine is genuinely useful and genuinely incomplete. Coverage is patchy, capture times are irregular, robots.txt and site owners can affect availability, and dynamic content often does not render as it did. It is also outside your control — you cannot make it have captured the page you needed.
Your own backups are yours, which is the problem when the dispute is about your site.
What actually helps
Two things, and they work together.
Capture completely. A screenshot of the visible area is not the page. Capture the full rendered page, the HTML source, the HTTP response headers, and the URL. Include the date and the tooling used. A single-file archive of all of it is easier to handle than loose pieces.
Anchor the capture externally. Hash the archive and record that hash on a public ledger the same day. The capture's date is now fixed by something you do not control, and the archive's integrity is verifiable by anyone.
That combination answers the two questions a challenger raises: has this been edited since, and how do we know when it was made.
| Method | Complete | Tamper-evident | Date outside your control |
|---|---|---|---|
| Screenshot | No | No | No |
| Saved PDF | Partly | No | No |
| Wayback Machine | Partly | Reasonably | Yes, when it captured |
| Notarised capture | Varies | Yes | Yes, at a cost |
| Self-capture plus anchor | Yes | Yes | Yes |
For your own site
The commoner situation, and the easier one. You control the content and you know when it changes.
Timestamp a release archive of the site at each significant change — the same operation as timestamping a software release. That gives a dated record of exactly what was published and when, which covers published terms, pricing pages, claims in marketing copy, and anything else that might later be disputed.
This is worth doing prospectively. Reconstructing what your site said two years ago, after the fact, from backups you control, is exactly the evidence a challenger will decline to accept.
For someone else's site
Capture and anchor immediately, before it changes. Pages come down fast once a dispute starts.
Note what this does and does not establish. It proves that you captured this content on this date. It does not prove the content was genuinely served by that domain — you could, in principle, have fabricated the capture. Strengthening that requires more: an independent witness, a notarised capture service, HTTP response headers, or a corroborating third-party archive.
A capture that also happens to exist in the Wayback Machine is considerably stronger than either alone, which is a reason to submit the URL for archiving at the same moment you capture it.
The honest limit
Anchoring fixes integrity and date. Provenance — that this content came from that server — is a separate question that cryptography does not answer.
For a page you control, that gap barely matters, since nobody disputes that your site is yours. For a third party's page, it is the gap, and the answer is corroboration rather than better hashing.
See how to prove a document is authentic for the same distinction in a different setting.