7 ways to timestamp a competitor's change

You found it. The pricing page has a new tier, or the homepage headline reads differently than you remember, or a feature you'd never seen is suddenly in the nav. Good. Now answer the harder question: when did that happen?

Because the answer changes what you do next. A change made eleven months ago is history — interesting context, no urgency. The same change made nine days ago is a live event that probably explains the two deals you just lost. Same artifact, completely different meaning, and the only thing separating them is a date you don't have yet.

Here are seven ways to get that date, roughly in order of how quickly they pay off.

1. The sitemap's lastmod field

Start here, because it takes fifteen seconds. Most sitemap.xml files carry a <lastmod> timestamp per URL, and plenty of CMSs populate it honestly without anyone on the marketing team realizing it's public.

Pull the sitemap, find the URL you care about, read the date. Two caveats: some platforms stamp every URL with the build date, which makes the field useless, and some omit it entirely. You'll know within one look which kind of site you're dealing with. When it works, it's the cheapest timestamp in this list — and the sitemap is worth reading for the pages nobody announced anyway.

2. RSS and Atom feeds

Blogs, changelogs, release notes, and status pages very often still publish a feed, even when the company has forgotten it exists. Feeds carry <pubDate> or <updated> per entry, and unlike a marketing page, those values are generated by the system rather than written by a person.

The changelog feed is the high-value one. It gives you a machine-readable, dated record of what shipped and when, which you can line up against everything else you've noticed. RSS is the monitoring tool everyone forgot, and the timestamps are half of why it's worth remembering.

3. HTTP response headers

Request the page and look at what comes back before the HTML does. Last-Modified gives you a literal date on static assets and some cached pages. ETag doesn't give you a date, but it gives you an identity — if you record it now and it differs next week, something changed in between, even if the visible copy looks identical.

This is weakest on modern sites, where a CDN rewrites headers and everything looks freshly generated. Try it anyway; it costs one request. Where it does work — PDFs, images, downloadable assets, older doc sites — it's precise in a way nothing else on this list is.

4. Wayback bracketing

The Internet Archive won't tell you exactly when a change happened, but it will tell you a window, and a window is usually enough. Find the most recent snapshot showing the old version, find the earliest snapshot showing the new one, and the change lives between them.

Binary-search the snapshot list rather than scrolling it. On a well-crawled site you can narrow eleven months down to a nine-day window in about four clicks. On a thinly-crawled one you may get "sometime last quarter," which is still far better than nothing. There's more on this technique in Wayback pricing archaeology.

5. Build IDs and asset hashes in the page source

View source and look at the script tags. Most modern frontends ship filenames like main.4f7a2c.js or embed a build ID in the page. Those strings are meaningless on their own — but recorded over time, they're a perfect change detector for the parts of a site that don't announce themselves.

A shifted bundle hash with no visible copy change usually means a deploy touched functionality rather than marketing. Sometimes it's the earliest evidence you'll get that something is being built, weeks before it appears in the nav.

6. Job posting dates, including the reposts

Job boards timestamp everything, and the timestamps are honest because they're operational rather than promotional. A role posted eight weeks ago that just got reposted tells you the search is struggling. Three roles opened the same week in one function tells you a budget cleared on a specific date.

Read hiring as a clock, not just a signal — the when is what lets you connect an org change to a product change you spotted elsewhere. We covered the signal itself in hiring as a leading indicator; the dates are what make it stitchable to everything else.

7. Third-party timestamps you don't control

When the competitor's own surfaces are silent, other people's aren't. Review sites date every review. Reddit and Slack communities date every complaint. App stores date every release. Support forums date the moment users started asking about the thing.

These rarely date the change itself — they date the moment it became visible to customers, which is often the number you actually want. If the first "has anyone else noticed the new limit?" thread appeared on a Tuesday, the change shipped shortly before that Tuesday, whatever the marketing page implies.

The version of this that doesn't require archaeology

Every technique above is reconstruction: you noticed something late, and now you're working backwards to figure out when it happened. That works, but it's lossy, and it only works for changes obvious enough to notice at all.

The alternative is having the date because you were watching when it happened. That's what continuous monitoring is for — Seeto checks public surfaces on a schedule and records each diff as a discrete, dated change event, so the timestamp is attached from the start instead of reconstructed afterward. Worth being clear about the limit: it dates what it's watching, from the day it starts watching. It can't retroactively date a change from before that, and it won't tell you what the change means — that judgment stays yours. For anything already in the past, you're back to Wayback and sitemaps, which is precisely the memory problem these tools exist to solve going forward.

The habit worth building is small: whenever you record a competitor change, record a date next to it, even an approximate one. "Sometime in Q2" beats no date at all. A file of undated observations isn't intelligence — it's just a pile of screenshots that can't be argued with or acted on.