Twelve company blogs, and only half of them ever tell a search engine that a piece was updated

Content refreshing is the cheapest growth in editorial work. A piece that already ranks needs a fraction of the effort a new one does, and it starts from an established position rather than from nothing.

The catch is that a refresh only counts if somebody notices. So I went to check whether company blogs actually tell anybody.

What I measured

Twelve article pages from twelve well known software companies, fetched directly, parsed for three things:

• a <time datetime="…"> element,
• datePublished inside JSON-LD structured data,
• dateModified inside the same.

The first two say when a piece appeared. The third says when it last changed, and it is the one this article is about.

The result splits cleanly in half

Publishing a date is close to universal practice. Nine of twelve do it, and most use JSON-LD rather than a time element, which is the modern convention and perfectly fine.

Then half of them stop.

Six of these twelve teams can rewrite an article completely and emit nothing that distinguishes the new version from the old one. The change exists for a reader who happens to return. For everything automated, the page is what it was.

Why the second field is the one that pays

Editing an article without touching dateModified produces a specific, quiet failure.

The crawler has no reason to hurry. Recrawl frequency is driven partly by how often a page changes. A page that never announces a change gets visited on the schedule of a page that never changes, which is the schedule you were trying to escape.

The result keeps the old date. Search results sometimes show a date. Without a modified date, the date shown stays the original, and a reader deciding between your 2023 piece and a competitor’s 2026 one is not making a judgement about quality.

Your own reporting goes blind. Half of content work is knowing which pieces were refreshed and when. Teams without the field usually cannot answer that from the site itself, and end up maintaining a spreadsheet that drifts.

The listings are much worse, and it matters less

Before checking article pages I checked eighteen blog index pages. Only four carried any machine readable date.

That sounds alarming and mostly is not. A listing is navigation. The page that gets indexed, ranked and shown is the article, and article pages performed far better: 75% against 22%.

It is worth knowing, though, if you use your own listing as a source for anything. A content audit that reads the blog index to find stale pieces will conclude that most of the archive has no date at all.

The three with nothing

Three article pages emitted no date anywhere I could find: no time element, no structured data, and no visible date in the body.

That is a deliberate choice more often than an oversight. Removing dates is an old tactic for making evergreen material look timeless, and it does work on a reader who never wonders.

It also removes your ability to prove freshness later. When two pages answer a question equally well and one can demonstrate it was reviewed this year, the timeless one is not winning that comparison, it is simply not entering it.

What to do about it, in fifteen minutes

Check what you emit. Open any article, view source, and search for dateModified. Present or absent, that is your answer.

Add it next to what you already have. Almost every CMS stores a modified timestamp already. Emitting it is one line beside the datePublished you are already outputting.

Set it on real edits only. A build that stamps every page with today’s date on every deploy makes the field meaningless, and it is a common bug in static sites where the timestamp comes from the file system rather than the content.

Do not move the publish date. Keep both. The original tells a reader how long this has been your position, the modified date tells them you still stand behind it. Overwriting one with the other loses information for no gain.

Where this measurement is thin

Twelve pages, one per company, chosen by taking the first article link the index page offered. A different article from the same blog might behave differently, particularly on sites where old and new templates coexist.

Two blogs could not be checked at all: their listing pages build the article links with a script, so a plain fetch finds nothing to follow. That is its own editorial finding, and a different article.

Questions people ask about this