A changelog page with one entry per release, and a way for users to find it
A changelog page tells customers what changed and when. Done well, it shows the product is alive, cuts support questions after each release and gives you a link to send when someone asks for a fix you've shipped. On Anticode, you keep releases in a CMS collection, so each one gets its own page and the list updates as you add entries. There's no RSS feed, so the link from inside your product matters.
Who reads a changelog
Three groups, each skimming for something different. Existing customers check whether the bug that annoyed them is fixed, or why a button moved. Prospective customers look at the dates to see whether the product is actively maintained. Your own support team uses entries as the answer to "when did this change?". Write for all three: plain language first, technical detail second.
Setting it up as a collection
Create a CMS collection called changelog. Its fields are typed and edited in the dashboard; a practical set:
- Title
- A short summary of the release in user terms: "Recurring invoices and faster exports".
- Date
- The day it shipped. Readers judge activity by these.
- Version
- Optional. Useful for software people install; less so for a web app everyone gets at once.
- Type
- New, Improved, Fixed. Lets readers skip to what they care about.
- Summary
- One or two sentences for the listing.
- Body
- The full notes: what changed, why, and anything users need to do.
- Image
- A screenshot for visible changes, with alt text describing what it shows.
Anticode serves the collection as a listing at /changelog/ and gives each release its own page at /changelog/<slug>. A page per release is more useful than one ever-growing page: you can link a customer straight to the fix they asked about, and search engines can show a release that matches a query such as "[product] recurring invoices".
Writing entries people understand
| Internal note | Changelog entry |
|---|---|
| Refactored export pipeline to stream rows | Exports of large reports now finish in seconds instead of timing out. |
| Fix race condition in invite flow | Fixed: team invites sometimes arrived twice. |
| Deprecate v1 webhooks | Version 1 webhooks stop on 1 March. Switch to version 2 in Settings > Webhooks before then. |
| Misc UI tweaks | Leave it out, or name the tweak someone will notice. |
- Lead with the effect on the user, then the detail.
- Flag anything that needs action (a deprecation, a setting to change) at the top of the entry, not the bottom.
- Credit requests where you can: "you asked for this" makes people feel heard.
- Don't pad quiet weeks. A changelog with honest gaps reads better than one full of "minor improvements".
Getting it read without RSS
Many developer-facing changelogs offer an RSS feed. Anticode's CMS collections don't produce one, so readers can't subscribe in a feed reader. That puts more weight on the routes you control:
- A "What's new" link inside your product, in the help menu or account menu, pointing to
/changelog/. This is the single most effective route, because it reaches people while they're using the product. - A link in release emails to the specific entry, rather than repeating the full notes in the email.
- A newsletter sign-up on the changelog page for people who want updates by email, connected to Mailchimp or Kit.
- A footer link on the marketing site, so prospective customers find it.
- The release's own address in support replies: "this was fixed on 12 October, details here".
Each published site's sitemap.xml, robots.txt and llms.txt help search engines and AI assistants find the site's pages.
Upkeep
Add the entry on release day, as part of shipping, not afterwards. If the changelog is a separate chore it falls behind within a month. A good habit is to draft the entry while the change is in review, then publish it in the dashboard when it ships. For the site around it, Anticode's version history keeps the most recent saved versions of the site (up to a per-plan number), so you can step back from a redesign that goes wrong; the entries themselves live in the collection.
Limits
- No RSS or Atom feed.
- No scheduled entries. Entries can't be set to appear at a future time; add them when the release ships.
- No in-app widget. The changelog lives on your site; link to it from the product.
- No reactions or comments on entries.
- No import from GitHub releases. Entries are written in the dashboard.
Questions people ask
What's the difference between a changelog and release notes?
They overlap. A changelog is usually the running list of changes; release notes are the fuller write-up of one release. A page per release in a collection gives you both.
Should I include bug fixes?
Yes, the ones users could have noticed. Fixes are often what people are checking for.
How long should I keep old entries?
Indefinitely. Old entries answer "when did this change?" and show a history of steady work.