The 10-Month Problem: How Stale B2B Case Studies Really Are

The bigger problem with B2B case study freshness is not that stories are old. It is that 64.2% of them (215 of 335 companies we could open a story for) carry no verifiable publish date at all, so a reader has no way to judge their age either way. Among the 35.8% that do carry a real date, the picture our Customer Proof Index already reported holds: a median age of 9.9 months, and 44.2% untouched in over a year. This post is the deep dive on that finding: what the two extremes actually look like by name, and how to tell whether a case study you are reading is current at all.

The short version of how we measured it

This is a companion piece to our post on what's actually inside a published case study, which first reported the 120/9.9-month/44.2% figures and the reasoning for excluding server and sitemap timestamps from a freshness claim (a redeploy touches those regardless of whether the story itself was edited). We will not re-derive that methodology here; read the companion post for the full case-by-case reasoning. What follows takes those same 120 dated companies and the 215 undated ones and goes further: by name, by category, and from the perspective of someone reading a single case study rather than auditing their own library.

The number that matters most: two in three case studies carry no date at all

Read the top two rows before the bottom two. The more common failure in B2B case studies is not staleness. It is the absence of any date at all, which means a reader (or an AI answer engine deciding whether to cite the story) has no way to tell whether what they are reading is nine months old or five years old. Staleness is what we can measure among the minority of companies that told us how old their story was.

What 9.9 months and 44.2% actually look like

The median matters less than the range around it. At the fresh end, several companies in our crawl had a story dated the same day we measured them: Recruitee's story about Keolis, and Verizon Connect's about Green Mountain Communications, were both published 2026-08-21. At the stale end, Helpjuice's oldest dated customer story traces to 2011, nearly 15 years before our crawl; Cognito Forms and Trademetria both carry newest dated stories from early 2018. A reader landing on either extreme has no way to tell which one they are looking at unless they check the date themselves, and per the finding above, most companies do not even give them that option.

We also checked whether staleness clusters by category the way the existence gap does (see our companion post on IT, dev and security benchmarks). It does not, at least not reliably: only 120 companies across all 55 categories carry a verifiable date, an average of about 2 per category, too thin to responsibly report a per-category median without it being driven by one or two outliers. That thinness is itself worth stating plainly rather than forcing a number that would not hold up: we can say with confidence how stale the dated minority is; we cannot yet say which industries are worse, because too few companies date their stories for the comparison to mean anything.

What the two ends of the range actually look like

The stale end is not a rounding artifact. Helpjuice's oldest verifiably dated customer story predates the company's own product maturing into what it sells today, and it is still the newest dated story on the domain we could find at crawl time; there may be a more recent one that simply carries no machine-readable date, which is exactly the ambiguity this whole post is about. A reader cannot tell the difference between "this is genuinely the newest story" and "this is the newest one we could date" without checking by hand.

How to tell if a case study you're reading is actually current

This cuts both ways. If you are the one evaluating a vendor's case study rather than publishing your own, five checks take under a minute and tell you more than the story's tone does.

Look for a visible date near the headline or the byline. Its absence is common (64.2% of the stories in our crawl had none), so treat a missing date as unknown, not as necessarily old.

If there is no visible date, view the page's source and search for "datePublished." Many sites include a machine-readable date in the page's structured data even when they do not show one to a human reader.

Check whether the product names, integrations, or pricing mentioned in the story still exist. A story praising a feature the vendor has since renamed or deprecated is a more reliable staleness signal than any date field.

Search for the quoted person's name and current title. If they have moved to a different company or a different role, the story is at minimum old enough that the relationship it describes may no longer hold.

Treat a vendor's own "recently updated" or "fresh case studies" claim with the same skepticism this post applies to modified timestamps. A page can be technically re-touched (a redesign, a template change) without the underlying story being re-verified with the customer.

Why a date is worth adding even if no customer ever asks for one

A visible, machine-readable date is mostly a courtesy to a skeptical reader, and that is reason enough on its own. A buyer doing due diligence on a vendor treats a dated, recent story as a live claim they can weigh, and an undated one as a claim they cannot place in time at all. That difference shows up before any question of search visibility: it is the difference between "here is evidence this still holds" and "here is evidence that held at some point." The fix costs a single structured-data field, not a rewrite, which is a low price for closing a gap this consistent (64.2% of the case studies in our crawl never pay it).

Why so few B2B case studies carry a real date

A case study is usually written once and then left alone. Unlike a blog post, nobody is assigned to revisit it, and most case study page templates were built around answering "is this credible" rather than "is this current," so a visible, machine-readable date was never a design requirement. The practical effect is that a case study page can sit unedited for years while looking exactly as fresh as the day it was written, because nothing on the page tells a reader otherwise. Our companion post on how many case studies a B2B site needs covers the quantity side of this problem; staleness is the quality side of the same neglect.

What to do about it

If you publish case studies yourself, our companion post already covers the specific fixes: add a JSON-LD datePublished field, and treat a library over a year old as a reason to have a new conversation rather than republish an old one. What that post does not cover, and what this data changes about the advice, is the scale of the problem underneath it. Dating your stories correctly only helps once you already have recent ones to date. The harder constraint for most teams is not the markup, it is finding the hour with a willing customer often enough that "over a year old" never becomes true in the first place.

If that cadence is the part that keeps slipping, that is what we built done-for-you case studies for: a fresh interview and a fresh, dated publish on a schedule you set, without a single case study landing on your own team's desk to write.