한글 슬러그 301 리디렉션으로 SEO 중복 콘텐츠 문제 해결
목차
초기에 구축한 서비스에서 한글 문자가 포함된 슬러그(URL 경로)를 레거시 형태로 그대로 두고 있었는데, 이게 결국 검색 엔진 입장에서 중복 콘텐츠로 인식되는 문제가 발생해서 301 리디렉션으로 정리하게 됐다. 단순한 URL 정리처럼 보이지만, SEO 관점에서 생각할 점들이 꽤 많이 있었다.
한글 슬러그가 낳는 문제
웹이 초기에 구축될 때는 URL 표준화가 지금만큼 엄격하지 않았다. 한글 문자를 그대로 URL에 넣는 경우도 많았고, 브라우저나 서버마다 인코딩하는 방식도 제각각이었다. 당시 우리 서비스도 한글 제목을 가진 콘텐츠의 슬러그를 자동으로 한글 그대로 생성하도록 구현했었다.
문제는 시간이 지나면서 드러난다:
- 한글 슬러그는 URL 표준(RFC 3986)에는 기술적으로 허용되지만, 검색 엔진이나 다양한 환경에서 일관되게 해석하지 않을 수 있다
- 사용자가 같은 콘텐츠를 여러 방식으로 접근할 수 있다 (한글 원본 vs 인코딩된 형태)
- SEO 크롤러 입장에서는 같은 콘텐츠가 서로 다른 URL로 존재하는 것으로 보여 중복 페이지 페널티(duplicate content penalty) 리스크가 생긴다
이커머스나 CMS 같은 서비스에서는 이런 문제가 특히 심하다. 같은 상품/페이지가 여러 URL로 색인되면 검색 순위가 분산되고, 최악의 경우 스팸으로 낙인찍힐 수도 있다.
301 리디렉션으로 정규화하기
이 문제를 해결하기 위해 301 Moved Permanently 리디렉션을 사용했다. 301은 단순한 "이 URL로 이동하세요"라는 신호가 아니라, 검색 엔진에게 "이 페이지의 모든 권력(PageRank)을 새 URL로 옮겨주세요"라고 말하는 것이다. 따라서 레거시 한글 슬러그로 들어오는 모든 트래픽을 정규 슬러그로 통합하면:
| 관점 | 효과 |
|---|---|
| 검색 엔진 | 중복 페이지가 아닌 하나의 정규 URL로 인식. 링크 권력 통합 |
| 사용자 | 레거시 링크도 자동 리디렉션되어 접근성 유지 |
| 성능 | 로그인이나 세션 유지 같은 상태도 리디렉션 과정에서 보존 가능 |
구현 전략: cms_legacy_slug 필드
직접 구현하려면:
// DB 스키마에 legacy 슬러그 추적 필드 추가
// cms_legacy_slug: 레거시 한글 슬러그를 저장해두고
// canonical_slug: 현재의 정규 슬러그로 유지
// DB 레이어에서는 두 형태 모두 검색 가능하도록
// 예: findBySlug() 쿼리는 legacy 도 normal 도 매칭
라우팅 로직([slug].astro)에서는:
- 요청받은 슬러그가 legacy 형태인지 확인
- 만약 legacy라면 → 정규 슬러그로 301 리디렉션
- 정규 슬러그라면 → 정상적으로 페이지 렌더링
이 방식의 장점은 마이그레이션이 점진적이라는 것. 기존 한글 URL들을 한 번에 다 바꿀 필요 없이, 데이터베이스에 매핑만 해두고 라우터가 처리하도록 떠넘길 수 있다.
왜 이 우선순위였나
사실 이런 수정은 기능 추가처럼 눈에 띄지 않는다. 사용자가 "UI가 쌈박하다" 하거나 "반응이 더 빠르다"고 느끼지도 않는다. 하지만 검색 엔진 순위는 경쟁력의 핵심이고, 특히 장기적으로 서비스의 발견성을 좌우한다.
팀 내에서도 처음엔 "지금 급해?"라는 반응이 있을 수 있다. 하지만:
1. 신규 콘텐츠가 계속 쌓일수록 나중에 수정하기 어려워진다 — 지금 2000개 페이지라도 1년 후엔 10000개일 수 있다
2. 이미 검색 엔진에 색인된 레거시 URL이 있다면 기회 비용이 크다 — 미루면 미룰수록 잃는 SEO 자산이 늘어난다
3. 코드 복잡도는 작다 — DB 필드 하나, 라우터 로직 몇 줄이면 충분하다
그래서 우선순위를 높게 잡고 진행했던 것 같다.
배운 점과 함정
레거시 데이터를 다룰 때는 항상 이중 검증이 중요하다. 특히:
- 기존 canonical 슬러그가 정말 정규화되어 있는지 (혹은 여러 형태가 섞여 있진 않은지)
- 301 리디렉션이 정말 작동하는지 (캐싱 레이어 때문에 302로 응답하는 경우도 있음)
- 체인 리디렉션(A→B→C)이 없는지 (검색 엔진은 이를 비효율로 본다)
또한 향후 슬러그 생성 로직이 바뀔 때 이 매핑을 함께 갱신해야 한다는 걸 팀과 공유하는 것도 중요했다. 그렇지 않으면 새로운 형태의 레거시가 반복해서 쌓일 수 있으니까.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.