Tell the model how old the page is: fetch timestamps in context

A model reads a fetched page as if it were timeless. Nothing in the Markdown says "read at 09:14 UTC today", so the model cannot tell a page fetched a minute ago from one fetched last month. If the answer depends on a price, a status or a changelog, that difference decides whether the answer is right. The fix is cheap: put the time next to the content, in one format, and say what it means.

Which time to record

There are three candidate times, and only one of them is yours:

• Fetch time. When your app (or your provider) read the page. This is the only time you can vouch for.
• The page's published or updated date. What the page says about itself. Useful, but it is the site's claim, and many pages do not expose one.
• The HTTP Date header. MDN describes it as the time the response was generated. It is close to the fetch time, but it comes from the target server's clock and is not shown to you by every API.

Record the fetch time for every page, and the published date only when the page exposes it.

One format: RFC 3339 in UTC

RFC 3339 defines the timestamp profile most APIs already use, for example 2026-10-27T09:14:05Z. In JavaScript, Date.prototype.toISOString() returns this form, always in UTC with the Z suffix. Use it everywhere: in your logs, your cache keys and the prompt. One format means the model never has to guess whether 10/11 is October or November.

A header block per page

Put a short block above each page's content:

[source 2]
url: https://example.com/status
fetched_at: 2026-10-27T09:14:05Z
country: de
page_published: not stated
---
(page Markdown)

Then give the model today's date once, at the top of the prompt, and one instruction: "Each source shows when it was fetched. If a fact may have changed since then, say when the source was read." That turns hidden staleness into a sentence the user can see.

Common mistakes

• Local time without an offset. 09:14 means nothing without a zone. Always write Z or an offset.
• Using the page's date as the fetch time. A page "updated in 2024" that you read today is a page fetched today with old content. Keep both, labelled.
• Dropping the time when you truncate. If you cut a page to fit a budget, keep the header block.

The live vs cached web data guide covers the freshness decision this timestamp belongs to.

How this maps to Live Web Data API

Each URL in a response has a statuses[].fetchedAt in ISO 8601, set when the page was read, and null when the fetch failed. results[].url is the final URL after redirects, results[].publishedDate is filled when the page exposes one, and countryCode is the country you asked for. Those four fields fill the header block above without extra code. The API reference lists every field.