URL Slug Generator

A slug is the human-readable portion of a URL that identifies a specific page or resource. In example.com/blog/what-is-url-encoding, the slug is what-is-url-encoding. Slugs exist because raw identifiers like article IDs (article.php?id=42) are meaningless to humans — they don't tell you what the page is about, they don't share well in conversation, and they don't survive a site migration when IDs change. A good slug is both machine-stable and human-informative.

The dual audience for slugs — humans and search engines — is what makes them worth caring about. A descriptive slug helps users predict what a page contains before clicking, and it gives search engines a strong relevance signal because the words in the URL appear in the page's actual content. This is why auto-generated slugs from titles (rather than random IDs) are a standard SEO recommendation.

The core SEO principle for slugs is that they should match the page's primary keyword phrase as closely as possible. If your article is about 'how to configure Nginx reverse proxy,' the slug should be how-to-configure-nginx-reverse-proxy — not a truncated version, not a generic one like article-123. The words in the slug should be the same words a user would type into a search engine to find this content.

Length matters because search engines truncate long URLs in results, and because long slugs dilute the signal from the most important keywords. Aim for 50-60 characters or fewer, putting the most important words at the beginning. Remove stop words (a, an, the, and, or, but) that add length without adding signal. Use lowercase exclusively — URLs are case-sensitive on most servers, and mixed-case slugs create duplicate content issues when users or links accidentally capitalize differently.

Slugs must be safe for every URL parser, web server, and file system they'll encounter. The safest approach is to allow only lowercase ASCII letters, digits, and hyphens. Everything else — spaces, underscores, punctuation, accented characters, symbols — should be either removed or transliterated. Spaces and underscores become hyphens (or are removed). Punctuation is stripped. Accented Latin characters are folded to their ASCII equivalents: é → e, ñ → n, ü → u, ø → o.

This transliteration step is what makes slugs portable. A slug containing raw Unicode might work in the browser's address bar but break in an RSS feed, an API response, or a file system that doesn't handle UTF-8 consistently. By constraining slugs to plain ASCII, you guarantee they'll work everywhere a URL can appear. The trade-off is that the slug becomes a lossy representation of the original title — 'café' becomes 'cafe', 'naïve' becomes 'naive' — which is why the page title and meta tags should carry the properly accented text while the slug stays plain.

For non-Latin scripts, the question of whether to use Unicode slugs or transliterated ones has no single answer. Unicode slugs (example.com/ページ/ニュース) work in modern browsers and are more readable for users of those scripts, but they require careful URL-encoding when transmitted and may be mangled by systems that don't handle UTF-8 well. Some CMS platforms support Unicode slugs; others force transliteration to a Latin approximation.

A practical middle ground is to generate a transliterated slug for non-Latin text — ページ becomes pe-ji (Japanese romanization), Новости becomes novosti (Cyrillic transliteration). This keeps the slug ASCII-safe while preserving some phonetic resemblance to the original. The transliteration quality depends heavily on the language: Romance languages fold cleanly to ASCII, while logographic scripts like Chinese require a romanization scheme (pinyin) that adds complexity. For any site with a significant multilingual audience, testing slug generation across the actual scripts you expect is essential.

Most CMS platforms generate slugs automatically from the title field, but the quality varies widely. WordPress lowercases, strips punctuation, and replaces spaces with hyphens — a solid default. Drupal and Jekyll follow similar conventions. The key thing to verify with any CMS is how it handles duplicates: two posts titled 'Hello World' should get slugs hello-world and hello-world-2 (or hello-world-1), not an overwrite or a database error.

Beyond generation, the most important slug rule is stability. Once a page is published and indexed, changing its slug breaks every inbound link and search ranking the page has accumulated. If a slug must change, set up a 301 redirect from the old slug to the new one. Some platforms support this automatically; for others it's a manual step. Treat slugs as permanent infrastructure, not as editable metadata — get them right at publication time.