Most teams building client websites skip releases and tags entirely. The thinking is that tags and semantic versioning are a library thing, something npm packages do, not something a marketing site needs. You just merge to main and deploy. It works right up until the moment it does not, and then you discover what the discipline was actually for.
I think releases and tags belong on client sites, not just on published packages, and the reasons all show up at the worst possible time.
A rollback point you can trust
Here is the scenario that converts people. Something breaks in production. A page is down, a form has stopped submitting, a client is calling. You need to get back to a known-good state, now, while you figure out what went wrong. If your history is a long flat line of merges to main, "get back to a known-good state" means scrolling through commits trying to remember which one was live last Tuesday, which is exactly the kind of detective work you do not want to be doing while the site is down.
If you tag your releases, that problem evaporates. The last release is right there, labelled, and rolling back to it is a known operation instead of an investigation. The tag is a point in history you have deliberately marked as "this shipped," and in an incident, having a clean point to return to is the difference between a five-minute recovery and an hour of stress. The discipline costs almost nothing when things are calm and pays for itself entirely in the one moment things are not.
A changelog the client can actually read
The other everyday benefit is the changelog. A GitHub release is not just a tag; it is a place to write down what went into this version in human language. What was added, what was fixed, what changed.
That record is worth far more than developers expect, because it is readable by people who are not developers. When a client asks what they paid for last month, or what changed between two versions, or whether a particular fix has gone live yet, the answer is a release note, not a database of commit messages written for other developers. It turns the project's history into something you can point a stakeholder at. It also helps you, six months later, when you are trying to remember when a particular change shipped and why. Commit messages are notes to other developers. Release notes are notes to everyone, including future you.
Semantic versioning is a discipline, not a library ritual
The piece people most associate with packages is semantic versioning, the major-minor-patch scheme, and the assumption is that it only matters for things other code depends on. I think the discipline matters even for client sites, because the discipline is the point, not the dependency management.
Versioning forces you to think about the nature of each release. Is this a small fix, a new feature, or something that changes behaviour people were relying on? Bumping the right number means you have actually classified what you are shipping rather than throwing another undifferentiated deploy over the wall. That habit of naming the size and shape of a release is valuable regardless of whether anything imports your code. It gives the project a rhythm and a vocabulary: everyone can talk about "the 2.0" or "that patch last week" and mean something specific, instead of gesturing vaguely at "the deploy from around then."
Why the teams that skip it regret it
The reason skipping releases and tags feels fine is that the cost is deferred. Nothing bad happens on the day you decide not to bother. The flat-line-to-main workflow is genuinely simpler in the moment, and the discipline looks like pure overhead when everything is working.
The regret arrives later and all at once: the production incident with no clean rollback point, the client question you cannot answer cleanly, the inability to say what shipped when. None of these are catastrophic on their own, but they are all entirely avoidable, and they are avoided by a habit that costs a few minutes per release. That asymmetry is why I tag and release even on a small client site. The effort is tiny and constant; the payoff is occasional but exactly when you most need it. Disciplines that protect you during incidents are worth keeping precisely because you cannot schedule the incident.
