Shipping without visibility: your best marketing sits in the git log
“We ship all the time, but nobody notices”: I hear this sentence from SaaS teams more often than any feature question. The team delivers every week, the releases pile up in the git log, and from the outside the product looks frozen. The last blog post: eight months old. The product page: unchanged since launch.
Yet the proof of your development speed already exists — it just has to become visible. The tool for that is called a changelog, and it costs you about twenty minutes of writing per release. In this article I show you who actually reads changelogs, which format works, and why a dedicated /changelog route usually beats the third-party widget.
Who reads your changelog: customers, prospects, and machines
First, a definition: a changelog is the chronological, dated list of your product changes, newest entry first. Release notes are the text for a single release. In practice, both terms end up on the same public page. That page has three groups of readers, and you are probably aware of only one of them:
- Existing customers: They pay every month and occasionally wonder what for. Every entry answers the question “Is this product still moving forward?” before it lands on the table at renewal.
- Prospects: According to a Gartner survey published in March 2026, 67 percent of B2B buyers prefer a buying process without sales contact. These buyers check for themselves whether your product is alive — a changelog with entries from the current month is the fastest proof.
- Google and AI search: Fresh, dated, precisely worded content is exactly the material that search engines and AI assistants cite. More on that below.
For prospects, the changelog is part of your conversion path: a trust signal on the way to the trial, just like the trial and demo pages themselves. Maintain both and you sell to self-serve buyers without a sales rep typing a word.
A release nobody hears about never happened, as far as the market is concerned.
The format: benefits instead of ticket numbers
Most changelogs fail not on discipline but on format: they read like a ticket export. “Fix: NPE in InvoiceService” tells your customer nothing. The reference for structure is the Keep a Changelog standard, whose first principle reads: changelogs are for humans, not machines. Four ingredients make the difference.
State the benefit
Write every entry from the user's point of view: what they can do now, or what they no longer have to do. “Refactored async export” becomes “Large exports no longer block your browser window: you get an email as soon as the file is ready.” The pattern behind it: first the benefit in one sentence, then a sentence on the how if needed. Ticket numbers stay in the tracker.
Screenshots and short videos
One screenshot per feature is enough, but it has to be there: people scroll changelogs, they don't read them word for word. Linear shows how it's done: big image, one explanatory paragraph, done. For interactions, a short video or GIF under thirty seconds is worth it. Rule of thumb: whatever you show in sprint review belongs in the entry as an image.
Date and rhythm
Every entry carries a date, the newest sits on top. Regularity matters more than frequency: better one bundled entry every two weeks than three posts in one week followed by a quarter of silence. Collect small fixes into a weekly or monthly entry instead of announcing every hotfix on its own.
Categories
Keep a Changelog recommends six change types: Added, Changed, Deprecated, Removed, Fixed, Security. For a marketing changelog, three usually suffice: New, Improved, Fixed. Categories make the page scannable and hand you analyzable data on the side — say, the answer to how much genuinely new ground your team covered this quarter.
The changelog as an SEO and GEO asset
On the subject of visibility: a maintained changelog is a page that changes weekly, on a website that otherwise rarely changes. Search engines register freshness signals like that. Add long-tail hits: whoever searches for your product name plus a feature lands on the matching entry instead of nowhere.
For AI search, this weighs heavier. ChatGPT, Perplexity, and Google AI Overviews answer questions like “Can tool X do Y by now?” from what they can cite: dated, clearly structured statements with a source. A changelog entry with a date, a feature name, and one sentence of benefit is the most citable text form on your website — that is my read from our GEO audits, not a study.
The channel is measurable all the same: in the Umami data of our own website, ChatGPT and Perplexity have shown up as referrers for months, meaning visitors who click through from an AI answer. Sanity takes machine readability furthest: every changelog entry there is additionally available as a Markdown file, ideal feed for AI crawlers (as of September 2026).
Three moves get the most out of it: a dedicated URL per entry instead of one endless scroll page, an RSS feed for subscribers and crawlers, and clean HTML with the date in the markup. How the changelog fits into the rest of your site architecture is covered in the guide to the SaaS website.
Your own /changelog route or a third-party widget?
The default solution is a service like Canny, Beamer, or LaunchNotes: an embedded panel in the app plus a hosted changelog page. That is set up in an hour, but it carries a price beyond the subscription fee: your content sits on someone else's infrastructure, and the SEO effect lands on the provider's subdomain instead of your domain.
Weighed honestly: a widget is the right choice if you mainly want in-app announcements and feedback voting and have no developer capacity to spare right now. At Canny, that costs $79 per month on the Pro plan with annual billing; the free plan does not include the changelog module (as of September 2026).
| Criterion | Your own /changelog route | Third-party widget |
|---|---|---|
| SEO effect | on your domain | on the provider's subdomain |
| Design | your design system | the provider's builder |
| In-app announcements | build it yourself | included |
| Feedback voting | build it yourself | included |
| Running costs | none, one-off development time | Canny Pro: $79/month (as of 09/2026) |
| Reuse (newsletter, social, AI) | full control over the raw data | export depends on the provider |
If your website already runs on a headless CMS, the dedicated route is little work: one document type with title, date, category, text, and screenshot, plus a list page and a detail page. In our stack of Sanity and Next.js, that is a one-day project, not a sprint. The same lever works for help pages: the sister article shows how to feed docs and website from one CMS.
The underrated advantage of your own route is reuse. Every entry sits as a structured record in your CMS: the same source feeds the “New this month” section of your newsletter, the LinkedIn post for the release, and the in-app message. You write once and publish on every channel — with a widget, exactly that hangs on the provider's export.
Three changelogs that show how it's done
I checked all three examples on September 22, 2026; the dates mentioned reflect that snapshot.
- Linear (linear.app/changelog): the industry benchmark. Big image, clear benefit copy, bundled sections for fixes and improvements underneath. Rhythm roughly weekly to biweekly; the most recent entry, “Loops for product management,” dates from September 14, 2026.
- Vercel (vercel.com/changelog): the short form. Date, title, two sentences, link to details, several entries per week; the most recent appeared on September 21, 2026. Proof that a changelog needs cadence, not an editorial team.
- MOCO (mocoapp.com/blog): an example from the German market. The agency management software publishes product news as German-language blog posts with screenshots, on a weekly to biweekly rhythm; “Quick Wins September 2026” appeared on September 21, 2026.
What all three share: dates, benefit language, imagery, a dedicated URL on their own domain. What none of them publishes: ticket numbers.
Next steps
You don't need a project for this, you need a start. My suggestion for this week: write up your last four releases retroactively as entries, following the pattern of benefit, screenshot, date, category. Publish them as a plain /changelog page. From then on, one rule applies: no release without an entry — the text is written in the same pull request as the feature.
Or we build it together: as a B2B website agency, we set up changelog, blog, and docs as routes in one CMS, so every release automatically lands where customers, prospects, and AI search can see it. Book a no-obligation intro call: in 30 minutes, we work out which route your website needs first.
