What First Seen and Last Seen Actually Mean

“First seen” is the date a vendor’s crawler first observed a link. “Last seen” is the most recent date its crawler observed the link still present. Neither is the date the link was published, and neither is the date it was removed. They are timestamps about crawling.

Treating them as publication and removal dates is the single most common way link trend charts end up describing crawler behaviour instead of link acquisition.

The gap between discovery and publication

A link exists from the moment it’s published. The vendor learns about it whenever its crawler next fetches the page, which depends on the page’s crawl priority, whether the page is linked from anywhere the crawler visits often, whether it’s in a sitemap the crawler consumes, and how much budget the vendor allocates to that neighbourhood of the web.

The lag is real, variable, and undocumented. For a link on a high-traffic news homepage it may be hours. For a link in a paragraph of a five-year-old blog post on a small site, it may be months — and the “first seen” date will then be months after publication.

Two consequences:

Your “new links this month” is really “links discovered this month.” Some of them are old. This is why an unchanged link programme can produce a spiky discovery chart.

A campaign’s links arrive in your data over a long tail. If you placed twelve links in June and see seven in June’s data, the other five are not missing. They’re probably not crawled yet. Reporting seven as the outcome, in June, understates the campaign — and re-reporting in August double-counts if you’re not careful.

The gap between last seen and removal

Symmetric, and slightly worse.

“Last seen” only updates when the crawler revisits. So a link that was removed the day after its last crawl looks alive until the next fetch, and for low-priority pages that can be a long time. Your live-link count includes an unknown number of dead links.

Vendors also apply retention policies: how long a link stays in the index after it stops being observed, whether it’s marked lost immediately or after N failed checks, and whether it’s ever purged. These policies differ, they change, and they are part of why two indexes report different totals — the mechanism in why two tools report different backlink counts.

The practical rule: “last seen” is a lower bound on the link’s lifetime, never an endpoint. If last seen is three weeks ago, the link may be alive, dead, or behind a fetch error. The only way to know is to open the page, as set out in lost-link reports and index churn.

What the timestamps are good for

They are genuinely useful for three things, all of them relative rather than absolute.

Ordering. Within one index, first-seen dates put links in a reasonable sequence. The absolute dates are wrong; the order is mostly right.

Detecting clusters. A large group of links sharing a narrow first-seen window is informative — it usually indicates a syndicated piece, a widget, a scraper, or a batch that was created rather than accumulated. Uniform timing is a pattern-level signal in exactly the way uniform anchors are, per anchor text distribution as a dataset.

Confirming a specific link’s discovery. For a placement you’re tracking, first-seen answers “has the vendor found it yet,” which is a real question with a real answer.

What they’re bad for

• Attributing links to a time period for reporting. The period boundary is a crawl artefact.
• Computing link velocity. Velocity computed on discovery dates measures crawl throughput as much as acquisition. This is one of the reasons velocity misleads — see link velocity and other metrics that mislead.
• Establishing that a link existed before a ranking change. The dates are too soft to support a before/after argument, which matters a lot for the attribution problem in how to tell whether a link did anything.
• Comparing across vendors. Two indexes’ first-seen dates for the same link differ by whatever the difference in their crawl schedules is. Aligning them is not possible.

How to report link timing honestly

Use “discovered” not “acquired” or “built.” One word change, and it’s accurate.

Report verified placements separately from discovered rows. If your team placed or earned specific links, you know their real dates. Report those from your own records, with the source URL, and treat the index as confirmation of discovery rather than as the record.

Give the window and the vendor. “Links first observed by [vendor] between 1 and 22 July” is checkable. “New links in July” isn’t.

Don’t chart discovery weekly. The noise at weekly granularity is mostly crawl scheduling. Monthly is defensible; quarterly is more honest for most sites.

A hypothetical illustration of the distortion: a site earns roughly four links a month, steadily. Its discovery chart shows 2, 11, 1, 6, 3, 9 across six months. Nothing about the acquisition rate varied; the crawler visited a cluster of relevant pages in month two. Anyone reading that chart as performance will draw six wrong conclusions. (Illustrative figures, not measurements.)

What nobody outside the vendors knows

The distribution of discovery lag — how long, on average, between publication and first seen, and how it varies by site type. Retention policy specifics. Whether last-seen updates on every fetch or on a schedule. Whether failed fetches update the timestamp at all.

Given that, the defensible framing is narrow and easy to remember: these fields describe a crawler’s history with a page, they bound the link’s real lifetime from the inside, and your own records are a better source for the dates of links you were involved in.