As-of dates: why data freshness belongs on every SEO slide

Your report went out at nine this morning. The Search Console numbers in it describe the day before yesterday, because that source finalizes a day or two late. Nobody wrote that on the page. So for the rest of the week it gets read as this morning's news.

Every number in a search report has an age, and most reports never say what it is. That silence is where the arguments start. Two people pull the same chart on different days, see different numbers, and spend twenty minutes on a gap that was only ever a timestamp.

The fix costs one line. An as-of date: the day the data was last complete, printed beside the number itself.

Every source runs on its own clock

Your connected sources do not age at the same rate. The spread is wider than most teams assume, which means one dashboard view is quietly showing you several different todays at once. Nothing on it is wrong. Something on it is unlabeled.

None of those lags is a defect. Each one is how the source works: an API that finalizes its data after validation, a nightly batch window, a crawl cycle. Print them as facts and they stop being surprises you talk your way out of.

The docs carry the full lag reference, and it repays one team read. Once the lags are shared vocabulary they stop being folklore one person happens to know. The six of them, fastest first:

• Server logs: hours to nightly.
• Web analytics, from GA4 or Adobe: a nightly load.
• CTR-modeled search market share of tracked demand, your modeled share of the clicks available across the keywords you track, and AI visibility: about daily.
• Google Ads: about the same, daily.
• Google Search Console: one to two days behind.
• Core Web Vitals: roughly biweekly for most sites, faster on priority pages.

See also: what the share number covers and what it does not →

Print the date where the number lives

A Monday readout built on Sunday's load should say so beside the number, not in an appendix nobody opens.

The moment that date is on the page, the freshest-data argument dies, and every other claim inherits the credit. It scales down too. A Slack message quoting one number is better for the same five-word suffix, which heads off the whole which-dashboard-are-you-looking-at thread before it starts.

There is a courtesy in it too, and that is the part worth sitting with. A reader who has the date can weigh the number against what they already know about that week. A reader denied it can only trust you or distrust you, with nothing in between. Printing the date is you choosing which of those two you get.

This is the smallest of the labels that tell a reader where a number came from and how fresh it is, and it is the one you reach for every week rather than once a quarter. The article on decks that survive fact-checking covers the rest.

See also: the rest of the labels, on a deck that survives fact-checking →

Freshness is a question you can ask

You do not have to assume. One check reports the latest available date for each connected domain of data. Another lists every feed and how often it loads.

When a number looks stale, asking settles it in about ten seconds. That is faster than the message you were drafting about it.

Freshness also decides how a number should be read. One that looks flat may simply not include yesterday yet. A drop on the most recent day of a lagging source is usually the lag itself, and it fills in by tomorrow. Knowing each feed's rhythm turns both from alarms into non-events.

The full lag table lives in the docs. The rule that matters fits in one sentence: no number leaves the building without its birthday.