글로벌 브랜드 사이트를 운영하다 보면 반드시 겪는 상황이 있습니다. 한국 사용자가 한글 브랜드 키워드로 검색했는데 영문 페이지가 뜬다는 제보입니다. 딱히 고장난 건 없습니다. 두 페이지 모두 존재하고, 색인도 되어 있고, 페널티를 받을 만한 중복도 아닙니다. 검색엔진이 두 페이지가 서로의 언어 버전이라는 사실을 모를 뿐입니다.
hreflang은 정확히 이 문제를 위한 장치이고, 동시에 사소한 문법 실수 하나로 전체 선언이 조용히 무효화되는 몇 안 되는 기능이기도 합니다.
hreflang이 하는 일과 하지 않는 일
hreflang은 검색엔진에 이렇게 말합니다. "이 URL들은 언어·지역만 다른 같은 콘텐츠다. 사용자에게 맞는 걸 보여줘라."
반대로 다음은 하지 않습니다.
- 순위를 올리지 않습니다. 어떤 URL을 보여줄지를 바꿀 뿐입니다.
- 중복 콘텐츠 문제를 단독으로 해결하지 않습니다. 그건
canonical의 역할입니다. - 리다이렉트하지 않습니다. 브라우저가 아니라 검색엔진에 주는 힌트입니다.
현실적인 이득은 하나입니다. 노출되는 페이지가 사용자의 언어로 바뀝니다. 한글·영문 페이지가 같은 브랜드 쿼리에서 경쟁하는 브랜드 사이트라면, 이것만으로도 국내 CTR이 눈에 띄게 움직입니다.
구현 방식 세 가지
선언 위치는 세 곳입니다. 하나만 골라 일관되게 쓰세요. 섞는 순간 불일치가 생깁니다.
1. HTML <head> 링크 — 가장 흔하고 검증하기 쉬운 방식입니다.
<link rel="alternate" hreflang="en" href="https://example.com/en/products/x" />
<link rel="alternate" hreflang="ko" href="https://example.com/ko/products/x" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/products/x" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/products/x" />
2. XML 사이트맵 어노테이션 — 대규모 사이트에 적합합니다. 모든 템플릿이 아니라 생성기 한 곳만 수정하면 됩니다. 사이트맵 가이드 참고.
3. HTTP Link 헤더 — PDF 등 HTML이 아닌 문서에 필요합니다.
대부분이 실패하는 지점: 상호 참조 규칙
한 언어 그룹의 모든 페이지는 자기 자신을 포함해 그룹의 모든 구성원을 나열해야 합니다.
/ko/pricing이 /en/pricing을 선언했는데 /en/pricing이 /ko/pricing을 되돌려 선언하지 않으면, 그 선언은 단방향이며 폐기됩니다. 일부만 인정되는 게 아니라 통째로 버려집니다.
자기 참조도 마찬가지로 필수입니다. 3개 언어라면 각 페이지에 3개씩, 총 9개의 <link>가 나와야 합니다. 자기 참조를 빼고 2개씩만 넣은 채로 한 분기를 보내며 "왜 안 바뀌지?"를 반복하는 경우가 정말 많습니다.
언어·지역 코드 정확히 쓰기
값은 언어 또는 언어-지역 형식이며, 언어는 ISO 639-1, 지역은 ISO 3166-1 Alpha-2를 씁니다.
| 의도 | 올바른 값 | 흔한 실수 |
|---|---|---|
| 한국어(지역 무관) | ko |
kr (국가 코드이지 언어 코드가 아님) |
| 한국 내 한국어 | ko-KR |
ko_KR(언더스코어), KO-kr |
| 영어(지역 무관) | en |
en-EN (존재하지 않는 지역) |
| 싱가포르 영어 | en-SG |
en-SEA |
| 일본어 | ja |
jp |
| 중국어 간체 | zh-Hans |
zh-CN도 허용되지만 스크립트 코드가 안전 |
국내 사이트에서 가장 잦은 오류가 ko 대신 kr입니다. kr은 유효한 언어 코드가 아니며, 해당 URL의 선언 전체가 폐기됩니다.
지역 코드는 범위를 좁히는 값입니다. en-US는 '미국에 있는 영어 사용자'만 가리킵니다. 전 세계 영어 사용자를 원하면 en을 써야 합니다. en-US, en-GB, en-AU만 선언하면 한국에 거주하는 영어 사용자는 매칭되는 버전이 없습니다. 바로 이때 x-default가 필요합니다.
x-default
x-default는 어떤 언어·지역과도 매칭되지 않을 때 보여줄 페이지를 지정합니다. 다음 용도로 사용합니다.
- 기본값 역할을 하는 글로벌 영문 페이지
- 언어 선택 랜딩 페이지
- 명시적으로 타깃하지 않은 모든 시장
그룹당 하나만 둡니다. 없어도 치명적이진 않지만, 매칭되지 않는 사용자는 검색엔진의 추측에 맡겨집니다.
canonical과 hreflang의 관계
코드 오타보다 더 큰 피해를 만드는 조합입니다. 규칙은 단순합니다.
- 각 언어 버전은 자기 자신을 canonical로 지정합니다. 절대 다른 언어를 가리키지 않습니다.
hreflang에 적는 URL은 canonical URL이어야 합니다.
한국어 페이지가 canonical을 영문 URL로 걸어두면, 검색엔진에 "영문이 진짜이고 나는 버려도 된다"고 말하는 셈입니다. 그런데 hreflang은 한국어 페이지를 가리키고 있으니 두 신호가 충돌합니다. 이때는 보통 canonical이 이기고 한국어 페이지가 색인에서 사라집니다. 고치는 데는 5분이지만, 아무도 점검하지 않으면 수개월의 트래픽을 잃습니다.
기존 구현 점검 방법
발견 빈도가 높은 순서입니다.
- 상호 참조 — 그룹의 모든 페이지를 크롤링해 선언을 모으고, 그래프가 대칭인지 확인합니다.
- 자기 참조 — 각 페이지가 자기 URL을 포함하는지 봅니다.
- 코드 유효성 —
kr,en-EN, 언더스코어, 임의 지역 코드가 없는지 확인합니다. - 상태 코드 — 선언된 모든 URL이 200을 반환해야 합니다. 리다이렉트나 404를 가리키는 선언은 무의미합니다.
- canonical 정합성 — 선언된 URL이 모두 자기 참조 canonical인지 봅니다.
- 절대 URL — 상대 경로는 유효하지 않습니다.
크롤 기반 점검이면 이 모든 걸 한 번에 처리합니다. DeepAnalyzer는 크롤한 모든 페이지의 canonical과 hreflang을 함께 수집하므로, 대칭 검사가 수작업 샘플링이 아니라 내보낸 인벤토리의 diff 작업이 됩니다.
hreflang보다 먼저 결정할 것: 사이트 구조
hreflang은 이미 존재하는 구조를 설명할 뿐입니다. 구조를 먼저 정해야 합니다.
| 구조 | 예시 | 트레이드오프 |
|---|---|---|
| ccTLD | example.kr |
지역 신호 최강, 비용 최대, 도메인별 권위 분산 |
| 서브도메인 | ko.example.com |
인프라 분리 용이, 권위 통합은 약함 |
| 서브디렉터리 | example.com/ko/ |
하나의 도메인에 권위 집중 — 대체로 기본값 |
| 파라미터 | example.com?lang=ko |
권장하지 않음. 불안정하고 canonical 처리가 어려움 |
대부분의 브랜드 사이트에서는 서브디렉터리가 유리합니다. 도메인 하나에 권위가 쌓이고, 인증서도 하나, 애널리틱스 속성도 하나이며, 언어가 IA에서 이미 다루는 경로 세그먼트가 됩니다. 로케일 세그먼트를 경로 어디에 둘지는 URL 구조 설계에서 다룹니다.
자주 묻는 질문
한국어 단일 사이트인데 hreflang이 필요한가요?
필요 없습니다. hreflang은 언어 버전 간의 관계를 설명하는 장치입니다. 버전이 하나면 설명할 관계가 없습니다. <html lang="ko">만 정확히 설정하면 됩니다.
hreflang이 순위를 올려주나요?
직접적으로는 아닙니다. 특정 사용자에게 어떤 버전을 보여줄지를 바꿉니다. 언어가 맞아 CTR이 오르고 이탈이 줄면 간접적인 성과 개선은 있지만, 선언 자체에 대한 순위 가산점은 없습니다.
한국어와 영어 페이지가 완전한 번역이 아니어도 되나요?
괜찮습니다. hreflang은 문자 그대로의 번역이 아니라 동등한 목적의 페이지를 전제합니다. 원화 표기와 국내 결제수단이 반영된 한국어 가격 페이지도 가격 페이지의 한국어 버전입니다.
서로 다른 도메인 간에도 쓸 수 있나요?
가능합니다. 도메인이 달라도 동작하기 때문에 example.kr / example.com 분리 운영이 성립합니다. 단, 양쪽 모두 상호 선언해야 하고 Search Console에서 두 도메인의 소유권이 확인되어야 합니다.
head 태그와 사이트맵 중 무엇으로 구현할까요?
수천 페이지 미만이면 head 태그가 낫습니다. 브라우저에서 바로 확인할 수 있기 때문입니다. 대규모 카탈로그라면 사이트맵이 낫습니다. 템플릿 전체가 아니라 생성기 한 곳만 관리하면 됩니다. 둘을 함께 쓰지는 마세요. 진실의 원천이 둘이면 반드시 어긋납니다.