Twenty-four of my tags file exactly one post
Across 219 posts I had 88 distinct tags and 24 appeared exactly once. A tag that gathers one item is a label, and labels do not help anybody find things.
Two hundred and nineteen posts, eighty-eight distinct tags, and twenty-four of those tags apply to exactly one post.
Every one of those twenty-four was a reasonable choice at the moment it was typed. Collectively they are a filing system that files nothing.
The case this post is about
One tag, used once.
It was accurate — the most precise word for what that post was about — and it created a category page with a single item on it, reachable from that post and from nowhere else. A reader who clicked it arrived back where they started.
Multiply that by a corpus and the filing system has a long tail of one-item categories and a handful of tags that actually gather anything. The precise tags are the useless ones, which is the opposite of the instinct that produces them.
This post follows that one tag, because the fix is counter-intuitive: prefer an existing tag that is nearly right over a new one that is exactly right, and make a new tag earn its place by having two or three posts that need it.
The symptom
A tag page with one post on it. Somebody arrives from a link, sees a category, follows it, and finds a single article — which tells them the category is not a category, and tells the platform's recommendation system nothing it can use.
The second thing is the distribution, which is lopsided in both directions. Three tags cover most of the corpus: a hundred and nineteen posts, a hundred and ten, a hundred and six. Those are so broad they barely discriminate. Then there is a long tail of twenty-four that each hold one item. The useful middle — tags specific enough to mean something and common enough to gather — is thin.
The third is that the one-offs are not mistakes. Each was chosen while writing a post, by somebody thinking about that post, and each describes it accurately. The problem is not accuracy; it is that a tag's value comes entirely from being reused, and reuse is a property of the corpus rather than of the post.
The fourth is that nothing surfaces it. Tags are entered per post, validated per post if at all, and nobody sees the distribution unless they go and count. A system that is wrong only in aggregate has no symptom at the point where decisions are made.
That is the general condition for this whole class of problem. Nothing is wrong with any post, so no review catches it; the defect exists only in the relationship between posts, which is a thing nobody is looking at while writing one. The only remedy is a periodic look at the set, and periodic looks are what get skipped.
Why the obvious fix failed
Pick tags carefully. The instruction everybody already follows. Care per post produces exactly the outcome described above, because the care is directed at describing the post rather than at matching what already exists.
Keep a controlled vocabulary. The right instinct, and on its own it ossifies: a fixed list cannot accommodate a genuinely new subject, so either the list grows without discipline or posts get filed under something approximate. The list needs a way to grow and a cost for growing it.
Use the section instead. Sections are coarse and few, which makes them reliable navigation and poor discovery. A reader who wants everything about one narrow subject is not served by a section containing a hundred and twenty posts, and that is the request a tag exists to answer.
Let the platform infer them. Available on some platforms and it optimises for its own model of similarity rather than for the distinctions you care about. It also moves the taxonomy outside your control, which is a poor trade for the one surface where your own sense of what connects to what is the value.
The actual mechanism
Treat tags as a shared index over the corpus, maintained against what exists rather than chosen per post.
read the existing distribution before adding a tag to a new post
prefer an existing tag that is close over a new one that is exact
earn a new tag by having two or three posts that need it, not one
prune tags that have stayed at one item after the corpus has grown
The second line is the one that feels wrong and is right. A slightly less precise tag that gathers ten posts is more useful to a reader than a perfectly precise one that gathers one, because the reader's request is "show me more like this" and precision with no neighbours cannot answer it.
The sub-case worth stating is when a one-off is correct: when it is the first of something you expect to write about again. The distinction is whether the tag is a bet on future posts or a description of this one, and the honest test is whether you can name the second post that would carry it.
Applying that test honestly is harder than it sounds, because at the moment of writing you can usually imagine a second post. The sharper version is whether the second post is one you have actually planned — a row in a backlog, a draft, something with a title — rather than one you can picture. Imagination is cheap at tagging time and the tail is made of it.
There is a related point about where tags do their work, which is not only on your own site. A syndication platform's discovery runs largely on its own tag system, and a tag that matches what readers there actually browse is worth more than one that matches your internal taxonomy. Those two sets overlap and are not the same, which is an argument for keeping them as separate fields rather than reusing one list for both.
Keeping them separate also removes a quiet source of pressure on the internal list. When one field serves both purposes, every consideration about what the external platform rewards leaks into decisions about your own taxonomy — and the platform's incentives are not yours, so the internal scheme slowly reshapes itself around somebody else's discovery model.
The fix
measure the distribution across the corpus, periodically
adopt an existing tag where one is close enough
reserve new tags for subjects with more than one post in view
report tags at one item, as a list, so the tail is visible
separate the platform's tags from your own, since they serve different readers
The distribution is the whole instrument — a tag at one item is the signal, and it is invisible without counting:
export function tagReport(posts: Post[]) {
const counts = new Map<string, string[]>();
for (const p of posts) {
for (const t of p.meta.tags) counts.set(t, [...(counts.get(t) ?? []), p.slug]);
}
const rows = [...counts].map(([tag, slugs]) => ({ tag, n: slugs.length, slugs }))
.sort((a, b) => b.n - a.n);
// The TAIL is the finding. Tags used once are either a subject that will grow
// or a synonym for one that already exists — and only a human can tell which.
return { rows, singletons: rows.filter((r) => r.n === 1) };
}
/** Before adding a tag, check whether an existing one is close enough. */
export function nearest(tag: string, existing: string[]) {
const norm = (s: string) => s.toLowerCase().replace(/[^a-z]/g, "");
return existing.filter((e) => norm(e).includes(norm(tag)) || norm(tag).includes(norm(e)));
}
The report over a corpus that had never been audited:
$ tag-report
compose 68 kotlin 41 agents 33 …
singletons 24 of 61 tags:
cdn(1) · fastlane(1) · guardrails(1) · codegen(1) · evals(1) …
$ nearest "codegen" --existing
→ generation, generators
Twenty-four tags at one post each. Each was reasonable when added, none is wrong, and together they are a filing system where a third of the drawers hold one sheet of paper.
The first line is what makes the rest possible, and it is a single pass over the posts you already
have. Until the distribution is in front of you, every per-post decision is made blind — which is
how eighty-eight tags accumulate without anybody choosing that.
What makes pruning tolerable is that it is not destructive in the way it sounds. Removing a one-item
tag from a post does not remove the post from anything a reader uses; it removes a page that had one
entry on it. The post keeps its broader tags and becomes findable through categories that have
company.
The exception is a one-item tag that somebody has linked to directly, which turns pruning it into a
broken URL rather than a tidy-up. That is rare for a tag page and worth checking before a sweep,
because the cost of the mistake is borne by whoever followed the link rather than by you.
## How we proved it
**The distribution is one pass over the corpus and it settled the argument immediately.** Eighty-eight
distinct tags over two hundred and nineteen posts; twenty-four at exactly one post; the top three at
a hundred and nineteen, a hundred and ten and a hundred and six. Nothing about those numbers needs
interpretation.
**The thin middle is the actionable part.** The broad tags are fine as they are and the one-offs are
the visible problem, but the real finding is how few tags sit in the useful range — specific enough
to be a subject, common enough to gather a handful. That is where the effort belongs and it is not
where attention naturally goes.
Attention goes to the extremes because both are visible: the broad tags are on every post and the
singletons look obviously wrong in a list. The middle has neither property — the tags there are
unremarkable, present on a handful of posts, and doing most of the useful work precisely because
nothing about them draws the eye.
**What I cannot tell you is what any of this did to traffic.** I have no before-and-after on
discovery through tag pages, because the measurement would need to isolate one navigation path over
a period long enough to matter. The argument here is structural — a page with one item cannot help
somebody find more — rather than measured.
**What I have not solved:** the merge. Several of my one-item tags are near-synonyms of each other
and of a larger tag, and consolidating them properly means deciding which survives and editing every
post that used the others. That is mechanical and tedious and I have not done it, which is why the
tail is still twenty-four rather than smaller.
The reason it keeps not happening is instructive about this whole class of maintenance: the work is
entirely clear, entirely mechanical, and improves nothing visible on the day it is done. Tasks with
that profile lose to everything else indefinitely, which is an argument for doing them as part of
something that is already happening rather than scheduling them on their own.
**And a limitation of optimising for gathering:** it biases toward subjects you already write about,
which is a mild force against covering something new. A tag earned by having two posts means the
first post on a genuinely novel subject is always under-tagged, and the honest answer is that the
rule should bend for a deliberate bet — stated as a bet rather than applied by accident.
Marking it as a bet also makes it reviewable later. A tag introduced deliberately for a subject you
intend to return to is a different object from one introduced because it described a paragraph —
and six months on, the first can be assessed against whether the follow-up posts arrived, while the
second can only be assessed against nothing.
**The thing that reframed it** was noticing which question a tag answers. I had been treating tags as
metadata describing a post, in the way a title or a date describes it. They are not: they are an
index, and an index entry with one item in it is not describing anything, it is just a longer way of
pointing at the item you already have.
## What this generalizes to
**A classification is only worth what its groups gather**, and groups of one are the sign that the
scheme is being applied per item rather than across the set.
The shape recurs in any taxonomy maintained from inside. Error codes defined per incident. Labels on
issues, added by whoever filed them. Categories in an expense system. Feature flags named for the
feature rather than the behaviour. In each case every individual choice is defensible and the
aggregate is a long tail of singletons that nobody can navigate.
So the question worth asking of any labelling scheme is **what does the distribution look like** —
because the answer is almost never examined, it takes one query to produce, and it will usually show
that a small number of labels are doing all the work while a long tail is doing none.
One post a week, no digest
New writing when it lands. No roundups, no course pitch, no "10 tips".