Skip to content
yutils

Why URL Slugs Matter for SEO

What makes a good URL slug — search-friendly characters, the Romanization vs Punycode question for Korean, hyphen vs underscore, slug stability, and the 301 redirect rules every site eventually needs.

~7 min read

Two URLs for the same article — /blog/post?id=12345 vs /blog/how-qr-codes-are-made. Both work. But click-through, shareability, and SEO signals all favor the latter. Why? And how should Korean (or any non-Latin) titles get slugified — raw UTF-8, Romanization, or English translation? This guide walks through what makes a good slug, the Korean slug strategies, and the 301 redirect rules every long-lived site eventually needs.

Five traits of a good slug

  • Readable — you can guess the content from the URL alone
  • Short — easy to share, remember, copy. 3-5 words is the sweet spot
  • Keyword-bearing — small SEO matching signal
  • Stable — once published, it shouldn't change. If it must, 301 redirect
  • URL-safe characters only — avoid spaces, special chars, raw non-ASCII (or encode)

Slug Generator turns any text into a URL-safe slug — lowercase, hyphenated, ASCII when possible.

The slug as an SEO signal

Google treats ?id=12345 very differently from how-qr-codes-are-made:

  • Result snippet — the URL shows up under the result. Keyword-bearing URLs raise click-through (CTR)
  • Ranking signal — weaker than title / description / body, but real. Descriptive slugs help slightly
  • Backlink anchor — when external sites link to your URL without custom text, the slug words become implied anchor text
  • Social previews — Twitter / Slack show the URL in their preview. A meaningful slug = more clicks

Google's John Mueller has repeated this: don't stuff keywords, but descriptive slugs help. Six or seven words with the actual topic, separated by hyphens.

Hyphen (-) vs underscore (_)

how-qr-codes-are-made    ← Google treats as word boundaries
how_qr_codes_are_made    ← Google treats as one token (legacy)

Google has recommended hyphens since 2014. Underscores are treated like variable names, not word separators — bad for SEO. Hyphens are also easier to read at a glance.

Non-Latin slugs — three strategies (Korean as example)

Strategy 1: keep the original characters (UTF-8)

/blog/qr-코드는-어떻게-만들어질까

Browser address bar — shows the Hangul (readable)
Actual URL on the wire — /blog/qr-%EC%BD%94%EB%93%9C%EB%8A%94...

Pros:
- Readable for the target audience
- Native-language keyword matching

Cons:
- Looks broken to non-Korean speakers
- Copy/paste shows the percent-encoded form (long)
- Some legacy systems break
- Some email / SMS previews mangle it

Strategy 2: Romanization

/blog/qr-codeneun-eotteokge-mandeureojilkka

Pros:
- Works everywhere
- Safe for email / social previews
- Some letters guessable by non-Korean readers

Cons:
- Less readable for Korean readers
- Requires a Romanization library (multiple Romanization schemes exist)

Strategy 3: English translation

/blog/how-qr-codes-are-made

Pros:
- Universally safe
- Global SEO (shows up for English searches)
- Cleanest looking URL

Cons:
- Korean content + English URL feels inconsistent
- Korean keyword matching weakens (compensate via title and body)

Real-world choice — global-facing sites use strategy 3. Korean-only sites use strategy 1 or 2.

This site (yutils) uses strategy 3. Korean titles appear on the page; the URL slug is English so it ranks in both languages.

Punycode — non-Latin in the domain part

Korean domains (한글.kr) live in the host, not the path. Percent-encoding doesn't apply — DNS doesn't understand %. Punycode does the translation:

한글.kr → xn--bj0bj06e.kr   ← what DNS actually sees
한국.kr → xn--3e0b707e.kr
한.kr   → xn--6q8b.kr

Browser address bar — shows Hangul (xn-- form hidden)
DNS lookup — uses the xn-- form

The Punycode algorithm (RFC 3492) is deterministic — same input, same output.

Punycode (IDN) converts both ways. Useful when you suspect an IDN homograph attack — Latin "a" vs Cyrillic "а" look identical but produce different Punycode.

The slug-change problem — 301 redirects

Slugs should be stable. But sometimes they have to change:

  • Typo fixes (/blog/how-jsoon-parsing-works)
  • Meaningful renames (/post/12345 → /post/best-tools)
  • Product / brand renames

When changing, redirect from the old URL to the new one with a 301 (Permanent Redirect):

GET /blog/old-slug HTTP/1.1
→ 301 Moved Permanently
  Location: /blog/new-slug

GET /blog/new-slug HTTP/1.1
→ 200 OK

What you get:

  • Old bookmarks and backlinks keep working
  • Google transfers most of the SEO value (~90%+)
  • 302 (Temporary) doesn't transfer SEO value — use 301

A slug-generation pipeline

Input: "How QR Codes Are Made? (Part 1)"

1. lowercase:
   "how qr codes are made? (part 1)"

2. strip or replace special characters:
   "how qr codes are made part 1"

3. non-Latin → ASCII (Romanize or drop):
   "how qr codes are made part 1"

4. spaces → hyphens:
   "how-qr-codes-are-made-part-1"

5. collapse repeated hyphens:
   "how-qr-codes-are-made-part-1"

6. trim leading/trailing hyphens

Non-Latin handling:

Option A — keep as UTF-8 (percent-encoded on the wire):
"QR 코드 만들기" → "qr-코드-만들기" → "qr-%EC%BD%94%EB%93%9C-..."

Option B — Romanize:
"QR 코드 만들기" → "qr-kodeu-mandeulgi"

Option C — strip (English words only):
"QR 코드 만들기" → "qr"  ← too short, usually not chosen

Slug Generator defaults to keeping the original characters and only cleaning up spaces and specials. Lowercase + URL-safe.

Common pitfalls

1. Timestamp / ID-only slugs

/post/2024-05-22-1716345600    ← meaningless, no SEO value
/post/abc123def                ← UUID. zero keyword matching

WordPress' default is /?p=123. Set Permalink Settings to a meaningful pattern from day one.

2. Slugs that are too long

/blog/how-to-create-a-beautiful-modern-responsive-web-application-with-nextjs-and-tailwind
                                                              ← 75 chars

→ Looks like keyword stuffing → SEO penalty
→ Truncated in the browser address bar → UX hit

Aim for under 60 characters. 3-5 keywords max.

3. Trailing slash

/blog/post-1     ← URL A
/blog/post-1/    ← URL B

To Google, these are different URLs. Duplicate-content risk.
Pick one and redirect the other.

4. Uppercase

/Blog/Post-1     ← URL A
/blog/post-1     ← URL B

Some servers treat these as different. Always lowercase.

5. Filler words ("stop words")

"a", "the", "is" carry little SEO value. how-to-make-qr vs how-to-make-a-qr — the latter is longer with less signal. Don't be cargo-cult about it though; readability still matters.

6. Renaming without a 301

Change a slug and skip the redirect → the old URL returns 404. You lose all the backlinks, bookmarks, and search-result clicks. SEO value evaporates.

References

  • Google — Keep a simple URL structure — Search Central
  • Google — Underscores vs hyphens (Matt Cutts video) — YouTube
  • RFC 3492 (Punycode) — datatracker
  • Cool URIs don't change (Tim Berners-Lee, 1998) — W3C

Summary

  • Good slug = readable + short + keyword + stable + URL-safe.
  • Slugs are a weak SEO signal but a real CTR / preview / backlink-anchor signal.
  • Hyphens are word boundaries to Google. Underscores aren't — hurts SEO.
  • Non-Latin slugs have three strategies (UTF-8 / Romanize / translate). Global-facing sites: translate.
  • Non-Latin in the domain = Punycode (Punycode (IDN)). In the path = percent-encoding.
  • Always 301 when changing a slug. SEO value transfers.
  • Avoid timestamp / id / UUID-only slugs. Pick keywords.
  • Try it: Slug Generator turns text → URL-safe slug — lowercase + hyphens + cleaned specials.

Related tools

← Back to guides