How to host your changelog on your own domain

A changelog earns its value slowly. Entries accumulate, customers bookmark the page, support tickets link to it, other sites cite it, and search engines gradually learn that it answers questions about your product. All of that accrues to whatever domain the page lives on. If the page lives at yourproduct.somevendor.io, it accrues to the vendor. This guide covers where a customer-facing changelog should live and the practical ways to put it there. If you're still deciding between a changelog, release notes, and product updates, and which channel suits each, we've covered what to write where separately.

Why the domain matters

Three reasons, in rough order of how quickly you'll feel them.

Trust. A customer who clicks "What's new" expects to stay on your site. Landing on a third-party domain is a small jolt, and it makes the page read as an outsourced artefact rather than the official record. For a page whose entire job is credibility, that's a real cost.

Search. Over time a changelog ranks for a long tail of queries: your product name plus "changelog", plus a feature name, plus a bug someone remembers hitting. Every entry is a page of specific, dated, factual content, which is exactly what search engines like. When another site links to one of your entries, that link strengthens your domain. Host the page on a vendor's domain and the rankings and the backlinks build up their authority instead of yours.

Portability. Tools get replaced. If the changelog has always lived at your URL, you can change how it's generated without breaking a single inbound link. If it lived on a vendor's domain, migrating means abandoning every link and citation the page ever earned.

Subdomain or subdirectory

The two conventional homes are yoursite.com/changelog and changelog.yoursite.com. Both are yours, and either is a large improvement on someone else's domain, so this decision matters less than the previous one. The tradeoffs:

A subdirectory keeps the changelog inside your main site as far as search engines are concerned, so it benefits directly from the authority your homepage and docs already have. The catch is technical. If a third party serves the page, putting it under a path on your apex domain means a reverse proxy or rewrite rules at your edge, which not every setup makes easy.

A subdomain is trivial to wire up. Add a CNAME record pointing at whatever host serves the page and you're done, which is why nearly every hosted tool supports custom domains this way. The cost is a long-running SEO debate about whether subdomains fully share the main domain's authority. The honest summary is that opinions differ, subdirectories are the safer bet for pure SEO, and the difference is small next to the gap between your domain and a vendor's.

If your infrastructure makes the subdirectory easy, take it. If not, the subdomain is fine, and it's what most teams end up with.

The practical options

A static page or site. Markdown in your repo, rendered to HTML, deployed alongside your marketing site. Full control over markup and design, no vendor, no monthly cost, and the subdirectory comes free. The cost is that you're building the plumbing yourself: per-entry permalinks, a feed, and some publishing flow. More importantly, the friction of publishing is now yours to manage, and friction is what kills changelogs. A page that's cheap to host and awkward to update goes quiet within a quarter.

Your existing CMS. If your site already runs on a CMS or blog engine, add a changelog collection with its own template. You inherit the domain, the SSL, and a publishing flow people already know. The thing to avoid is folding entries into the ordinary blog stream, where they age into an unnavigable pile. The changelog needs its own page, its own URL, and a consistent structure.

A dedicated hosted tool. The category exists because the plumbing is genuinely fiddly: hosted tools give you the page, the feed, per-entry links, and usually widgets and email subscriptions, without you maintaining any of it. Some go further and draft the entries from your merged work; ChangelogPilot, which we build, is one of those, and it serves your changelog on your own domain over a CNAME with automatic SSL. Whichever tool you look at, the question this article turns on is custom-domain support. Many hosted tools offer it, typically via CNAME, though some reserve it for paid plans. A tool that can only serve your changelog from its own domain gives away the compounding value described above, and that's worth walking away from.

What matters whichever you choose

A custom domain with working SSL. The certificate should be provisioned and renewed automatically once the DNS record is in place. A browser security warning on the page that's meant to build trust is worse than having no page.

One stable URL, and permalinks per entry. Pick the URL once and keep it. Every entry needs its own permanent link so a support reply or a forum post can cite a specific change years later. If you ever restructure, redirect the old URLs.

An RSS or Atom feed. Feeds are how integrators, aggregators, and your most attentive customers follow the page without visiting it. It's an old technology and it has quietly outlasted most alternatives.

Keep it indexable. No login wall, no noindex, and entries present in the served HTML rather than assembled entirely by client-side JavaScript. Include the page in your sitemap. An unindexable changelog does its job for existing customers and forfeits the search value entirely.

The order to decide in: choose the URL first, then choose whatever combination of tooling can serve it and keeps publishing cheap enough that you'll actually keep the record up. The generator behind the page can change every year without anyone noticing, as long as the URL underneath it never does.

If the hosted route is the one you want, that is what we build ChangelogPilot for: your changelog on your own domain, with the feed, per-entry links, and SSL handled, and each entry drafted from the PRs you've already merged.