How Do You Build a Changelog Page in Webflow?

How do you build a changelog page in Webflow?

Model it as a CMS Collection with one item per release, then render the whole thing as a Collection List sorted newest first. That gives your team a place to write entries in advance, publish them on release day, and never touch the Designer to ship an update again.

Most B2B sites either have no changelog or bury one in a docs site nobody links to. That is a wasted asset. A changelog is the cheapest proof of momentum you will ever publish, and it is one of the few pages that rewards you for shipping.

Here is the structure we build, the fields we use, and the writing rules that make it worth reading.

Why does a changelog matter to a B2B buyer?

Because buyers are looking for reasons to disqualify you. TrustRadius, in its 2026 B2B Buying Disconnect Report of 1,862 buyers and 444 vendors, found that 83 percent of buyers shortlisted three or fewer products. Getting cut is the main risk, and a dead-looking product is an easy cut.

A changelog answers a question nobody asks out loud: is this team still building? Twelve entries in the last quarter answers it better than any roadmap slide.

It also feeds the evaluation. The same report found 74 percent of buyers use reviews to inform their decisions, and a changelog is the page reviewers and analysts quote when they describe your pace.

What should the Collection look like?

One Collection called Changelog, one item per release. Webflow's own documentation describes Collections as holding items with field types including text, rich text, images, dates, numbers and references to other collections, which is everything a changelog needs and nothing more.

Resist the urge to model releases and features as two Collections linked together. It sounds cleaner and it doubles the work of publishing, which is how changelogs die.

One Collection also keeps the page simple: a single Collection List, sorted by release date descending, with a limit if you want pagination. Our guide to content modelling in a CMS covers when splitting is genuinely worth it.

Which field types should you use?

Webflow's documented field types map neatly onto this. Use PlainText for the entry title, RichText for the body, Date/Time for the release date, which Webflow stores in ISO 8601 format, and Option for the change type so every entry is tagged consistently.

Add a Switch for whether an entry is a highlight, which lets you pull the big releases onto your homepage or product page later. Use Link for a docs or help article URL, and MultiReference if you want to connect entries to product areas you already have as a Collection.

Keep the Option list short and fixed: added, improved, fixed. Three values cover almost everything and they survive a change of writer. Webflow's Option field uses predefined choice lists, so this stays clean rather than becoming free text.

How do you write entries people actually read?

Lead with the outcome, not the mechanism. "Export any report as CSV" tells a buyer something. "Refactored the export service" tells them you have engineers. One short paragraph per entry, plain words, no version numbers unless your customers actually cite them.

Name the thing the user can now do, where they can find it, and who it helps. If an entry cannot answer those three, it is probably an internal change that does not belong on a public page.

Write the fixes too. A changelog that only lists new features reads like marketing. One that admits what was broken and is now fixed reads like a team you can trust with your data.

How do you publish an entry on release day?

Write it ahead and let the CMS hold it. Webflow's documentation describes items existing in two states, staged for draft content not visible on your live site and live for published content, and says this dual-state system lets you prepare content changes without affecting your live site.

That is the whole workflow. Draft the entry while the feature is in review, then publish when the release goes out. Nobody has to open the Designer, and nobody has to remember the copy at 6pm on a Thursday.

If you want it automated, the Data API can create and update items programmatically. Webflow's docs note that creating a new item through those endpoints always creates a draft, and that updating a live item also updates its staged version. That is a sensible default for anything wired to your release pipeline.

Should each entry get its own page?

Yes, if entries are substantial, and no if they are one-liners. A Collection Page per entry gives you a URL to link from support tickets, release emails and social posts, which is usually worth having even when most traffic lands on the index.

The compromise we use most often: full entries on the index page, with each title linking to its own page for the longer ones. Readers skim the list, and anyone who cares gets a permanent link.

Watch the index page weight if entries include images. A page with 200 entries and an image in each one is a performance problem waiting to happen, which is what the list limit and pagination are for. Our notes on Webflow Collection Lists cover the limits and nesting rules.

How do you make a changelog findable in search and AI answers?

Give it a real page title, a stable URL like /changelog, and text that names the product and the capability in the same sentence. Entries that say what the feature does in plain language are the ones an answer engine can quote when someone asks whether your product supports something.

Date every entry visibly, not just in the CMS field. A visible date is what makes the page look current to a human and what lets a model say when something shipped.

Then set the page-level SEO fields properly so the index page describes the whole log rather than inheriting a generic template description. Our guide to Webflow page SEO settings walks through where each field lives.

How should people follow it?

Offer one way, well. For most B2B products that is a short email digest, monthly or per significant release, with a subscribe form directly on the changelog page. It converts better than a feed because it reaches people who will never check a page.

Keep the form dumb: one email field, clear expectation of frequency, and a note that it is product updates rather than marketing. Breaking that promise is how a changelog list becomes an unsubscribe list.

Whatever you offer, put the subscription next to the entries rather than in the footer. The moment somebody is impressed by your pace is the moment to ask.

What would we build first?

The Collection, six fields, one Collection List sorted by date, and three real entries written the way described above. That is an afternoon of work rather than a project, and it is enough to find out whether your team will actually keep the page fed once the novelty wears off.

Then set a rule about cadence. A changelog updated monthly is an asset. One that stops for six months is a liability, because the last entry becomes the date a visitor assumes you stopped working.

If you want help modelling this alongside the rest of your Webflow CMS, we are happy to walk through it. You can see how we build at phoenix.studio.