How to Run a Product Changelog Inside a Site Builder

A changelog is the most honest page on a product site. It says what shipped, when, and usually why. But most product sites run on a site builder: Webflow, Framer, Squarespace, WordPress with a page builder bolted on. Those tools are built for marketing pages, not for a running log of releases. The result is a changelog that either gets abandoned after three entries or turns into a static "What's New" page that hasn't been touched since last spring.

Running a changelog inside a site builder is possible. It just requires accepting that the builder is not a CMS for release notes and designing around that limitation instead of pretending it away.

Why the site builder fights a changelog

Site builders think in pages. A page has a hero, sections, a footer. A changelog has entries, each with a date, a version, a title, a body, and maybe a tag for "fixed" or "new" or "improved." Those are different structures, and a page builder will happily let a team fake the second one with the first for about six weeks.

The fake looks like this: someone duplicates a section, updates the text, pushes it live. It works. Then the entries stack up, the page gets heavy, the person who owned it leaves, and the next person opens the editor and sees forty duplicated sections in a scrolling mess. The changelog dies quietly. Nobody decides to kill it.

The fix is to stop treating the changelog as a page and start treating it as a collection. Most site builders have some version of this: CMS collections in Webflow, collections in Framer, custom post types in WordPress, database collections in Squarespace. The changelog becomes a list of items, and the page becomes a template that renders them.

Model the entry before touching the page

Before a single section gets built, define what a changelog entry actually contains. The field list is short and should stay short. A date, a version string, a title, a body field, and one category field with a fixed set of values: new, improved, fixed, deprecated. That last field matters more than it seems, because it becomes the thing readers scan for.

Resist the urge to add twelve fields. A changelog with a "priority," "affected plan," "internal ticket link," and "related feature" field is a changelog that gets filled in halfway. Five fields, all required, beats twelve fields where six are empty.

One field deserves a warning: the body. Rich text in a site builder CMS is often a trap. Pasted content carries styling, the editor strips some tags and keeps others, and the rendered output drifts from the design. Plain text or a tightly restricted rich text field with three options (bold, link, list) keeps entries consistent across months of use.

Build one entry template, then stop designing

The changelog page needs exactly one entry design, repeated. Date on the left, category tag above the title, body underneath. That's the whole thing. The temptation to make "major" releases look visually different is strong and should be resisted, because it turns every entry into a design decision and design decisions are what kill recurring content.

In the builder, this means a collection list with a single item layout, sorted by date descending. The date format should be unambiguous: "14 March 2025" reads cleanly in every locale where a site might be read, while "03/14/25" and "14/03/25" are a coin flip. Version strings sit next to the date if the product uses them, and many products do not, which is fine. A changelog without version numbers is still a changelog.

The category tag is the one place visual variation earns its keep. Three colors, used consistently: green for new, blue for improved, gray for fixed. Readers learn the colors within two visits and start scanning for them. This is the entire design system the changelog needs.

Pagination versus a single scrolling column

Site builders handle long lists poorly. A collection with two hundred entries rendered on one page will load slowly and scroll forever. Two workable patterns exist, and the choice depends on how often the product ships.

For products that ship weekly or more, a paginated list with twenty entries per page and a "load more" button is right. Readers come back often, they only need the recent entries, and archiving older ones behind a click is honest. For products that ship monthly, a single reverse-chronological column with the current year and a collapsed "previous years" section works better, because the volume is low enough that scroll is not a burden.

One thing to avoid: the infinite scroll pattern. It is easy in some builders, it breaks browser back behavior, and it makes the page impossible to link to a specific entry. A changelog entry should have its own URL. People share release notes internally, and a link that lands mid-scroll on a dynamic list is a link that fails.

The RSS feed problem

Most site builders generate an RSS feed for blog posts automatically and do not for arbitrary collections. This matters because a changelog is one of the few marketing assets where an RSS feed still has real users: developers, integration partners, and the occasional power user who wants release notes in their reader.

Some builders let a collection be assigned to the blog template, which inherits the feed. Others require an external service like Zapier or a small script to generate one. The pragmatic move is to check whether the builder can output a feed for the collection; if not, point the feed URL at the collection's paginated index and accept a lower-fidelity feed rather than skipping it entirely.

Draft, review, and schedule without a second tool

The reason changelogs stall is rarely the writing. It is the workflow around publishing. A release ships on Tuesday, the person who knows what changed is busy, the entry gets written Thursday, and by then it reads like an afterthought.

Site builder CMS collections usually support a draft state and a publish date. Use both. The entry gets written during the release cycle, saved as a draft, and scheduled to publish the moment the release goes live. This removes the lag between shipping and announcing, which is the single biggest contributor to changelog decay.

Review is a lighter matter. One other person reads the draft before it schedules, looking for two things: does it say what actually changed, and does it avoid internal jargon. "Refactored the auth layer" means nothing to a customer. "Sign-in now works with passkeys" means something. The review catches the first kind of sentence before it ships.

Writing entries that are worth reading

The content itself has a shape that works. Lead with what changed, in the first sentence, in plain language. Follow with a sentence on why it matters or what it replaces. Stop. Three sentences is often enough. A changelog entry is not a blog post and should not try to be one.

Two habits are worth building. First, write entries as they happen, in a shared document, not from memory at the end of the week. Second, keep a running list of user-facing changes as releases go out, because the engineering changelog and the customer changelog are different documents and conflating them produces entries full of internal references.

There is a category of entry that should never appear: the empty one. "Various bug fixes and improvements" is a sentence that communicates nothing and trains readers to stop reading. If a release has nothing customer-facing, the changelog does not need an entry for it. Silence is better than filler.

Linking entries back into the product

A changelog entry has a natural second job: it can link to the feature it describes. The body field accepts a link, and the link points at the docs page, the feature page, or a help article. This turns the changelog into a navigational surface instead of a dead archive.

The linking discipline is simple. If a feature has a page, link it. If it does not, don't invent a destination. A changelog full of links to nonexistent pages is worse than a changelog with none, because it teaches readers that the links are unreliable.

The maintenance question nobody plans for

Six months in, the changelog will have sixty entries and one owner. That owner will eventually change roles or leave. The changelog survives that transition only if the process is documented somewhere the next person can find: where the collection lives, what the fields mean, what the category colors are, who reviews drafts, and how the schedule works.

This document takes an hour to write and saves the changelog. The alternative is what happens on most product sites: the page stays live, frozen at the last entry from a person who no longer works there, quietly telling every visitor that the product stopped shipping. A changelog that stops updating is a worse signal than no changelog at all.