What an abandoned website reveals
A site left to itself doesn't stay silent. It tells you fairly precisely when it was abandoned, and sometimes why.
I have a habit I can't shake: when a site feels dated, I check when it was last touched. Not to judge — collecting the signals is like a stratigraphic section: each layer was laid down at a different moment, and together they give a fairly accurate picture.
All seven signals below come from the site's public surface: from what the browser downloads anyway. Nothing here involves intrusion, and none is needed.
- surface · year, last post, contact details
- source · version numbers, generator, typefaces
- connections · embeds, certificate, redirects
the three layers can be dated independently
One — the year in the footer
The oldest and least reliable signal. On many sites the copyright year updates automatically, so a current year proves nothing. A stopped year does: it means somebody typed it in, and nobody has been there since.
Two — the date of the last post
The news or blog section. This rarely lies, because nobody writes here automatically. If the most recent entry is years old, that isn't necessarily bad — but then why is the section there. An empty news menu does more harm than no news section would.
Three — version numbers in the source
The most precise of the lot. Most systems append a version number to the URLs of stylesheets and scripts, so that after an update the browser doesn't keep the old copy. It serves cache management — as a side effect it makes the running version readable by anyone.
Combined with release dates, this narrows the last update to a fairly tight window. It's interesting not because it's secret, but because the owner typically has no idea it's visible.
Four — the generator and its era
The tools in use mark a period. Certain typefaces, icon sets and animation libraries date as reliably as the shape of a car. This signal isn't precise, but it gives you the order of magnitude: two years or ten.
Five — the broken embed
The most telling one, because the site didn't break — the world moved on. An embedded map showing a grey rectangle after an authorisation error; a social feed rendering as an empty box; a video that can no longer be played.
This is exactly the kind of failure that arises on its own when nobody touches a site — the subject of a separate piece on what happens to a neglected site.
Six — the certificate and the domain
The certificate's issue date shows whether automatic renewal is running or whether it's done by hand. If a site is live with an expired certificate, then nobody is receiving the expiry notices either — the strongest sign that the system has no owner.
Seven — the contact details
The only non-technical signal, and the one that says most. A dead e-mail address, a disconnected phone number, an old address. At that point the site isn't merely outdated, it misleads — and that is what causes actual harm, not the dated typeface.
One signal alone can mislead: a stale footer year can sit above a well-maintained system. Four or five in agreement are fairly conclusive — and on most neglected sites all seven hold at once.
What this says about the company
Not that they work badly. Behind most such sites stands a functioning, decent business that simply has nobody to turn to: whoever built it left, the credentials were lost, and since then nobody dares disturb it.
What is visible is how far the attention reaches. A site whose expired certificate nobody notices tells you the business receives no signal at all about its own online presence. That isn't negligence — it's a missing system.
The ethical line
All of this is public data: exactly what a browser downloads on every visit. The line is in what you do with it.
For an assessment, for checking your own site, or for understanding where an inherited system stands — entirely fine. As raw material for cold outreach — not: I don't send letters beginning “I looked at your site and saw it was out of date”. This is one of the points where technical possibility and decency part ways.
And your own site?
That's the best use for this list. Open your own site logged out, with a stranger's eye, and go through the same seven. Most sites give themselves away with something the owner hasn't looked at in years — because they always see it logged in, where everything is fine.
Questions on this topic
How can you tell when a website was last updated?
From several independent signals that together are fairly precise: the year in the footer, the date of the most recent post, version numbers visible in the source, the state of embedded services, and when the certificate was issued. One signal alone can mislead; four or five in agreement do not.
Why are plugin version numbers visible from outside?
Because most systems append a version number to the URLs of stylesheets and scripts, so that browsers don't keep using the old copy after an update. It serves cache management; as a side effect it makes the running version readable by anyone.
Is that visibility a security risk?
Visibility on its own isn't a vulnerability: attackers try indiscriminately anyway. The real risk is the outdatedness itself — a public version number merely makes targeting easier. The remedy isn't hiding it but updating.
What should I do about this on my own site?
Go through the same seven signals on your own site, from outside, logged out. Most sites give themselves away with something the owner hasn't looked at in years: an old year in the footer, a last post from two years ago, a broken embed.