What Makes a URL Slug Good: Stability, Readability and the Conflict Between Them
Published 11/26/2025 · 13 min read · Marketing & SEO tools
A slug is the human-readable part of a URL path, and it is asked to do two incompatible things: stay identical forever, because every link and every ranking signal points at the exact string, and read well, because people and search engines both see it. Optimising for readability means rewriting it when the title improves; optimising for stability means never touching it. Google recommends hyphens over underscores, words in the reader's own language, and percent-encoding for anything outside ASCII — which is where readability breaks, since a 27-character German slug becomes 37 characters encoded and a four-character CJK slug becomes 36. This site resolves the conflict by separating the two jobs: an internal identifier that never changes, and a public segment derived from each language's own title, capped at 70 characters, with stop words dropped only when that cap is exceeded. On the run of 9 August 2026 that produced six different public slugs for all 1,736 tools and 631 articles, with two collisions disambiguated deterministically. If you must change a slug, redirect permanently; Google's crawlers follow up to ten redirect hops, so chains are survivable but not free, and a temporary redirect passes no canonical signal at all.
A slug has two jobs that pull against each other: it is a permanent identifier and it is a piece of readable text. Length, hyphens, stop words, dates, non-ASCII characters and the identifier-plus-slug pattern that gets both properties — with the real numbers from a site that localises 1,736 tool slugs into six languages.
Two jobs, one string
The slug is the last segment of a URL path — the part that says what the page is. It is simultaneously an identifier, because links, bookmarks, analytics rows and whatever ranking memory a search engine holds are all keyed on the exact byte sequence, and a label, because it appears in the address bar, in a shared message, and often in the result itself. Identifiers want to be immutable. Labels want to be improved. That is the whole tension, and every rule about slugs is a way of managing it.
The identifier side is the expensive one to get wrong. Change a slug and every external link now points at a URL that no longer exists. A permanent redirect repairs that: Google's documentation states that the indexing pipeline uses a permanent redirect "as a signal that the redirect target should be canonical", while a temporary redirect is explicitly not used that way. So the type of redirect matters more than most people assume, and the common instinct to use a 302 because the change feels reversible is exactly wrong.
Redirects also compound. Google's own documentation states that by default its crawlers follow up to ten redirect hops. Ten is a generous budget, but it is a budget, and a site that renames its slugs every couple of years spends it silently: an eight-year-old link can already be four hops from the page. Every hop is also an extra round trip for a human on a slow connection. The practical rule is not "never chain" but "flatten": when you add hop number two, rewrite hop number one to point at the final destination.
Hyphens, underscores and why the convention exists
Google's URL structure guidance is unusually direct here: it recommends hyphens instead of underscores to separate words, "as it helps users and search engines better identify concepts in the URL". The reason is historical and mechanical rather than aesthetic. A tokeniser splits on characters that are not word characters, and the underscore has traditionally been treated as a word character — the convention that lets identifiers like max_speed stay one token in source code. So red_shoes could tokenise as one term and red-shoes as two.
Whether any modern search engine still behaves that way is not something anyone outside can verify, and it does not matter much: the convention is now so universal that a slug with underscores mostly signals a site nobody has looked at in a decade. The one place the distinction still bites hard is a hyphen inside a compound word. In German a compound is one word, so a slug that hyphenates it splits a term that should stay whole. This site handles that by deriving the German slug from the German title, which already spells the compound as one word, rather than by translating an English slug word by word.
Length, and where a result stops showing the path
Nobody publishes a character limit for slugs, because there is not one. What exists is a display budget: a result shows the site name and a shortened path, and a browser's address bar has a finite width. Both truncate, both truncate differently on a phone, and neither is documented. So a length rule has to be chosen rather than looked up. This site chose 70 characters, and the corpus now contains slugs that hit it exactly — the longest is the 70-character Portuguese slug quantos-montantes-parede-preciso-estrutura-por-espacamento-comprimento.
The interesting part is what happens when a title is longer than the budget. Truncating mid-word produces a slug that reads as an error. Truncating at a word boundary loses whichever words came last, which in most languages are the specific ones. The generator here does something else: it removes stop words first — a, an, the, of, for, and, to, your, with in English, and the corresponding lists in the five other languages — and only then drops trailing words, never going below three. That ordering matters, because a stop word is the one part of a slug that carries no search signal and costs real characters.
There is a second trim that happens before any of that. A title of the form "Main headline: the qualifier" or "Main headline (an aside)" contains two things, and only the headline belongs in a path — the qualifier is what a meta description is for. So the generator drops parentheticals and cuts at the first colon or dash before it slugifies anything. That single rule removes most length problems before the stop-word list is ever consulted.
The non-ASCII question, answered six times over
Google's guidance is to use words in the reader's own language, transliterated where applicable, and to percent-encode anything outside the ASCII range. Those two sentences are in tension for every language that has accents, and the tension is measurable. Encode the German phrase grundstücksfläche-berechnen and 27 characters become 37 — a 37.0% expansion, because each of ü and ä costs six characters as %C3%BC and %C3%A4. A Spanish slug with one ñ grows 19.2%. A fifteen-character Cyrillic slug becomes 85 characters, 5.67 times longer. A four-character CJK slug becomes 36, nine times longer.
Whether that matters depends entirely on where the URL is going to be seen. A modern browser decodes the path back to readable characters in the address bar, so a reader on the site sees the accents. Paste the same URL into a plain-text email, a chat client that does not decode, an analytics report, a spreadsheet, a log line or a printed slide, and the reader sees the percent signs. A URL is copied more often than it is typed, and the copy lands in the ugly context often enough that this is a real cost, not a theoretical one.
This site splits the difference by language rather than pretending one answer fits all six. German maps ä, ö, ü and ß to ae, oe, ue and ss, which is the ordinary German convention for ASCII text and yields grundstuecksflaeche-berechnen at 29 characters — eight shorter than the encoded form and readable everywhere. The other five strip the diacritic instead, so contraseñas becomes contrasenas and régime becomes regime. Neither choice is wrong; they are different answers to the question of what a reader in that language expects a stripped word to look like.
Six languages, six slugs, one identifier
The pattern that gets both properties at once is old and unglamorous: keep a stable identifier that never changes, and let the readable part be derived rather than authored. Forums and issue trackers do it with a numeric id followed by a slug, so /42/some-old-title and /42/anything-at-all both resolve, and the slug can be rewritten without breaking a link. This site does the same thing with a string identifier instead of a number: the registry name of a tool or an article never moves, and the public segment is generated from that item's own title in each language.
The run of 9 August 2026 covered 1,736 tools and 631 articles across six locales. Nothing fell back to the identifier for want of usable text, and exactly two tool slugs and two article slugs collided inside a locale and were disambiguated by appending the distinguishing part of the identifier — deterministic, so a rerun produces byte-identical output. The churn is the interesting figure: in French, Spanish, Portuguese and Italian every single one of the 1,736 tool slugs differs from the identifier, in German 1,705 of them do, and in English only 397, because the identifiers were English to begin with.
Deriving the slug from the translated title also solves a problem nobody thinks about until they hit it: elision. A French tool called Calculateur d'IMC must not become calculateur-dimc, and an Italian one called Calcolatrice dell'IVA must not become calcolatrice-delliva. The generator turns the apostrophe into a boundary and then drops the elided particle, so both become calculateur-imc and calcolatrice-iva. That is a language-specific rule with no English equivalent, and it is the kind of thing a hand-written translation table gets wrong on entry number four hundred.
Dates, and the other things that expire inside a path
A date in a slug is a promise you will regret. It is not a search-ranking question — nobody has shown that a year in a path helps or hurts — it is a maintenance question. The moment the article is updated, the path says something false, and the two ways out are both bad: leave it stale, or rename and redirect. Blogs that put /2019/03/ in the path have the same problem one level up, and they usually solve it by never updating anything.
The same logic applies to anything that describes a state rather than a subject: a version number, a price, a season, a country you currently ship to, the word "new". Put the state in the page and in the structured data, where changing it costs nothing, and keep the path describing the thing. If the date is genuinely part of the identity — a specific year's tax rules, a specific season's fixtures — then it belongs there, because that page really is about that year and will never be updated to be about another one.
| Decision | If you optimise for readability | If you optimise for stability | What this site does |
|---|---|---|---|
| Language of the segment | The reader's language | One language everywhere | Six, derived from each language's own title |
| Accented characters | Keep them, and accept the percent escapes | Strip them, and accept the loss | German maps to ae/oe/ue/ss; the other five strip the diacritic |
| Word separator | Hyphen — Google recommends it explicitly | Hyphen — same answer, nothing to trade off | Hyphen, with the apostrophe treated as a boundary |
| Length | As long as the headline needs | Short, so nothing ever has to be trimmed later | Capped at 70 characters; stop words go only above the cap |
| Date in the path | Helpful when the page really is about that year | Never — it guarantees a future rename | No date; the publication date lives in the page and its schema |
| Renaming a slug | Whenever the title improves | Never, once anything links to it | Freely — the identifier never moves, so only the public segment changes |
Frequently asked questions
- Does changing a URL slug hurt rankings?
- It costs you the accumulated links unless you redirect, and it costs a little even then. Google's documentation says a permanent redirect is used by the indexing pipeline as a signal that the target should be canonical, so a correctly implemented permanent redirect preserves the signal; a temporary redirect explicitly does not. What you cannot recover is anything that does not follow redirects — a printed URL, a hard-coded citation, a copy pasted into a document. The honest answer is that the rename itself is cheap and the tail of broken references is not, so rename when the old slug is actually wrong, not when the new one would be slightly nicer.
- How long should a slug be?
- There is no published limit, so pick one and enforce it. This site uses 70 characters, which comfortably holds a headline in all six languages while staying inside what a result and an address bar will show without truncating on a phone. What matters more than the exact number is the order of operations when you exceed it: drop the subtitle after the colon first, then the stop words, then trailing words — and never cut mid-word, because a slug that ends in a fragment reads as a bug rather than a page.
- Should I translate my slugs or keep them in English?
- Translate them if you have real translations of the page. Google's URL guidance says to use words in your audience's language, transliterated where applicable, and the reason is straightforward: a German reader landing on a German page whose path ends in an English word has been shown two names for one thing. The failure mode to avoid is a machine-translated path on a page that is otherwise English — that is worse than leaving the path alone. Derive the slug from the translated title you already have, not from a separate translation of the slug itself.
- Can I use accented or non-Latin characters directly in a slug?
- Technically yes — the browser encodes them for you and Google's guidance is simply that non-ASCII characters should be percent encoded. Practically, decide where the URL will be read. In an address bar it decodes back to the accented form and looks fine. In plain text it does not: a 27-character German slug becomes 37 characters of percent escapes, a 15-character Cyrillic one becomes 85, and a four-character CJK one becomes 36. For a Latin-script language, transliterating or stripping the diacritic buys readability everywhere at almost no cost. For a non-Latin script the trade is genuinely harder, because stripping is not an option and your readers will never see the encoded form in their own browser anyway.
- Is the identifier-plus-slug pattern worth the ugly number in the URL?
- It is worth it whenever titles change and links matter, which describes most content that lives longer than a year. The number buys you the ability to rewrite the readable part at will, with no redirect and no chain, because resolution never depended on it. The cost is a path that looks machine-generated. This site takes the middle route: the identifier is a readable string rather than a number, it does not appear in the public path at all, and the per-language slug maps back to it — so a renamed title changes six public slugs and breaks nothing internally.
Articles you may find interesting
All guides →Related tools
Sources
- Google Search Central — Keep a simple URL structure — hyphens over underscores, percent-encoding for non-ASCII, words in the audience's language
- Google Search Central — Redirects and Google Search — a permanent redirect is a canonical signal, a temporary one is not
- Google Search Central — HTTP status codes and network errors — "By default, Google's crawlers follow up to 10 redirect hops"
- IETF — RFC 3986, Uniform Resource Identifier (URI): Generic Syntax — percent-encoding and path segments
- WHATWG — URL Standard — percent-encode sets and how browsers render encoded paths
Spotted a mistake in this article?