How to Build a Changelog Page for Your SaaS With a CMS (2026)

Most SaaS teams ship features every week and tell nobody. The work goes out, the release notes never get written, and users find changes by accident — usually when something they relied on moves. A changelog fixes that. It's the cheapest retention tool you're not using, and you can run the whole thing from a CMS you already control.

The good news: you don't need a dedicated changelog SaaS or a plugin subscription. A category and a handful of scheduled posts inside a normal CMS does 90% of the job. This guide shows how to build a changelog page that ranks, retains, and stays easy to update — with a concrete recipe using UnfoldCMS.

TL;DR — what you actually need

A changelog is a dated, reverse-chronological list of what changed in your product. You need three things: a place to host entries (a blog category or a standalone page), a consistent entry format (date, version, a type badge like New/Fixed/Improved), and a way to publish on a schedule without a code deploy.

If you run a CMS, you already have all three. Make a category called Changelog, write each release as a short post tagged to it, and let the CMS render the archive. Add an RSS feed so power users subscribe, and — if your app front end is separate — pull entries as JSON through a REST API and render them in-app. That's the whole pattern. The rest of this post is the detail.

Why does a changelog matter for a SaaS?

A changelog builds trust and drives long-tail SEO. It shows the product is alive, gives users a reason to come back, and turns every feature you ship into an indexed page that catches searches like "does [product] support X". Quiet products feel abandoned even when they're not.

Three concrete payoffs:

• Retention. Users who see steady progress stick around. A changelog is a passive "we're still building" signal. When you ship a fix someone asked for, the entry is proof — link it back in a support reply and you close the loop.
• Trust and sales. Prospects check the changelog before buying. A changelog that stops six months ago kills a deal quietly. A fresh one does the opposite — it's social proof that ships itself.
• SEO long-tail. Each entry is a page. "Added Slack integration" becomes a URL that ranks for people searching exactly that. These pages are cheap to write and compound over time, feeding your marketing site with fresh, crawlable content.

Where should you host the changelog — blog or standalone page?

Host it as a blog category if you want SEO and RSS for free. Host it as a standalone page if you want tight design control or an in-app widget. Most teams start with the category — it's less work, each entry gets its own indexable URL, and the CMS handles the archive, pagination, and feed automatically.

The split comes down to what you optimize for. A blog category gives you one URL per entry, a ready-made feed, and zero custom code — but it lives on your marketing domain and looks like blog content. A standalone page (one long page, or a headless widget in your app) gives you full design control and lets you show the changelog inside the product where users already are — but you build the layout and the feed yourself.

You can also do both: publish entries through the CMS category for SEO, then pull the same entries into an in-app widget over the API. One source, two surfaces.

Comparison: three ways to run a changelog

Third-party tools are fast to embed but rent your content on someone else's domain, so the SEO value leaks away from you. If you already pay for a CMS, the blog-category route keeps the traffic and the data.

How should you structure a changelog entry?

Every entry needs a date, a version number, and a type badge, then a short human summary. Lead with what changed and who it affects — skip the internal ticket numbers. Keep each entry scannable: two or three lines for small changes, a short bullet list for bigger releases.

A reliable entry format:

• Date — the publish date, so the reverse-chronological order reads clearly.
• Version — v2.4.0 or a release name. Ties the entry to what users see in-app.
• Type badge — New, Improved, Fixed, Deprecated. A colored label lets readers scan for the category they care about. In a CMS you can drive these off a tag or a small set of sub-categories.
• Summary — one plain sentence: "You can now export reports as CSV from the dashboard."
• Optional detail — a screenshot (with a real alt tag) or a link to the feature doc.

Write in the same voice as your product. "Fixed a bug where invoices double-counted refunds" beats "Resolved refund calculation discrepancy in billing subsystem." Users skim changelogs; make them easy to skim.

How do you set up a changelog in a CMS? (step by step)

Create a category, write each release as a post, schedule it, and let the CMS render the archive and feed. In UnfoldCMS this is the whole flow — no changelog-specific feature needed, because a changelog is just a category plus posts. Here's the honest, concrete version.

1. Make a category named Changelog. In UnfoldCMS every category gets its own archive URL and RSS-able index, so this alone gives you a working changelog page and feed.
2. Write each release as a post. UnfoldCMS uses one Post model with four content types (post, page, landing, block). A changelog entry is a normal post assigned to the Changelog category. Title it with the version, e.g. v2.4.0 — CSV export + faster search.
3. Add a type badge with a tag or sub-category. Tag entries New / Fixed / Improved so readers can filter. Your theme renders the tag as a colored label.
4. Set the date and schedule it. UnfoldCMS supports scheduled posts — write the entry when the code merges, set it to go live the moment the release ships, and walk away. The publish date orders the changelog for you.
5. Fill the SEO fields. Give each entry a clear seo_title and meta description — this is what makes "added X to [product]" rank. UnfoldCMS ships SEO fields plus JSON-LD structured data per post.
6. Point people at the feed. The category index is RSS-able, so link "Subscribe" to the feed. Power users and tools like Zapier can watch it.
7. (Optional) Render it in your app. If your product front end is separate, read entries as JSON from the /api/v1/* REST API and drop a "What's new" widget in-app.

That's it. No new content type to learn, no plugin — a changelog is a category and some posts, and it's fair to say so plainly.

Can you automate the changelog for a headless front end?

Yes — read entries over the REST API and trigger a rebuild with a webhook. UnfoldCMS exposes /api/v1/* to fetch posts as JSON, so a headless or in-app changelog widget can pull the latest Changelog entries. Outgoing HMAC-signed webhooks fire on publish, so your static site or app rebuilds the moment a new entry goes live.

The headless loop looks like this:

• Your front end (Next.js, Astro, a mobile app) calls /api/v1/posts?category=changelog and renders the list.
• When you publish a new entry, UnfoldCMS sends a signed webhook to your build hook.
• The site rebuilds with the new entry baked in — no manual deploy, no stale cache.

The webhook signature is HMAC, so your endpoint can verify the payload really came from your CMS before it kicks off a build. For a purely server-rendered marketing site you can skip all of this and just use the category page — the API path is there when you need the changelog inside the product itself.

What about RSS and email notifications?

RSS comes free with a CMS blog index; email you wire up on top of the feed. The category page is a subscribable feed out of the box, so developer-heavy audiences can follow it in a reader. For email, point an automation tool (or your own cron) at the RSS feed and send a digest whenever new entries appear.

You don't need a separate "notify subscribers" system to start. A feed plus a weekly or per-release email digest covers most SaaS audiences. If you already collect emails, a monthly "here's what shipped" send — pulled straight from the changelog — is one of the highest-open emails you can write, because it's all about things users asked for.

Make it real: a one-hour changelog

Block one hour. Create the Changelog category. Backfill your last five releases as posts so the page doesn't launch empty — even rough entries beat a blank archive. Add New / Fixed / Improved tags. Fill the SEO title and meta for each. Link "Changelog" in your footer and your in-app help menu.

Then set a habit: when a release merges, write the entry and schedule it for ship day. Two minutes per release. If you have a headless front end, wire the publish webhook to your build hook once and forget it. The whole system runs on a category and a scheduling toggle you already have — see the full feature list for what's included.

FAQ

Do I need a dedicated changelog tool? No. A changelog is a dated list of posts. Any CMS with categories and scheduled publishing runs one. A dedicated tool adds a subscribe widget and analytics, but you rent your content on their domain and lose the SEO. Start with a category; add a tool later only if you need the widget.

Should each changelog entry get its own URL? Yes, if SEO matters to you. One URL per entry means each feature can rank for its own long-tail search. A single long standalone page is easier to skim but ranks for far less. The blog-category route gives you both — an archive page and a URL per entry.

How often should I post to the changelog? Every release, however small. Consistency is the signal. A changelog with weekly small entries reads as "active product." Batching a month of changes into one post is fine too — just don't let it go quiet. Empty months read as a stalled product.

Can I show the changelog inside my app, not just on the marketing site? Yes. Pull entries as JSON from the CMS REST API and render a "What's new" widget in-app. Same content, two surfaces — one for SEO on the marketing domain, one for engaged users inside the product. UnfoldCMS's /api/v1/* endpoints support exactly this.

What's the minimum viable changelog? A category, five backfilled entries, and a footer link. That's a working changelog you can ship in an hour. Add badges, RSS promotion, and email later.

Want to run your changelog from a CMS you host and own? UnfoldCMS is a self-hosted Laravel + React CMS with categories, scheduled posts, a REST API, and signed webhooks — everything the changelog recipe above needs, with no per-seat changelog tax.

Sources: patterns here reflect common SaaS changelog practice (reverse-chronological entries, version + type badges, RSS feeds) and the documented capabilities of UnfoldCMS as of 2026. Verify feature specifics against your own CMS version before building.