What Makes a Good URL Slug

A slug is the human-readable part of a URL that identifies one page. It is also, uniquely among the things you write when publishing, close to permanent: a title can be rewritten, a description tuned, an image replaced, but changing a slug means either breaking every existing link or maintaining a redirect for as long as the site exists. That asymmetry should drive every decision below.

Hyphens, never underscores

Search engines have long treated a hyphen as a word separator and an underscore as a word joiner. A path of url_slug_guide is read as a single token; url-slug-guide is read as three words. Since the whole point of a readable slug is that the words in it can be matched, the underscore quietly removes the benefit you were paying for.

Everything should also be lowercase. Paths are case-sensitive on most servers, which means /Guide and /guide can be two different pages holding the same content — duplicate content created by nothing more than a capital letter.

How long is too long

There is no length at which a URL is penalised. What there is, is a width at which search results truncate the displayed URL, generally somewhere around sixty to seventy characters for the visible portion. Past that, the end of your carefully chosen slug is replaced by an ellipsis and stops persuading anyone to click.

Three to five meaningful words is a good target. The test is whether someone could read the URL aloud over the phone and roughly guess what the page contains.

good:  /articles/what-makes-a-good-url-slug
poor:  /articles/what-makes-a-good-url-slug-in-2026-a-complete-guide-for-beginners
bad:   /articles/post?id=48211

Stop words: usually drop them, sometimes not

Words like a, the, of and for carry almost no matching value and eat the character budget. Removing them is normally right. The exception is when a stop word changes the meaning or makes the slug unreadable: how-to-cook-for-one is not improved by becoming cook-one, and a slug nobody can parse has lost more than it saved.

Optimise the slug for a human reading it in a search result. The machine reading it is already satisfied by far less.

Dates and numbers are a trap

Putting a year in the slug — best-tools-2026 — guarantees one of two futures. Either you update the content and the URL now lies, or you create a new URL each year and split the accumulated links across several pages that compete with each other.

Put the year in the title, where it can be edited freely, and leave it out of the slug. The same applies to dates in the path structure: /2026/08/my-post makes every post look stale the following January, for no benefit the publication date in your structured data does not already provide.

Accents and non-Latin scripts

Non-ASCII characters are legal in a URL and are encoded when transmitted, so café becomes caf%C3%A9 in anything that copies or logs the link. That is ugly, fragile when pasted between systems, and hard to type. Transliterating to ASCII — cafe — keeps the link clean and shareable.

For scripts with no reasonable Latin transliteration the calculation changes: a readable slug in the reader's own script is generally worth the encoded form, since browsers display it decoded anyway.

Uniqueness, and what to do when it collides

Two pages cannot share a slug, and near-duplicates are almost as bad — they compete for the same queries and split their signals. When a genuine collision happens, add a distinguishing word rather than a number: not my-post-2, but my-post-for-teams. A numeric suffix tells a reader nothing and tells a search engine even less.

If a slug does have to change, redirect the old one permanently and keep the redirect indefinitely. Most link equity survives, but not all, and the crawl budget spent rediscovering the page is never refunded. That is the cost this whole list exists to avoid paying.