Dates and Discoverability

Every article on this site can carry a date. None of them currently show one, no sitemap entry claims a modification time, and nothing emits structured data. That's the default state of a Docusaurus docs site, and it turns out to be a real decision rather than an oversight — because the two channels I care about want opposite things.

The conflict

Classic search punishes visible staleness. A reader scanning results treats "2025" as "probably obsolete," whether or not the content changed. The strongest public evidence is a single case study — 13.37% organic traffic lost within a week of exposing publish dates, recovered on rollback. One site, one query mix, no methodology published. Directionally plausible, evidentially thin.

AI search rewards recency, harder than classic search does. Ahrefs' data has AI-cited content running 25.7% fresher than organic results, with ChatGPT citing URLs roughly 393–458 days newer than what ranks. The GEO vendors claim much more — half of citations under 13 weeks, 3.2× for sub-30-day pages, Perplexity weighting freshness at 40% — but those firms sell freshness services and none publish methodology. The direction survives the discount; the magnitudes don't.

So: showing a date may cost clicks in one channel and win citations in the other, and the evidence on each side is asymmetric in quality.

Why the obvious experiment doesn't work

The instinct is: turn dates on, watch the traffic, turn them off if it drops.

That can't be measured with the tooling here. Click-through rate is clicks divided by impressions. Plausible only sees people who already clicked — it has no concept of an impression, because it's a page-load counter. The denominator lives in Google Search Console, which this site isn't verified with.

Worse: Search Console does not backfill. Not one day. Every day it isn't verified is search data permanently gone. That makes verification urgent independently of this experiment — the baseline has to exist before the change, and the baseline can only start accumulating once verification happens.

There's a second problem, which is honesty about power. Traffic here is modest. A site-wide before/after comparison would be confounded by everything that moves in the meantime: new articles published, seasonality, algorithm updates, one post doing well on social. At this volume the effect being looked for is smaller than the noise.

A design that might survive contact with the data

The site runs separate docs plugin instances per section — technical/, not-technical/, projects/ each have their own. showLastUpdateTime is set per instance, not globally.

That allows a difference-in-differences design instead of a before/after:

• One section shows dates, another doesn't, over the same period.
• Each section is compared against its own prior trend, not against the other.
• Anything that moves both sections — an algorithm update, a seasonal dip, a viral post — cancels out.

It isn't a clean randomised trial. The sections aren't equivalent populations and never will be: technical/ gets different queries than not-technical/. But differencing against each section's own baseline removes the confounds that would otherwise dominate, which is the difference between a hard experiment and a meaningless one.

What's being done now, and what's waiting

Some of this doesn't need the experiment to resolve, because the upside is better-supported than the downside and carries no visible-date exposure:

Doing now:

• Populate a real published field. Correct regardless, and prerequisite to everything else.
• last_update.date means meaningful content revision going forward, per ARTICLES.md. Historical values are mostly a bulk tooling run and are not publishable claims.
• Structured data with honest datePublished and dateModified. Machine-readable, feeds the AI-citation channel, no CTR exposure.

Deliberately not doing:

• Visible dates. The only piece carrying real downside, and the thing under test.
• Sitemap lastmod. Google treats sitemap dates as binary trust — accurate enough to use, or ignored entirely. One bad batch and the signal is gone silently, so this waits until the dates have been honest for months.
• Any update treadmill. Publishing new articles is already the freshness engine here; a new article is fresh by definition, and it doesn't require pretending an old one changed.

Blocked on:

• Search Console verification, for impressions.
• Enough post-verification baseline to difference against. Realistically a quarter.

Prediction, recorded before the data

Writing this down now so it can be wrong later.

I expect visible dates to be net negative on this site, and for the reason to be about content type rather than search mechanics: most of what's here is explanation that doesn't decay. A piece on why a zone apex can't hold a CNAME is as true next year as today, but a 2025 date makes it look stale, and the AI-citation upside won't recover the loss because those systems are reading the date and correctly concluding the page is a year old. Freshness signals reward publishing, not re-dating — and the answer for evergreen writing is to publish more, not to claim it changed.

Low confidence. That's why it's a test.

Next check

2026-11-09. By then: Search Console verified with roughly a quarter of baseline, structured data live, published populated. At that point the split becomes runnable.