By Mehdi HassanWhat is a SaaS changelog page?
A SaaS changelog page is a public, dated list of product changes: new features, improvements and fixes. It sometimes goes by "product updates", "what's new" or "release notes". It's written for current users who want to know what changed, and increasingly for prospects who want to know whether the product is still moving.
That second audience is why the changelog has moved from a docs afterthought to a marketing page. A buyer comparing two tools will often check when each last shipped something. A page with recent, specific entries says "this team is active"; a page last updated eight months ago says the opposite. It's one of the trust pages we cover in our SaaS website design guide.
What makes a good SaaS changelog page?
A good SaaS changelog page is current, specific and easy to scan. Every entry has a date, a clear title that says what users can now do, a short explanation, a visual where it helps and a link to more detail. The page itself loads fast, can be filtered and has a way to subscribe.
- Dated entries in reverse order, with the newest at the top and the date visible on each one.
- Outcome titles: "Bulk-edit tasks from the list view" rather than "List view improvements".
- One visual per significant entry: a screenshot, a short loop or a GIF of the new behavior.
- Labels such as New, Improved and Fixed, plus product-area tags for filtering.
- Links out to the relevant docs page and, for big releases, a dedicated release page.
- Subscribe options: email, RSS or an in-app feed, so users don't have to remember to check.
Which changelog examples are worth studying?
The changelog examples worth studying come from products that treat release notes as part of the brand. The patterns below are publicly visible on their sites, though designs change, so check the live pages before copying a detail.
Company | Pattern to notice | Why it works |
|---|---|---|
Linear | Dated, well-designed release posts with large product visuals | Turns each release into a small launch and reinforces a design-led brand |
Stripe | A separate, versioned API changelog for developers | Developers can see exactly what changed and whether it affects their integration |
GitHub | A high-volume changelog with labels and filtering by type and area | Users of a huge product can find only the changes that matter to them |
Vercel | Short entries per feature, each with its own page | Every feature becomes linkable, shareable and indexable |
Raycast | Release notes grouped by version number | Matches how users of a desktop app think about updates |
Notion | A "What's New" page with dated releases and visuals | Speaks to non-technical users in plain language |
Notice what they share: a strong date, a visual and plain titles. None of them depend on a clever layout. If you want more patterns from the rest of the site, our SaaS website examples and AI company website examples break down how these teams present the product elsewhere.
How should a changelog entry be written?
A changelog entry should be written for a user who has thirty seconds: what changed, who it's for and how to use it. Start with the outcome, add one or two sentences of context, then link to the docs. Save the engineering backstory for the blog.
Title the outcome
Use a verb and the user's language: "Export reports to CSV" beats "Reporting module v2".
Explain who benefits
One sentence on the problem it solves and which users will notice it.
Show it
A cropped screenshot or a short loop of the new behavior, with real-looking data.
Say how to use it
Where to find it, which plans include it and a link to the docs article.
Group the small stuff
Bundle minor improvements and fixes into a short list at the end of the entry instead of giving each its own post.
How does a changelog help SEO and AI search?
A changelog helps SEO when substantial releases get their own pages with clear titles, real explanation and links to the relevant feature and docs pages. Those pages can rank for searches like "[product] CSV export" and give AI assistants a dated, specific source to cite when someone asks whether a product supports a feature.
- One URL per notable release, with a descriptive slug, rather than a single endless page.
- Link each release to its feature page, and update the feature page to mention the new capability.
- Use dates in the markup and on the page, so freshness is visible to people and crawlers.
- Keep the index paginated and fast, with summaries rather than the full text of every entry.
Should the changelog live on the marketing site or in the docs?
Put the product changelog on the marketing site and the API changelog in the docs. The product changelog speaks to users and prospects, benefits from your brand design and helps the main domain's search visibility. The API changelog speaks to developers, needs versioning and belongs next to the reference documentation.
If you use a changelog tool, check whether it can publish under your own domain (for example /changelog) rather than a separate subdomain, and whether entries render as normal HTML that search engines can read.
How do you keep a changelog page current?
Keep a changelog current by giving it an owner, a rhythm and a template. The owner, usually product marketing or a product manager, collects shipped changes at a fixed point in each cycle and publishes on the same day every week or two.
The template matters as much as the rhythm. A CMS collection with fields for title, date, labels, product area, summary, visual and docs link means anyone can publish a consistent entry in minutes, without a designer. The same entries can feed an in-app "what's new" panel and a monthly email, so you write once and publish three times.
Pros
- Shows prospects and users that the product is actively improving.
- Gives sales a dated answer to "do you support X yet?"
- Creates indexable pages for feature searches at very low cost.
Cons
- A stale changelog actively hurts trust, so it needs a real owner.
- Visuals for every entry take time from design or product marketing.
- Teams with irregular release cycles can struggle to keep a steady rhythm.
This is where many small teams fall behind: the changelog template exists, but nobody has time to produce visuals and release pages alongside everything else. A SaaS website redesign is a good moment to set up the template properly, and our guide to SaaS feature pages shows how releases and feature pages should link together.
