Slug Generator

What it does

The Slug Generator turns any string into a clean, URL-safe slug. It normalises Unicode (so accented characters get their plain ASCII equivalents), strips characters that should not appear in a URL, normalises whitespace to a single separator (hyphen by default, underscore as an alternative), optionally lowercases everything, and truncates at a configurable maximum length without leaving a trailing partial word.

Common situations

You are publishing an article with a title that contains punctuation, accents, or special characters — “Café résumé: 10 tips you’ll find useful” — and you need a URL slug that strips all of that to something search-engine-friendly. Drop the title in, the generator returns cafe-resume-10-tips-you-find-useful.

A CMS auto-generates slugs from titles but its rules are awkward — keeps stop words, doesn’t strip apostrophes, leaves punctuation intact. Generate the slug here against the same title input, copy the cleaner version into the CMS’s slug field manually for important pages.

You are bulk-importing content from a legacy system that stored articles by ID and you need to generate URL slugs from the titles for a new URL structure. The generator handles the conversion one-by-one or as part of a templating workflow.

You have inherited a site where slugs are inconsistent — some have stop words, some don’t; some are camelCase, some hyphenated; some end with trailing dashes from sloppy generation. Standardise on the generator’s output for any new content; for the existing inconsistency, plan a one-time normalisation pass with redirects from old to new.

A multilingual site needs slugs in English even though the source titles are in French or German. Diacritics-stripping handles this — the German title “Über uns” becomes uber-uns, French “À propos” becomes a-propos. The slug stays English-friendly even when the underlying language is not.

What you need to know

A URL slug is the human-readable portion of a URL that identifies the page within its parent path. In https://example.com/blog/how-to-pick-a-cms/, the slug is how-to-pick-a-cms. Slugs are not random identifiers — they carry meaning that affects both user trust and search ranking.

The rules of a good slug are mostly conventions rather than technical requirements. Use lowercase because URLs are case-sensitive on Linux servers and case-insensitive on Windows servers; lowercasing avoids serving the same content at multiple casings of the same URL. Use hyphens to separate words; underscores work but are conventionally treated as word-internal by search engines (Google reads how_to_pick as one token, how-to-pick as three). Avoid spaces and special characters — they encode to %20 and other percent-escapes that are ugly and unfriendly.

Diacritic handling is the trickiest part. The generator uses Unicode normalization (NFD or NFKD) to decompose accented characters into their base letter plus combining mark, then strips the marks. This produces predictable transliterations: é → e, ñ → n, ü → u. Some Eastern European languages (Polish, Czech) need additional rules — the generator handles the major Latin-based scripts cleanly but a Polish ł becomes nothing rather than l. For non-Latin scripts (Cyrillic, Arabic, CJK), transliteration is a deeper problem and the generator does not attempt it; for non-Latin source content, generate slugs in the target language, not via transliteration.

Stop word stripping removes the high-frequency English words (a, an, the, is, are, of, in, on, at, etc.) that add length without meaning. Stripping is optional and generally helpful — the-best-of-times is more useful as best-times — but be careful: stripping too aggressively can produce ambiguous slugs (“The Lord of the Rings” → “lord-rings” is fine; “Where Are They Now?” → “now” is unhelpful).

Length matters mostly for cosmetics. Slugs over ~60 characters look unpolished in the SERP, get truncated when shared, and indicate the title was probably too long anyway. The generator’s default 60-character cap is a reasonable balance; tune up to 80 for genuinely complex topics, down to 40 for simple ones.

Frequently asked questions

Why hyphens instead of underscores?

Search engines treat hyphens as word separators and underscores as part of a word. how-to-cook parses as three tokens — “how”, “to”, “cook”. how_to_cook parses as one token. For SEO, hyphens are unambiguously the right choice.

Should I include stop words in slugs?

Generally no. Stop words add length without affecting how search engines understand the URL. Strip them by default and only keep them when their absence makes the slug ambiguous or hard to read.

How long should a slug be?

Under 60 characters as a soft limit. Long slugs aren’t a ranking penalty but they look sloppy in SERPs, get truncated when shared, and usually signal that the title is too long. Aim for 30–60 characters.

Should slugs include keywords?

Yes — the slug is a small but real ranking signal, and the keywords in it influence which queries the page can match for. Don’t stuff keywords artificially, but a slug that contains the page’s primary topic is doing useful work.

Do I need to lowercase slugs?

Yes — URL casing is server-dependent (Linux is case-sensitive, Windows isn’t), and serving the same content at multiple casings creates duplicate-content concerns. Lowercase everything; redirect uppercase variants to the lowercase canonical.

What about non-English content?

For content in non-Latin scripts (Cyrillic, Arabic, CJK, etc.), most modern browsers and search engines now handle native-script URLs (IDN — Internationalized Domain Names — and percent-escaped path segments). For Latin-script languages with diacritics (French, German, Spanish), strip the diacritics — the slug works for both native and English-speaking visitors.

Can I change a slug after publishing?

Yes, but you need to set up a 301 redirect from the old slug to the new one. Don’t change slugs casually — every change costs a tiny amount of accumulated SEO equity until the redirect is in place and Google has reprocessed the URL. Reserve slug changes for genuinely necessary cases.

What characters are technically allowed in URLs?

URLs allow letters, digits, hyphen, underscore, period, and tilde without escaping (RFC 3986 “unreserved characters”). Other characters need percent-encoding. In practice, slugs should use only letters, digits, and hyphens — anything else is a stylistic mistake.

Common problems

Problem: Slug contains weird leftover characters after diacritic stripping.

The generator handles standard Latin-1 diacritics (é, ñ, ü, etc.) but some characters don’t decompose cleanly via NFKD. Polish ł and Turkish ı are common offenders. For those scripts, hand-edit the output.

Problem: Stripping stop words produces nonsensical slugs.

Stop word stripping is aggressive — it doesn’t understand context. “Lord of the Rings” → “lord-rings” works; “Are You There” → “you-there” is borderline. If aggressive stripping produces ambiguity, turn it off for that title and accept the longer slug.

Problem: Same title produces different slugs in different tools.

Slug-generation rules are conventions, not standards. Different tools handle stop words, character stripping, and locale-specific cases differently. The right answer is to standardise on one tool (or one rule set) for an entire site.

Problem: CMS keeps overriding the manually-set slug back to its auto-generated version.

WordPress in particular regenerates slugs on save under certain configurations. The fix is usually a setting in the CMS or a permalink-related plugin. For long-term stability, use a slug-management plugin that locks the slug after publish.

Problem: Truncated slugs cut off mid-word.

The generator’s truncation respects word boundaries — it backs up to the last separator within the length limit. If a slug is truncating mid-word, the source string contains characters that aren’t being recognised as separators. Manually trim to the next hyphen boundary if needed.

Tips

• Set the slug at publish time and don’t touch it again. Slugs are part of the page’s permanent identity; changing them after the page has accumulated traffic is more expensive than picking a slightly imperfect slug initially.
• For content where the title is long but the topic is narrow, manually edit the slug to a shorter, sharper version that captures the topic. The generator is a starting point, not the final answer for important pages.
• When migrating, generate slugs from titles in bulk, then spot-check the most-trafficked pages — the generator handles the bulk case correctly but edge cases in those highest-value pages deserve manual attention.
• Avoid slugs that are dates or IDs. 2024-01-15-post and post-12345 carry no signal to search engines and look amateurish in SERPs.
• Hyphens between every word, no double hyphens, no leading or trailing hyphens. The generator enforces this; hand-written slugs sometimes don’t.

Related tools in this suite

There is no direct sibling for the Slug Generator in the SEO suite — it is a small, focused utility. The closest pairing is the Meta Tag Generator which handles the title that the slug is usually derived from. The Page SEO Audit reports the URL of an audited page, which is where you would notice an inconsistent or oversized slug in the first place.

What this looks like at scale

A CMS with sensible defaults handles slugs automatically — title goes in, slug comes out, no human attention needed for most pages. The exceptions are: pages where the auto-generated slug is too long, where the title doesn’t translate well, or where the page is high-value enough to warrant manual attention. For sites with thousands of pages, the rule of thumb is to trust the auto-generation for everything below the top 5% of traffic, and hand-tune the rest.

Take it further

If a content set you have inherited has inconsistent slugs (mixed conventions, leftover IDs, oversized URLs), the cleanup is often part of a wider migration or content audit. Start a conversation about what that scope looks like.