Planning the slug namespace on a short domain

There is only one namespace and it is flat

Unlike a website with directories and sections, a short domain typically has a single flat space of slugs. Every team, every campaign and every experiment draws from the same pool. The first person to claim a short, obvious word owns it, and reclaiming it later means breaking whatever already points there.

This is worth stating explicitly because it is unlike almost every other naming system people work with. There is no folder to isolate teams from one another, and no way to have two different things called the same thing. Every slug is a permanent, global decision made by whoever happened to create it.

Reserve the valuable words before anyone needs them

A handful of slugs are worth far more than the rest: your product names, the words you would use in a radio advertisement, single common words that are memorable when spoken. If these are not reserved, they will be consumed by whichever campaign got there first, and you will discover this the week you want one for something important.

Create these deliberately, point them at something sensible, and mark them as protected so they are not repurposed casually. Also reserve words that would embarrass you if someone else on the platform claimed them, and any word that resembles a login or payment page on your main site.

Block the slugs that will be typed by accident or by attackers

Certain slugs invite trouble regardless of what you do with them: login, account, verify, password, secure, pay, billing, support, admin. These are the words a phishing campaign wants on a domain that looks like yours, and they are also the words a confused user will type directly.

Reserve them and point them at an explanatory page on your main site, or refuse to allocate them at all. The cost is nothing and the benefit is that a plausible fraudulent link on your domain becomes one word harder to construct.

Choose a shape for generated slugs and stick to it

Automatically generated slugs should be visually distinct from hand-chosen ones, so that anyone reading a list can tell which is which. A fixed length of random characters is the usual approach. Decide the alphabet with care: excluding easily confused characters makes a slug that survives being read aloud, copied from print or transcribed over a phone.

Once published, the shape cannot be changed for existing links, so make this decision before volume accumulates. Mixing several generation schemes over the years leaves a namespace that looks accidental, which it will have been.

Decide case sensitivity once and enforce it

If slugs are case sensitive, two links can differ only by capitalisation, which is a trap in print, in speech and in anything typed by hand. If they are case insensitive, you have half as many possible slugs and no such trap. Both are defensible; having no stated position is not, because the platform has a behaviour and your users will find it.

Lowercase-only is the safer default for anything a person might type or read aloud. Where the platform preserves case, normalise at creation time so the stored value and the published value cannot drift apart.

Prefix by team or campaign only if you mean it

Some organisations introduce structure with a prefix and a separator, giving each team a portion of the namespace. This prevents collisions and makes ownership obvious in a report. It also makes every link longer and less memorable, which defeats part of the point of a short domain.

The reasonable compromise is to use prefixes for the bulk of internal and operational links, where readability in a list matters more than length, and to keep the unprefixed space for public, spoken and printed links that need to be short. Decide which category a link belongs to at creation, not afterwards.

Never reuse a retired slug

A slug that has been published is permanently associated with what it pointed at. People have bookmarked it, it appears in old messages, and it may be printed on something. Reassigning it to a new destination sends those people somewhere unexpected, and if the new destination is a purchase page or a form, the confusion is significant.

Retire slugs to an explanatory page rather than freeing them. The namespace is large enough that reuse is a false economy, and the discipline of never reusing is much easier to enforce than a rule with exceptions.

Keep a register of what is reserved and why

Reservations that exist only as links in an account are invisible; a colleague sees an unused-looking slug and repurposes it. A short register naming each reserved slug, its purpose and its owner turns an implicit convention into something a new person can follow.

Review it annually. Reservations made for a product that no longer exists can be released, and words that have become valuable since the last review can be added before someone else takes them.