URL Slug Design Guide: Length, Keywords, and Language Trade-offs

The slug is the only part of a URL you fully control

Of everything in a URL, the domain, the protocol, and the path structure are decided long before a content author shows up. The slug — that stretch of title-turned-path — is the only part chosen word by word by the content itself. It serves three readers at once: search crawlers (word forms and relevance), search users (the readable URL line in results affects clicks), and whoever pastes that link in the future.

Designing a slug comes down to four decisions: the separator, the length, the keyword, and the language. This guide takes them one at a time, then covers the batch workflow.

Decision one: hyphens, almost unconditionally

Google's own SEO documentation says it plainly: use hyphens to separate words in URLs, not underscores. Google's tokenizer has historically treated underscores as word-internal characters (url_slug risked being read as one token, urlslug), while hyphens have always been separators. Every major engine and CMS (WordPress by default) operates on the hyphen convention. Underscores belong in filenames and programming identifiers (snake_case) — a different job.

Decision two: length is an information-density question

A slug is not a full transcription of the title. Titles can run long to earn the click; slugs only need to carry retrieval signal:

• 3–5 words, under 60 characters is the practical sweet spot: result pages truncate longer URLs
• SEO weight past the fifth word trends to zero — cut function words and filler
• Keep the highest-information entity words: "The Beginner's Guide to Café Marketing in 2026" → cafe-marketing-guide, not a transcription of the whole title

Decision three: one keyword, early, never stuffed

Put the page's core keyword in the slug — as early as natural — and stop at one. url-slug-design beats some-thoughts-about-url-and-slug-design. Stuffing (url-slug-slug-url-generator) reads as a negative signal to ranking algorithms.

Decision four: the non-ASCII trade-off

Titles in Chinese, Japanese, Arabic, or accented languages raise a fork with two defensible branches:

1. Keep the original script (中文标题-测试 style): the URL percent-encodes fine, modern browsers display the original characters in the address bar, and readers of that language share it without friction — major Chinese sites use this heavily
2. ASCII only (strip non-ASCII for a pure English slug): safer for international audiences and technical communities (repos, docs sites), avoiding encoded-length bloat and cross-system display differences

There is no single right answer, but be consistent within a site. Mixed-script input (a product name inside a localized title) keeps the non-ASCII words and joins the English parts normally.

Conversion rules at a glance

Once the design is set, the mechanical rules:

The batch workflow

The real-world shape of this task is a list: migrating a blog, backfilling slugs for a product catalog. The slug generator handles line-by-line batches — paste a list of titles and each line gets its own slug. Non-ASCII characters are kept by default, with an ASCII-only toggle for the pure-English route, and the separator switches between hyphen and underscore. Before shipping a slug into production, preview its encoded form with the URL encoder; the companion text case converter handles the camelCase/snake_case side of the naming problem — the two naming needs, one stop apart.

Frequently Asked Questions

Should a URL slug use hyphens or underscores?

Hyphens. Google's official documentation explicitly recommends hyphens as word separators in URLs; underscores have historically been treated as part of the word (url_slug could be read as the single token urlslug), so url-slug and url_slug may not pass anchor text the same way. Save underscores for filenames and programming identifiers.

How long should a URL slug be?

A practical sweet spot is 3–5 words and under 60 characters: enough to carry the keywords, short enough to avoid truncation in search results. The SEO value of the sixth word and beyond is close to zero — keep the most information-dense words from the front of the title and drop the rest.

Should non-English titles keep their original script in the slug?

It depends on the audience. Slugs in the original script (percent-encoded in the URL but displayed as real characters in modern browser address bars) are legitimate and common for sites targeting that language; for international or technical audiences, an ASCII-only slug is the safer choice. An "ASCII only" toggle covers both needs, and mixed-script input keeps the non-ASCII words while joining the English parts normally.

What happens to accents and special characters in a slug?

Accented letters fold to their base form: café → cafe, Việt → viet (the standard slug rule, preserving readability). Apostrophes are deleted outright (Facebook's → facebooks). Other symbols are stripped without transliteration ($34B → 34-b, never dollar34b).