What a URL Slug Is, and How to Write One That Holds Up

A URL slug is the readable piece at the end of a web address that names one specific page — the what-makes-a-good-url-slug in the address of the page you are reading. It sits after the domain and any section folders, it identifies the page rather than the site, and on nearly every publishing platform you can edit it. Its one job is to tell a person what they are about to open when the link arrives with no other context around it.

Split an address into its parts and it is obvious which piece is which. In example.com/blog/what-makes-a-good-url-slug/, the domain says who is publishing, /blog/ says what kind of thing it is, and the last segment says which one. Change the slug and you are pointing at a different page — which is the whole reason changing one is a bigger decision than it looks.

What the slug is actually for

Two things, and they pull in the same direction.

It is a preview. Links get pasted into messages, emails and documents stripped of everything else — no title, no thumbnail, no surrounding sentence. An address ending in ?p=4127 — what WordPress serves until you set a permalink structure — tells the recipient nothing and looks like something they should not click. A slug of returns-and-refunds answers the question before the page loads.

It is a description search engines can read. Google's own guidance on URL structure is to use words rather than opaque identifiers, and search results still show the URL, or a breadcrumb trail built from it, under the title. That is worth something. It is not worth much: the words in a slug are a weak signal compared with the page's content, and rewriting a URL does not make a worse page beat a better one. Treat it as a finishing touch rather than a lever and you will make sensible decisions about it.

What a good slug looks like

• Lowercase, always. Paths are case-sensitive on most servers, so /About/ and /about/ can serve as two separate pages competing with each other.
• Hyphens, not underscores. Google has said for years that it reads a hyphen as a word break and an underscore as a joiner, which makes url_slug a single token to it.
• Three to six words. There is no length penalty and no prize for brevity on its own. Cut the filler, keep the words someone would actually type.
• Describes the page, not the site. /blog/acme-blog-post-about-shipping/ wastes half its characters on things the domain already said.
• Nothing that expires. A year, a version number or a "10" in front of a list all become wrong eventually, and fixing them means changing the URL. Some platforms fold the publication date into the path automatically; if yours does and you write anything evergreen, turn it off before you publish rather than after.
• Unique across the site. Two posts called "Getting Started" produce the same slug, and most content systems resolve the clash quietly by hanging a -2 off the second one.

Why "lowercase it and swap spaces for hyphens" breaks

That is everyone's first implementation, and it survives until the first title with real punctuation in it.

• Runs of separators. A colon followed by a space becomes two separators, so "Slugs: a guide" turns into slugs--a-guide unless you collapse repeats.
• Edges. A title ending in a question mark leaves a hyphen dangling off the end; one opening with a quotation mark leaves one at the front.
• Apostrophes. Treat them as separators and "don't" becomes don-t. They should be deleted, not replaced, so you get dont.
• Ampersands. Dropping the character loses the word. "Terms & conditions" should become terms-and-conditions, not terms-conditions.
• Accents. A rule that deletes everything outside the ASCII range eats them, so "café" arrives as caf.

That last one is the trap worth understanding, because the standard fix is only a partial fix. Unicode can spell é either as one character or as a plain e followed by a combining accent mark. Slug libraries exploit this: normalise the text to its decomposed form, then throw away the combining marks. One line of code, and é, ñ, ü, å and ç all fold to their plain letters.

It does nothing for ß, ø, æ, œ, ł or þ. Those are not accented versions of anything — they are their own letters, with no base character inside them to uncover — so they slip past the normalisation step and get deleted by the ASCII filter instead. "Straße" comes out as strae, silently, and nobody notices until a German reader does. The only cure is a lookup table that spells them out, which is why generating the slug with something that carries one beats writing the regex yourself for the fifth time. Paste a list of titles, one per line, and you get the folded, trimmed, length-capped version of each.

Can a slug be in Cyrillic, Greek or Chinese?

Technically yes. A URL may only contain a narrow set of ASCII characters, so anything else is percent-encoded: converted to UTF-8 bytes, with each byte written as a percent sign and two hex digits. Browsers do this automatically and then hide it, so a Russian or Greek slug looks perfectly clean in the address bar.

The encoding surfaces the moment the link leaves the browser. Cyrillic letters are two bytes each in UTF-8, and each byte costs three characters to encode, so every letter becomes six characters of hex noise in a plain-text email, a chat message or a spreadsheet cell. Chinese and Japanese characters are three bytes, so they cost nine. If you want to see exactly what a given slug turns into before you commit to it, run it through the URL encoder and look at the version that gets copied. Percent-encoding, explained properly covers why one accented letter produces two escapes and how links end up double-encoded.

So it is a judgement call, not a technical one. A site whose readers are all Greek loses nothing by using Greek in its URLs. A site whose links get shared internationally is better off transliterating — and transliteration is genuinely hard, because the correct Latin spelling of the same Cyrillic letter differs between Russian and Ukrainian. Generic tools, including ours, drop those characters and report how many went missing rather than guess at a spelling.

Should you strip out words like "the" and "of"?

Sometimes. Removing stop words shortens a URL and removes nothing a reader needs: the-history-of-the-slug and history-slug point at the same idea.

The failure mode is that some titles are mostly small words. "The Who" reduces to who. "To Be or Not to Be" reduces to not, because a stop list holding "to", "be" and "or" eats five of the six words. An automatic filter cannot tell the difference between a filler word and a load-bearing one, so if you turn the option on, read the result before you publish it rather than trusting the output.

The other thing to watch is that the filter runs after the ampersand has been spelled out, so the "and" it just created is a stop word like any other and gets removed again. "Terms & conditions" gives terms-and-conditions normally and terms-conditions with stop words on. Neither is wrong, but pick one on purpose.

What happens if you change a slug after publishing?

Every link to the old address breaks: other people's links, bookmarks, the entry sitting in Google's index, the URL in the newsletter you already sent. The page is not moved, as far as the web is concerned. It is deleted and a new one appears.

The fix is a 301 redirect from the old path to the new one, which tells browsers and crawlers that the page moved permanently and passes the accumulated ranking signals across. Set it up before or at the same time as the change, never afterwards, and then keep it indefinitely — an old link can sit unclicked in a document for years and still work when someone finally opens it.

Which is the real argument for spending a minute on the slug at the start. It is one of the few things about a page that is genuinely expensive to fix later. The title, the images and the text can all be rewritten this afternoon with no consequences at all.

Last updated September 19, 2026