TLDR: A changelog page is a dated, reverse-chronological list of what you shipped, with each entry tagged New, Improved, or Fixed. It is one of the higher-value pages you can build with AI because the layout is simple and the trust it earns is real. Prompt for one self-contained HTML file with your releases as data, add tag filters and a search box in a follow-up, and write every entry for the reader instead of the ticket queue. When it works, publish it with VisiblePage so it lives at one canonical link you re-publish to every release, and nobody ever lands on an old copy.
Every product has a moment where a customer wonders “wait, did they ever fix that?” or “is this thing even being worked on?” A changelog page answers both without a single support ticket. It is the running record of what you shipped, when, and why it matters, and it quietly does more for trust than most of the copy on your landing page.
Yet most projects never build one, because it feels like a chore that needs a tool, a plugin, or a whole content system. It does not. You can build a changelog page with AI in an afternoon, keep it at one link, and update it in a minute whenever you ship. This guide walks the whole path: what a good changelog is, the prompt that produces one, how to make it filterable and searchable, how to write entries people actually read, and where to put it so it stays current for everyone.
What is a changelog page, and why build one?
A changelog is a list of releases in reverse chronological order, newest at the top. Each release has a version or a date, and under it a few short entries, each tagged by type: something New, something Improved, something Fixed. That is the entire structure. A visitor scans from the top, sees you shipped this week, and reads the two lines that affect them.
The reason to build one is that it does three jobs at once:
- It builds trust. A changelog that updates regularly is proof the product is alive and cared for. An empty “last updated 14 months ago” says the opposite, loudly.
- It cuts support load. “That was fixed in the March 3 release” links straight to the entry. People find answers without emailing you.
- It gives you something to point to. Every release, you have a concrete link to share, post, and drop in a customer reply. Shipping becomes visible.
What goes in a good changelog entry?
The layout is the easy part. AI will get that right on the first try. The writing is where most changelogs fail, and where five extra minutes makes the difference between a page people read and a page people ignore.
Every entry needs three things:
- A type tag. New, Improved, or Fixed. Three is usually enough. This lets a reader filter to just the fixes when they are hunting for a bug they reported.
- A version or a date. Pick one convention and keep it. Version numbers suit software; plain dates suit most everything else, including a simple project.
- One line written for the reader. This is the whole game. Lead with what the user can now do, not with the internal change that made it possible.
That last point is what separates a changelog from a commit log. Compare:
| Written for the ticket queue | Written for the reader |
|---|---|
| Resolved indexing race condition in query service | Search now returns results instantly, even on big projects |
| Refactored image pipeline, migrated to WebP | Photos load about twice as fast |
| Patched null deref in export handler | Exporting a report no longer drops the last row |
| Bumped auth token TTL to 30d | You stay signed in for a month instead of a day |
Same changes. One column reads like news you can use, the other reads like a stranger’s git history. When you hand releases to the AI, hand it the left column if that is all you have, then ask it to rewrite every line in reader-facing language. It is genuinely good at this, and it is the single most useful thing it will do for the page.
The prompt that builds the changelog
Name the page, hand over your releases as data, and ask for one self-contained file. Swap in your own versions and entries.
Build a changelog page as a single self-contained HTML file. Show releases
in reverse chronological order, newest first, on a vertical timeline. Each
release has a version and a date heading, and under it a list of entries.
Each entry has a small colored tag (New = green, Improved = purple,
Fixed = amber) and one line of text.
Here are the releases (version | date | tag | text):
- v2.4 | Sep 8, 2026 | New | Search now works across all your projects at once
- v2.4 | Sep 8, 2026 | Improved | Keyboard shortcuts for jumping between pages
- v2.3 | Aug 27, 2026 | Improved | Photos load about twice as fast on mobile
- v2.3 | Aug 27, 2026 | Fixed | Long titles no longer overlap the date
- v2.2 | Aug 15, 2026 | Fixed | Exporting a report no longer drops the last row
- v2.2 | Aug 15, 2026 | Fixed | Dark mode no longer flashes white on load
Style: clean and editorial, one accent color, generous line spacing, a clear
type hierarchy, rounded tag badges. Make it responsive so it reads well on a
phone. Inline all CSS and JavaScript. No external files, no libraries, no CDN.You will get a real, readable page back. If the model returns a fragment or splits it across files, reply with the fix from getting self-contained HTML from AI: ask for the complete page with everything inlined into one file.
Get this static version looking right before you add anything interactive. Fix the spacing, the tag colors, and the type hierarchy first. A calm, well-set changelog is mostly typography, so the typography tips for AI pages are worth a pass here.
How do you make it filterable and searchable?
A short changelog is fine as a plain list. Once you have a few dozen entries, readers want to jump straight to what they care about. Add that with a focused follow-up:
Now add controls at the top of the page. First, filter buttons: All, New,
Improved, Fixed. Clicking one shows only entries with that tag and updates a
count. Second, a search box that filters entries live as I type, matching the
entry text. Keep the timeline layout, keep everything in the single HTML file
using plain JavaScript with addEventListener, and make sure a release heading
hides itself when all of its entries are filtered out.That last clause matters: without it you get empty date headings floating over nothing when a filter hides all their entries. Splitting the build into “make it look right” then “make it work” is the reliable path, the same two-step idea behind iterating on AI-generated pages.
What extra touches make it feel finished?
The base page works. A few small additions make it feel like a real product page rather than a demo. Add them one at a time so you can see what each does:
- An RSS or copy-link affordance. “Add a small link on each release that copies a direct URL to that entry, so I can point people at a specific release.” Deep links make a changelog genuinely useful in support replies.
- A subtle “new” indicator. “Mark releases from the last 14 days with a small dot so returning visitors see what changed since last time.”
- Grouped headings by month. For a long history, “group releases under month headings so the page skims quickly.”
- A little restraint on motion. A gentle fade as filtered entries appear reads as quality. The animation guide has the light touch to aim for, and it is easy to overdo here, so keep it quiet.
- A matching look. If you have a brand, hand the AI your colors and font so the changelog feels like part of the product. The feel-words vocabulary helps you describe the tone you want.
Add, test, add the next thing. If a change breaks the filtering, you know exactly which one to describe and fix.
Changelog vs roadmap vs blog
A changelog is one of a few pages that all sound similar and do different jobs. Knowing which one you are building keeps it focused.
| Changelog | Roadmap | Blog / release post | |
|---|---|---|---|
| Looks | Backward, shipped | Forward, planned | Backward, one release |
| Format | Short tagged entries | Now / Next / Later | Long-form article |
| Updated | Every release | Every few weeks | Occasionally |
| Reader question | “What changed?” | “What’s coming?” | “Tell me the story” |
| Best for | A living record | Setting expectations | Big launches |
Many products keep all three and link between them: the changelog for the running record, a roadmap page for what is coming, and the occasional long post for a headline feature. Start with the changelog. It is the one people check most and the one that is easiest to keep current.
Where should your changelog live?
Here is the thing that makes or breaks a changelog: it is only useful if it is current, and it is only current if updating it is trivial. A changelog buried in a doc, or living as an HTML file on your laptop, will be up to date for exactly one release and then quietly rot.
So the page needs to live at one address you can update in a minute. Take the self-contained HTML the AI produced and publish it with VisiblePage. You paste the HTML, or drop a ZIP if it grew into multiple files, and get a live URL immediately, with no build step and nothing to configure. The filters and search still work, because you are publishing the real page and not a screenshot, and it loads fast from the edge wherever someone opens it.
The part that matters most for a changelog is the single canonical link. Every release, you add the new entries and re-publish to the same URL, so every bookmark, every link in your docs, every “fixed in the latest release” reply you have ever sent now points at the current page with nothing to update on your end. You can keep it public so anyone can read it, or password-protect an internal changelog so only your team sees it, and point a custom domain like changelog.yourproduct.com at it so it feels native to the product. Because updating the page keeps the same link, nobody ever lands on a stale copy.
Try it now: Publish your AI-built changelog with VisiblePage and get a live link in seconds.
Frequently asked questions
Can AI really build a changelog page?
Yes. A changelog is a reverse-chronological list of releases with tagged entries, which is a layout modern AI models produce cleanly. Give it your releases as data, ask for a single self-contained HTML file with version headings and tag badges, then add filtering and search in a follow-up. You get a real page you can keep updating, no framework or build step required.
What should a changelog entry include?
A version or date, a short tag (usually New, Improved, or Fixed), and one line written for the reader that says what changed and why it helps. Skip internal ticket numbers and jargon. If a change is big, add a sentence or a small screenshot. The test is whether a customer who does not know your codebase understands what is different and whether they should care.
What is the difference between a changelog and a roadmap?
A changelog looks backward at what you have already shipped, dated and done. A roadmap looks forward at what you plan to ship, usually grouped into now, next, and later without firm dates. They answer different questions, so many products keep both and link between them.
How do I keep a changelog up to date without breaking the link?
Publish the page to one canonical URL and re-publish to that same URL each time you ship. With VisiblePage you paste the updated HTML and the existing link now shows the new release, so anyone who bookmarked it, or any docs that point to it, always see the current changelog with no dead links.
Do I need to know how to code to build a changelog with AI?
No. You describe the page and hand over your releases in plain text, and the AI writes the HTML, CSS, and JavaScript. You test it in the browser and give feedback in words. The only technical step left is publishing it, and a tool like VisiblePage turns the AI’s HTML into a live link with no setup.
The short version
A changelog page is a high-value, low-effort build: a dated, reverse-chronological list of what you shipped, each entry tagged New, Improved, or Fixed. Prompt for a static version first with your releases as data, add tag filters and search in a second prompt, and rewrite every line for the reader instead of the ticket queue, which is the single thing that makes it worth reading. When it works, publish it with VisiblePage so it lives at one canonical link you re-publish to every release. That way the changelog is always current, always at the same URL, and always proof that the product is alive.