Pick any article in your help center and ask it a simple question: when was this true?
It won't tell you. Help articles are written in a permanent present tense. "Click Settings, then Billing." That sentence reads identically whether it was written last week or in 2023, and whether or not the Billing tab still exists.
Now ask the same question of your changelog. It answers immediately, because a changelog is the only thing you publish that's built around a date.
Why that matters more than it used to
A human reading a stale article often notices. The screenshot looks old, the button colour is wrong, something feels off, and they go and check.
A retrieval system notices none of that. It has your confident present-tense sentence about a feature you removed in March, and nothing anywhere that contradicts it. So it answers with it.
Your changelog is the contradiction. It's the one artefact that can say "that changed, here's when, here's what replaced it" — and it's usually the most neglected page you own.
What makes a changelog useful to a machine
Write what changed for the customer, not what shipped. "Improved performance" helps nobody. "Exports now include archived projects" is a fact someone can answer a question with.
Name the thing the way your docs name it. If your changelog says "team space" and your articles say "workspace", you've published a contradiction rather than a correction.
Say what was removed, explicitly. Removals are the entries people skip writing and the ones that matter most. An article describing a dead feature is only detectably dead if something else says it died.
Link to the article you updated. That's the bridge that lets anything following the trail land on the current truth.
The habit, not the project
The useful version of this isn't a beautiful changelog page. It's the five minutes after a release where you write what changed and then go and fix the two articles it just broke.
Most teams do the first half. The second half is where the value is, and it's the part that stops your help center drifting away from your product one release at a time.
Our free prompt for claims that go stale will tell you which parts of an article are most likely to be wrong within a year. The habit matters more than the tool though: five minutes after each release, not two days once a quarter.

