A webpage can have several legitimate dates: original publication, a substantive content update, a server file modification and an archive capture. They describe different events. Start with the publisher's visible date and revision history, then compare other evidence. If the original date cannot be established, say so rather than treating any timestamp as the answer.
What each date can tell you
| Signal | What it describes | Limit |
|---|---|---|
| Visible publication date/byline | The publisher's statement of when the content was published. | Can be missing, ambiguous or incorrect. |
datePublished | Structured metadata asserting publication date. | Publisher-supplied; not independent proof. |
dateModified | Structured metadata asserting modification date. | Does not necessarily identify the first publication. |
HTTP Last-Modified | The server's reported last modification time for the resource. | Can reflect deployment/file behavior rather than an editorial event. |
| Archive capture timestamp | When the archive captured the resource under its process. | Not automatically the creation date or a complete record of all earlier versions. |
An original timeline example
Suppose a page displays “Published March 3; updated April 10.” A server header says May 1, and an archive has a March 6 capture. The simplest evidence-aware account is that the publisher states March 3 as publication and April 10 as an update, with a capture showing a version was available by March 6. The May 1 header might reflect later resource maintenance; it does not automatically move the original publication to May.
These are hypothetical dates, not a forensic conclusion about a real publisher. If the visible text and metadata conflict, record the conflict and inspect the revision history or ask the publisher instead of silently choosing whichever date suits your claim.
A practical checking sequence
- Read the visible title/byline area, footer notes and any changelog.
- Inspect structured metadata for publication and modification fields, while treating it as a publisher assertion.
- Compare archived versions and note the first capture you actually found, not a claimed first-ever appearance.
- Check whether a cited document has its own original date independent of the page hosting it.
- Record the URL, access date, inspected version and unresolved uncertainty.
Why a missing archive capture proves little
Archives do not capture every URL at every moment. Robots restrictions, dynamic content, access limits and collection choices can create gaps. A resource absent from one archive search may still have existed. Conversely, a captured page can include references to older dates that are claims within the page, not independent evidence that the same content was public then.
Use the date appropriate to the question
If you are asking what a company announced, seek the dated announcement itself. If you are verifying what guidance a reader could see on a historical day, inspect a suitable preserved version and its limits. If you are citing current guidance, record access and any relevant update date. A search-result date alone is a weaker basis for a historical assertion than the source and its version trail.
For publishers maintaining an article
Keep the original publication date. Use a modification date for a real content change and make substantive corrections understandable to readers. Do not stamp the current date onto every response or deploy merely to look fresh. The revision-record guide gives a practical change trail; the citation guide helps record which version supports a claim.