How to Build a Changelog Page: Entries, Tags, RSS and 'What's New'

How to build a product changelog page: what each entry needs, files vs database, tags, RSS, email updates, an in-app 'what's new' badge, and writing tips.

Mythex Team · 2026-09-29 · 5 min read

A changelog page is a dated list of what changed in your product, newest first, written for the people who use it. To build one you need entries with a date, a clear title, a short explanation and a tag (New, Improved, Fixed), a page that lists them, a separate URL per entry, and ideally an RSS feed and a way to tell users something is new. It is one of the simplest things you can build, and the main decision is where entries live: as files in your site, or in a database with an admin page.

Why a changelog is worth having

A changelog shows customers and prospects that the product is maintained. It gives support and sales a link to send when someone asks "does it do X yet?". It is also a place to close the loop on feedback: when a requested feature ships, the changelog entry is what you point people to. If you run a customer feedback portal, link shipped requests straight to their entries.

A changelog is not your internal commit history. "Refactored billing service" means nothing to a user. "Invoices now show your company's VAT number" does.

What the page needs

Content for each entry

Field	Notes
Title	What changed, from the user's point of view
Date	Publish date, shown on the page
Tag	New, Improved, Fixed (and maybe Removed or Security)
Body	A few sentences or bullets; how to use it, who gets it
Image or video	Optional; a screenshot helps more than a paragraph
Slug	The entry's URL, like `/changelog/invoice-vat-numbers`
Status	Draft or published, plus a scheduled publish date if needed

In-app extras

"What's new" badge: a dot on a menu item when there are entries the user has not seen. Store the date of the last entry they opened, per user or in the browser.
Email digest: a summary sent to users who opt in. This needs a sending provider; see how to send emails from your app.

The main decision: files or database

Entries as files in the site

Each entry is a Markdown file in the project. Publishing an entry means adding a file and redeploying. This is the simplest and most robust approach: no database, no admin login, nothing to secure, and pages can be pre-rendered so they load fast and are easy for search engines to read.

It suits teams where the people writing entries are comfortable asking an AI builder or editing a file.

Entries in a database with an admin page

Entries live in a table, and a private admin page lets anyone on the team write, preview, schedule and publish. This suits teams where marketing or support writes updates, or where you want scheduled publishing or per-audience entries (for example, only show enterprise features to enterprise customers).

The cost is more to build and look after: an admin login, image uploads, and making sure the public pages are still readable by search engines, which a page that only loads entries in the browser may not be.

	Files	Database + admin
Who can publish	Whoever edits the project	Anyone with an admin login
Setup	Minimal	Login, storage, admin UI
SEO	Easy (pre-rendered pages)	Needs care so pages are rendered on the server or pre-rendered
Scheduling	Publish when you deploy	Can schedule by date
Hosting cost	Static	Needs a running app and database

Writing entries people read

Lead with the benefit. "Export reports to Excel" beats "New export module".
Say who gets it. All plans, Pro only, rolling out this week.
Show it. One screenshot or short clip.
Group small fixes. A weekly "Fixes and improvements" entry with bullets keeps the page from being flooded.
Be honest about removals. If something is going away, say when and what to use instead.

A first prompt that works

Add a public changelog to our site at /changelog. Each entry is a Markdown file with a title, date, tag (New, Improved or Fixed), optional cover image and body. The index page lists entries newest first with the date, tag and first paragraph, has tag filter buttons, and shows 10 entries per page. Each entry has its own page at /changelog/<slug> with a proper page title and description for search engines. Add an RSS feed at /changelog/rss.xml. Create three sample entries. Match the existing site design, keep it readable on phones, and pre-render the pages so they load fast.

For the database version, swap the first sentence for "Store entries in a database with draft/published status and a publish date, and add a password-protected admin page to write, preview and publish them."

Build steps

Decide files or database using the table above.
Build the index and entry pages with a few sample entries.
Add tags and filters.
Add the RSS feed and link it from the page.
Add page titles, descriptions and a sitemap entry for each entry. Our guide on SEO for AI-built websites covers the basics.
Admin page and login, if you chose the database route.
"What's new" badge in your app.
Write real entries for the last few months so the page does not launch empty.

Common mistakes

Copying commit messages. Write for users, not developers.
One giant page with no per-entry URLs. Nobody can link to a specific change, and search engines see one page instead of many.
Updates stop after a month. A changelog last updated a year ago suggests an abandoned product. Set a rhythm you can keep.
Loading entries only in the browser. Search engines and link previews may see an empty page. Pre-render or render on the server.
Mixing in incidents. Outages belong on a status page, not the changelog.

When a hosted changelog tool is the better choice

Hosted changelog and product-update tools exist, and some come bundled with feedback boards or in-app widgets. They are worth it if you want an in-app popup, audience targeting and analytics without building them, or if your team already pays for a tool that includes one. Your blog or help centre software may also have a suitable format already.

Building your own makes sense when you want the changelog on your own domain, in your own design, and fully indexable, which for a simple list of dated posts is not much work.

Building it with Mythex

On Mythex you can ask the agent to add a changelog to an existing project or build it as its own small site, and see it in the live preview as it is built. The file-based version needs no database. If you choose the admin version, the agent adds a dedicated Postgres database when entries need saving (or type /database), and screenshots go in project file storage. Admin sign-in is something you add with your own auth approach (add login recipe).

New Mythex apps are often client-rendered single-page apps, which the SEO recipe notes are weaker for search, so ask for static or pre-rendered changelog pages if you want entries found in search. The same recipe covers titles, descriptions and sitemaps. For a starting point with a built-in changelog, see the product knowledge hub template.

Questions

What should a changelog entry include?

A date, a short title that says what changed for the user, a few sentences or bullets explaining it, a tag such as New, Improved or Fixed, and optionally a screenshot and a link to more detail.

Does a changelog need a database?

Not necessarily. If one or two people publish updates, entries can live as Markdown files in the site and be published with each deploy. Use a database when non-technical people need to write and schedule entries from an admin page.

How often should I update a changelog?

Whenever something users would notice has changed. Many small products group changes weekly or every two weeks; the important thing is a steady rhythm so the page looks alive.

Is a changelog good for SEO?

It can help a little: each entry is a crawlable page about a feature, and a regularly updated page signals an active product. Give each entry its own URL and a descriptive title.