What should a SaaS changelog say to people who are not customers?

Who is actually reading your SaaS changelog?

Not mainly your customers. Customers find out about changes from the product itself, or from an email, or from support. The people reading your changelog deliberately are evaluators, competitors and journalists, and evaluators are the ones you should be writing for.

That reframing changes what belongs in it. A changelog written for existing users is a list of what moved. A changelog written with an evaluator in mind is evidence that the company ships, that it fixes things, and that it tells the truth about both.

Most of the ones I read are written as if nobody outside the company will ever see them, which is a strange assumption for a public page on your own domain that search engines index happily.

Why is a changelog a sales page you did not plan?

Because a buyer comparing two vendors will look for evidence of momentum, and your changelog is the only page on your site where momentum is a matter of record rather than a claim. Your homepage asserts you are innovative. Your changelog either demonstrates it or quietly contradicts it.

It also answers a question nobody asks out loud: is this company still alive. A changelog with nothing in it for eight months tells a prospect something your marketing site is working hard to obscure, and they will believe the changelog.

The same logic applies to how you handle problems. A prospect who finds honest fix entries learns that things break here and get fixed, which is more reassuring than a page implying nothing ever breaks. It is the same instinct behind what a status page should say during an outage.

What does a prospect look for that a customer does not?

Pace, priorities and honesty. A customer wants to know what changed in the thing they already use. A prospect wants to know whether you are working on the problems they care about, how fast you move, and whether your roadmap has been drifting somewhere they do not want to go.

Priorities are the signal people underestimate. If every entry for six months is about a part of the product the prospect will never touch, that is genuinely useful information for them, and it may correctly disqualify you. Being disqualified early is cheaper for both sides than being disqualified in month four.

Honesty shows up in the small entries. A changelog that only ever announces features reads like marketing. One that includes the unglamorous fixes and the occasional removal reads like engineering, and engineering is more persuasive to a technical buyer than any feature announcement. This connects to what proof a skeptical buyer looks for first.

Why do most changelogs fail Google's own content test?

Because they are lists of unexplained fragments. Google's guidance on helpful content asks whether the content provides original information, reporting, research, or analysis, and whether someone will leave feeling they have learned enough about a topic to help achieve their goal. "Improved performance on the dashboard" does neither.

The irony is that a changelog should be the easiest page on your site to pass that test. Google also asks whether content clearly demonstrates first-hand expertise and a depth of knowledge, giving the example of expertise that comes from having actually used a product or service. You built the thing. Nobody on earth has more first-hand knowledge of what changed and why.

So the failure is not a lack of material, it is a lack of sentences. One line of explanation per entry, saying what problem this solved and who it was for, turns a fragment into something a person can learn from. Google's framing of the "why" applies directly: the reason for writing should be that you are creating content primarily to help people, content useful to visitors if they come to your site directly.

Should every entry get its own page?

No. Most entries belong on one dated page together, and only the substantial ones deserve a page of their own. Splitting every bug fix into a separate URL gives you hundreds of thin pages that say almost nothing, which serves nobody.

My threshold is whether an entry could reasonably be the answer to a search someone actually types. A new integration, a significant capability, a change in how something is priced or limited: those can carry a page. A copy fix in a tooltip cannot, and pretending otherwise is how a changelog becomes an indexing problem.

The exception is worth knowing because it earns real traffic. If you have shipped support for a named third-party tool, that is a page with a natural audience searching for exactly that pairing, and it belongs in your main site rather than buried in a changelog. I have written about whether every integration deserves its own page, and the answer shapes this decision too.

How much detail is too much?

When a reader outside your company cannot tell why an entry mattered, you have gone too deep rather than not deep enough. Internal component names, ticket numbers and refactors that changed nothing observable belong in your commit history, not on a public page.

The useful test is whether the entry names a problem or names a mechanism. "Fixed an issue where exports over ten thousand rows would time out" names a problem a reader can recognise in their own situation. "Migrated the export service to the new queue" names a mechanism only you care about, even though it might be the same work.

Length is rarely the problem. Two sentences per entry is plenty, and the second sentence is where almost all the value is, because that is where you say who this was for. Most changelogs stop after the first sentence and wonder why nobody reads them.

What should you never put in a changelog?

Anything you cannot stand behind in six months. Vague future promises, dates for things not yet built, and performance claims you have not measured. A changelog is a dated public record, and unlike a marketing page nobody expects it to be quietly edited later.

I would also leave out competitor comparisons, however tempting. An entry framing a new feature as catching up with or beating a named rival ages badly and invites a response. State what you shipped. Let the reader do the comparison, which they were going to do anyway.

The subtler mistake is security theatre in both directions. Do not list vulnerability details that help an attacker, and do not pretend security fixes never happen. "Resolved a security issue affecting a subset of accounts, with no action needed from you" respects both constraints and is more reassuring than silence.

How do you write one entry properly?

Name what changed, then name who it was for, in two sentences. "You can now export filtered views to CSV" followed by "This was the most common request from teams who report to finance monthly." That second sentence is the whole difference between a log and a document.

Group entries by audience rather than by system where you can. A prospect scanning for whether you serve their function will find it faster if the entries are organised around who benefits, and the organisation itself signals that you think about users by role rather than by codebase.

Put a date on every entry and never backdate one. Google's content guidance asks whether it is self-evident to visitors who authored the content, and whether pages carry a byline where one might be expected. A changelog with a real date and a real team behind it is the kind of page that reads as accountable.

What should you do next?

Open your changelog and read the last ten entries as a stranger evaluating your company. If you cannot tell from them what the product is for, who it serves, or whether the team is shipping, rewrite those ten entries with a second sentence each. That is an afternoon of work.

Then decide who owns it. A changelog nobody owns becomes a dumping ground for release notes copied from tickets, and the buyer-facing value disappears within a quarter. One person adding one sentence of context per entry keeps the whole thing worth reading.

Across 350+ published articles on how search and answer engines read pages, the consistent finding is that the pages with the most unique information are the ones companies write with the least care. Your changelog is the clearest example of that. If yours reads like a commit log, reach out and let's turn it into something that sells.