URL slug 는 왜 SEO 에 중요할까?

같은 글에 두 URL — /blog/post?id=12345 vs /blog/how-qr-codes-are-made. 둘 다 작동한다. 그러나 검색 결과 클릭률, 공유 가능성, SEO 신호 모두 후자가 압도. 왜? 그리고 한글 제목 슬러그는 어떻게 다룰까 — 한글 그대로 vs Romanization vs Punycode? 이 가이드는 URL slug 의 SEO 의미, 한글 처리 전략, slug 변경 시 대처를 정리한다.

좋은 slug 의 5 가지 조건

읽기 쉬움 — 사람이 URL 만 보고 글 내용 추측 가능
짧음 — 공유·기억·복사 쉬움. 3-5 단어 권장
키워드 포함 — 검색 매칭에 기여 (작은 신호)
안정성 — 한 번 publish 하면 거의 변경 X. 변경 시 301 redirect
URL-safe 문자만 — 한글·공백·특수문자 회피 또는 encoding

실험 — Slug 생성기 가 임의 텍스트 → URL-safe slug 자동 변환. lowercase + hyphen + ASCII.

SEO 신호로서의 slug

Google 의 ?id=12345 와 how-qr-codes-are-made 차이:

검색 결과 표시 — URL 이 결과 페이지 하단에 노출. 키워드 포함 시 사용자 클릭률 (CTR) ↑
검색 신호 — title / description / body 보다 약하지만 신호. 같은 콘텐츠라도 의미 있는 slug 가 약간 ↑
backlink anchor text — 다른 사이트가 link 걸 때 raw URL 사용 시 slug 의 단어가 anchor 역할
SNS preview — Twitter / Slack 의 url preview 에 slug 표시. 매력적 URL = 클릭 ↑

Google 의 John Mueller 도 여러 번 — "키워드 stuffing 은 X 지만 descriptive slug 는 분명히 도움". 6-7 단어 안 핵심 키워드 + hyphen.

Hyphen (-) vs Underscore (_)

how-qr-codes-are-made    ← Google 이 단어 경계로 인식
how_qr_codes_are_made    ← Google 이 한 단어로 인식 (옛 동작)

Google 공식 권장 (2014 부터) — hyphen 사용. underscore 는 변수명 같은 "이름" 처리. SEO 손해.

또한 hyphen 이 더 읽기 쉽다 — 시각적 word 분리 명확.

한글 slug — 3 가지 전략

전략 1: 한글 그대로 (UTF-8)

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

브라우저 주소창 — 한글로 보임 (가독성 ↑)
실제 URL (wire) — /blog/qr-%EC%BD%94%EB%93%9C%EB%8A%94...

장점:
- 한국 사용자에게 읽기 쉬움
- 검색 신호로 한글 키워드 매칭

단점:
- 영어권 사용자에게 깨짐
- copy/paste 시 percent-encoded 형태로 (긴 글자 보임)
- 일부 옛 시스템 호환 X
- email / SMS 의 URL preview 깨짐 가능성

전략 2: Romanization (한글 → 영문)

/blog/qr-codeneun-eotteokge-mandeureojilkka

장점:
- 모든 환경에서 정상
- email / SNS preview 안전
- 영어권 사용자가 일부 추측 가능

단점:
- 한국 사용자 가독성 ↓
- 발음 transliteration 라이브러리 의존
- Revised vs McCune-Reischauer Romanization 선택 모호

전략 3: 영문 키워드 (의역)

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

장점:
- 모든 환경 안전
- 글로벌 SEO (영어 검색 결과 노출)
- 가장 깔끔

단점:
- 한국어 콘텐츠인데 영문 URL → 불일치 느낌
- 한국어 검색 키워드 매칭 약함 (title 로 보강)

실무 — 글로벌 사이트는 전략 3 (영문 의역). 한국어 전용 사이트는 전략 1 (한글 그대로) 또는전략 2 (Romanization).

이 사이트 (yutils) 는 전략 3 — 영어권 검색 진입을 핵심 동선으로. 한국어 제목은 화면에만, URL slug 는 영문.

Punycode — 도메인 안 한글

한글 도메인 (한글.kr) 은 URL 의 path 가 아닌 host 부분. percent-encoding 못 씀 (DNS 가 % 의미 모름). 대신 Punycode:

한글.kr → xn--bj0bj06e.kr   ← DNS 가 실제로 보는 형태
한국.kr → xn--3e0b707e.kr
한.kr   → xn--6q8b.kr

브라우저 주소창 — 한글로 표시 (xn-- 형태는 숨김)
DNS query — xn-- 로 변환됨

Punycode 알고리즘 (RFC 3492) 는 일정한 매핑 — 한글 → ASCII safe encoding. 같은 입력 = 같은 출력.

Punycode (국제화 도메인) 가 양방향 변환. IDN homograph attack 의심 시 사용 — 라틴 "a" vs 키릴 "а" 같은 시각 비슷한 문자가 다른 codepoint 면 Punycode 달라짐.

Slug 변경의 함정 — 301 redirect

slug 한 번 publish 하면 변경 X 가 원칙. 그러나 종종 변경 필요:

오타 수정 (/blog/how-jsoon-parsing-works)
의미 명확화 (/post/12345 → /post/best-tools)
상품 이름 변경

변경 시 — 옛 URL 에서 새 URL 로 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

효과:

옛 URL bookmark / backlink 가 계속 작동
Google 이 SEO 가치를 새 URL 로 transfer (90%+ 보존)
302 (Temporary) 는 SEO 가치 transfer X — 301 사용

Slug 생성 — 알고리즘

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

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

2. 특수문자 제거 또는 변환:
   "how qr codes are made part 1"

3. 한글 → ASCII (Romanization 또는 제거):
   "how qr codes are made part 1"

4. 공백 → hyphen:
   "how-qr-codes-are-made-part-1"

5. 연속 hyphen 정리:
   "how-qr-codes-are-made-part-1"

6. 앞뒤 hyphen 제거

한글 처리:

Option A — 그대로 (UTF-8 percent-encoding):
"QR 코드 만들기" → "qr-코드-만들기" → "qr-%EC%BD%94%EB%93%9C-..."

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

Option C — 제거 (영문 단어만 추출):
"QR 코드 만들기" → "qr"  ← 너무 짧음, 보통 X

Slug 생성기 의 default — 한글 그대로 유지하면서 공백·특수문자만 정리. lowercase + URL-safe.

흔한 함정

1. timestamp / id 만의 slug

/post/2024-05-22-1716345600    ← 의미 없음, SEO 가치 X
/post/abc123def                ← UUID. 검색 매칭 0

WordPress 의 default 가 /?p=123 — 즉시 permalink 설정 으로 의미 있는 slug 로.

2. 너무 긴 slug

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

→ keyword stuffing 으로 보임 → SEO 손해
→ 브라우저 주소창에서 잘림 → UX 손해

권장 60 자 안. 핵심 키워드 3-5 개만.

3. trailing slash

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

Google 입장 — 다른 URL. duplicate content 위험.
→ 한 가지로 표준화 + 301 redirect

4. uppercase

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

서버 동작 따라 다른 URL 가능. 항상 lowercase 권장.

5. URL 안 stopword

"a", "the", "is" 같은 단어는 SEO 가치 ↓. how-to-make-qr vs how-to-make-a-qr — 후자가 더 길고 신호 ↓. 단, 가독성도 고려 (지나친 단축 X).

6. 변경 후 301 누락

slug 변경 + redirect 없음 → 옛 URL = 404. backlink·bookmark·검색 결과의 사용자가 잃음. SEO 가치 0.

참고 자료

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

요약

좋은 slug = 읽기 쉬움 + 짧음 + 키워드 + 안정성 + URL-safe 문자.
Slug 가 SEO 약한 신호 + CTR (클릭률) + SNS preview 매력에 기여.
Hyphen (-) 가 단어 경계. Underscore (_) 는 한 단어로 인식 — SEO 손해.
한글 slug — 3 전략 (UTF-8 그대로 / Romanization / 영문 의역). 글로벌 사이트는 영문 의역 권장.
도메인 안 한글 = Punycode (Punycode (국제화 도메인)). path 안 한글 = percent-encoding.
Slug 변경 시 301 Permanent Redirect. SEO 가치 전이.
flat alias (timestamp/id) 만 X. 키워드 박힌 의미 있는 slug.
실험 — Slug 생성기 가 임의 텍스트 → URL-safe slug. lowercase + hyphen + special char 정리.