A product site with a settled marketing layer has a freshness problem it did not choose. The pages are correct, nothing about them changes, so the sitemap reports that nothing changed and no page carries a date. Check D4 reads that as a site that might be abandoned, and a model deciding whether to cite the site has no way to read it differently. The cheapest thing that fixes both halves is a changelog: a page of dated entries saying what shipped and why. This post is about what makes a changelog count as a signal rather than decoration, how D4 actually treats it, and what ours looks like.
What D4 needs from it
The full mechanics of D4 are in the freshness signals post. The short version is that the check has a sitemap half and a page half. The sitemap half wants lastmod values, with at least a fifth of the file's URLs dated within 90 days of the scan. The page half wants a machine-readable date in the raw HTML of at least one crawled page, and it tests for that with a string match: a time element carrying a datetime=" attribute, or the literal "datePublished" or "dateModified" as they appear inside JSON-LD.
A changelog entry written as
<li>
<time datetime="2026-10-03">3 October 2026</time>
<p>Webhook deliveries now retry three times with backoff. Previously a single 5xx from the receiver dropped the event.</p>
</li>
passes the page half on its own. The same entry with the date in a heading, <h3>3 October 2026</h3>, does not, because the check does not read prose and has no idea that the heading is a date.
Where the crawler looks
The page half only sees pages the crawler fetched, and the free scan fetches six: the homepage, then up to five chosen from the sitemap and the homepage's links. Paths under pricing or plans come first, then product, shop or collections, then docs, then about or company, then contact, then cart or checkout, and only after those does the crawler fill remaining slots with other candidates, shortest URL first. A /changelog path is not in the preferred list. Whether it makes the cut depends on how many preferred pages the site has and what other short paths compete with it, which is not something to gamble a point on.
Two things remove the gamble. Put the latest two or three entries on the homepage, with their time elements intact, as a short list of what is new. Or carry a dateModified in the sitewide JSON-LD, which is what we do, so that every page has a date whichever six are picked. The changelog page is still worth having: it is the page a retrieval crawler indexes and a person reads. The homepage strip is the part that makes the signal certain.
The sitemap half
A changelog also moves the sitemap half, but the arithmetic matters. If the changelog is one page whose lastmod advances with each entry, it is one recent URL in a file of many, which on a thirty-URL site is 3% towards a threshold of 20%. Useful, not sufficient.
If each entry is its own URL, the arithmetic changes. A release note at /changelog/2026-10-03-webhook-retries is a new page with a true lastmod on the day it was written, and it stays within the window for 90 days. A team shipping every fortnight adds about six such URLs a quarter, which alone clears the threshold on a file of up to thirty URLs; a team shipping weekly clears it on a file of up to 65. The index page's date should advance too, since it did change. Two things not to do: backfill old entries with invented dates, and stamp the whole file with the build time, which the freshness post covers and which is worse than leaving the field out.
What an entry needs
Four things, none of them expensive.
A date a machine can read. The time element with an ISO datetime attribute, one per entry. The visible text can be in whatever format the audience expects; the attribute is the part the check and every other machine reads.
A stable URL on your own origin. A changelog that lives in a hosted widget injected by script, or an embedded document from a notes tool, is content that exists only after hydration. A plain fetch of the page returns a container and nothing in it, and the check, like every crawler that does not run JavaScript, sees no dates. Render the entries into the HTML.
The reason, not only the change. "Performance improvements" is noise. "Search results now come from the read replica; p95 latency on the search endpoint dropped from 900ms to 120ms" is something a reader can weigh, and a reader includes a model asked whether your product does a particular thing as of a particular month. The entries a model can cite are the ones that say what changed, when, and why.
Entries that are never rewritten. Append at the top; leave the rest alone. A changelog whose past entries change is not a record, and the value of the page comes from being one. This is the same rule we apply to scores, and the same argument is in why we publish the rubric.
A version number or identifier is worth adding where the product has one, and it is what most consumers will key on, but the date is the part D4 reads.
Ours
Our changelog is for the rubric rather than for a product, and it sits at the foot of the methodology page at /methodology#changelog. It is rendered from the CHANGELOG array in the rubric source, the same file that defines every check the engine runs, so an entry cannot appear on the page without existing in the code that scores. Each entry carries the version in monospace, the date in a time element with a dateTime attribute, and a note.
As of this writing there are two entries, both dated 2026-08-07. The first records the initial published rubric: four pillars, 25 points each, 27 checks. The second records v1.0.1, which changed B5, the clean text ratio, to exclude the contents of script and style elements from its denominator. The note gives the reason: auditing our own homepage found that the server-rendering framework inlined a serialised payload duplicating the page text, which was 60% of the document, so measured against total bytes the check penalised precisely the architecture that A7 rewards. It was measuring framework choice rather than markup quality. The note ends by saying that scores issued under v1.0.0 are not restated.
That is the shape we are recommending: version, date, what changed, why, and what was not touched. Two entries is short, and a short changelog that is true is worth more than a long one padded to look busy. It will grow as the rubric does.
We do not rely on the methodology page being among the six crawled, for the reason given above. The WebSite block on every page carries a dateModified from the same content date the sitemap uses, and blog posts add their own time elements and Article dates, so the page half of D4 holds whichever pages are picked. The changelog is there because a rubric that changes without a record would not be worth publishing.
Check your own site
If you ship regularly and your site says nothing about it, you are paying for the silence on D4 and in every decision a model makes about whether your site is current. The free scan reports visibleDates and the sitemap counts under D4, the check is defined under trust and freshness, and monitoring re-scans on a schedule so a changelog that stops does not go unnoticed.