Changelog pages that build trust over time

The changelog is the page nobody plans and everyone checks. New visitors hit it from a tweet or a footer link, current users check it on Mondays, journalists scan it before writing about you, investors read it to see whether you're shipping. It's the single best evidence-of-life surface a product has, and most teams treat it as an afterthought, a bulleted list of bug fixes that hasn't been updated since spring.

Linear, Vercel, Resend, Cursor, and Notion all ship changelogs that read like editorial. Here's what they have in common, and what you can copy without copying.

What a changelog is actually for

Three audiences, one page. Each one wants something different, and a good changelog quietly serves all three.

• Existing users: what changed that affects me? The release-notes view, ideally with anchor links per entry.
• Prospective users: is this product alive and improving? Recency + density of entries is the signal.
• Journalists, investors, integrators: what's the trajectory? Trends across months, what categories of work get prioritized.

The structure that scales

The page shape

A vertical feed, reverse chronological. Each entry is dated, titled, and often categorized. The page is anchor-linkable per entry (/changelog#2026-06-02-improved-search) so links from Slack and emails land at the right spot. Pagination by month or year prevents the page from becoming a 4MB scroll.

The entry shape

• Date and version (if you version). Top of the entry, small mono label.
• Title. One sentence, sentence-case. "Improved search ranking" beats "v2.4.1." Lead with the user benefit.
• A short paragraph (2–4 sentences). What changed, who it affects, why it matters. This is the editorial work most changelogs skip.
• Optional media. Screenshot, short loop, or a thumbnail diagram. Linear and Vercel both run beautiful changelog screenshots; they convert the page into something shareable.
• Optional category tags. "Search," "Performance," "Auth." Useful when you have a year+ of history; skip them in the first six months when there isn't enough content to filter.

The header

A short title ("Changelog" or "What's new"), a one-line description ("What we've shipped at [Product]"), an RSS link, and an optional subscribe-by-email field. The subscribe field is more important than most teams realize, the people who opt in to your changelog are your most engaged users, and the list compounds.

The cadence question

Three viable rhythms:

1. 01Continuous, with a few entries per week. Resend, Cursor, GitHub. Each entry is small and focused. The page reads like a feed; recency is always today.
2. 02Weekly digest. One entry per week summarizing what shipped. Linear and Notion lean this way. Each entry is larger, more editorial, easier to maintain at small team sizes.
3. 03Monthly recap. A single entry per month, magazine-style, often paired with a blog post. Stripe and Figma converge here for their larger releases.

Pick one and stay consistent. The worst changelog cadence is the one that varies wildly, three entries one week, nothing for six weeks, then a giant catch-up. Visitors read silence as decay.

Entries worth writing (and ones not to)

Not everything ships in the changelog. Three filters help.

• Would a user notice this? If no, it's an internal release note, not a changelog entry. Backend refactors, infrastructure migrations, and minor copy fixes all belong elsewhere.
• Can you describe it in one sentence? If the description requires three paragraphs and a screenshot, ship it as a blog post and link to it from the changelog as a short stub.
• Is it part of a story? Bundle related shipments. "Improved search" is a better entry than "better tokenizer + new ranking heuristic + UI polish" published as three separate items the same day.

The details that turn the page into marketing

1. 01A featured screenshot per major entry. Even a 60-second screenshot beats none. Use a consistent frame, browser chrome or no chrome, but the same choice every time.
2. 02Author attribution on bigger entries. "Shipped by Alex." Humanizes the team, especially for indie products and small startups.
3. 03Crosslinks to docs and blog posts. Each entry can deep-link to its full documentation or its accompanying blog post. The changelog is a hub, not an island.
4. 04RSS, always. Some users will read your changelog exclusively in their feed reader. Don't skip RSS even if you have a subscribe form.
5. 05Shareable per-entry OG cards. Each anchor link should generate a custom OG image with the entry title. Vercel does this; it's the single biggest reason their changelog entries spread.

The mistakes that hurt the page

1. 01"Various bug fixes and improvements." Either say what was fixed or don't publish the entry. The vague filler entry teaches users to ignore future ones.
2. 02Letting it go stale. A changelog where the most recent entry is from four months ago is worse than no changelog. Either commit to the cadence or take the page down.
3. 03Calling every entry "Major." If every entry is major, none are. Reserve the badge for the rare release that genuinely deserves it.
4. 04Hiding it five clicks deep. The changelog should be linked from the footer, the in-product help menu, and ideally from a small "What's new" indicator in the app itself.

How to start one this week

1. 01Pick the cadence you can sustain, even at your worst week. Weekly is the safe default.
2. 02Ship the page with the last three things you shipped, even if they're small. The first version of the page is allowed to be thin.
3. 03Add the RSS feed and a small subscribe field on the same first ship.
4. 04Set a recurring calendar reminder for the day you write entries. The calendar is the single most reliable changelog mechanism in early-stage products.
5. 05Backfill once. Spend an afternoon writing changelog entries for the last quarter. Then never backfill again.

Frequently asked

How long should a changelog entry be?

Two to four sentences for most entries; a short paragraph plus a screenshot for the bigger ones. Anything longer should be a blog post that the changelog entry links to, the changelog is a feed, not a knowledge base.

Should I version my changelog?

Only if your users care about versions. SDKs, CLI tools, API products, yes. Most SaaS apps, no, dates are clearer than version numbers for a UI product. Don't use version numbers as decoration if your users don't pin to versions.

How do I write the changelog when our team is small?

Make it one person's job each week, on rotation. Pull the entries from your release notes, your pull request titles, your Slack #ship channel. Editing 30 minutes a week beats writing from scratch once a month and missing it twice.

Where should the changelog link from?

Footer (always), help menu inside the product, a small "What's new" pill in the product UI for major entries, and any onboarding email sequence that talks about ongoing development. The changelog is also fair game for press kits and investor decks.

Ship one

The launches collection has changelog patterns and the cadence playbooks Linear and Vercel use; pair with the landing pages collection for the visual register that ties your changelog to the rest of your marketing site, and the footer entry for where to surface the link so users actually find it.