hreflang 설정 가이드: 다국어 SEO 중복을 막는 법
다국어 사이트의 hreflang 태그를 올바르게 구성하고 x-default·상호참조 실수를 피하는 법.
한국어·영어 두 버전을 운영하는 사이트에서 가장 흔한 SEO 사고는 두 가지다. 하나는 엉뚱한 언어 페이지가 검색에 뜨는 것 — 한국 사용자가 검색했는데 영어 페이지가 노출되어 이탈률만 올라간다. 다른 하나는 중복 콘텐츠로 인한 평가 분산 — 구글이 /ko/pricing과 /en/pricing을 “거의 같은 페이지 두 개”로 보고 링크 평가를 나눠 갖거나 한쪽을 색인에서 빼버린다. hreflang은 이 두 문제를 동시에 푸는 신호다. “이 페이지들은 같은 콘텐츠의 언어별 버전이니, 사용자 언어에 맞는 쪽을 보여줘라”고 검색엔진에 알려준다.
문제는 hreflang이 실무에서 가장 많이 틀리는 SEO 태그라는 점이다. 상호참조(return tag) 한쪽만 빠져도, 언어 코드를 kr로 쓰기만 해도, canonical이 어긋나기만 해도 구글은 해당 hreflang 쌍을 조용히 무시한다 — 에러 메시지도 없이. 이 가이드는 세 가지 구현 방식 중 하나를 고르는 기준부터, 코드 규칙, x-default, 상호참조 규칙, canonical 함정까지 정리하고, 마지막에 정상 예시와 “구글이 무시하는 깨진 예시”를 나란히 비교한다. 태그 블록은 hreflang 태그 생성기로 만들고, 배포 후에는 SEO 메타태그 검사기로 실제 렌더링된 태그를 확인하면 된다.
구현 방식 3가지 — 하나만 골라라
hreflang을 검색엔진에 전달하는 통로는 세 가지다. 셋 다 효력은 같지만, 반드시 하나만 사용해야 한다. 두 방식을 섞으면 서로 충돌하는 신호가 생겼을 때 디버깅이 거의 불가능해진다.
- ① HTML
<head>의 link 태그 — 가장 일반적. 각 페이지의<head>에<link rel="alternate" hreflang="ko" href="..." />를 나열한다. 페이지 단위로 관리할 수 있어 CMS·Next.js 같은 프레임워크에서 다루기 쉽다. 단점은 언어가 10개면 모든 페이지 head에 태그가 10줄 이상 붙어 HTML이 커진다는 것. - ② HTTP 응답 헤더 — PDF·이미지처럼 HTML이 아닌 파일에 쓴다.
Link: <https://example.com/en/file.pdf>; rel="alternate"; hreflang="en"형식. 일반 웹페이지에는 굳이 쓸 이유가 없다. - ③ XML 사이트맵 — 각
<url>항목 안에<xhtml:link rel="alternate" hreflang="...">를 나열한다. 페이지 HTML을 건드리지 않고 한 파일에서 전체를 관리할 수 있어 언어·페이지 수가 많은 대형 사이트에 유리하다. 대신 사이트맵 파일이 크게 불어나고, 상호참조를 수동으로 맞추면 실수하기 쉬우므로 반드시 자동 생성해야 한다. 배포 후에는 사이트맵 검사기로 XML 구조와 URL 응답을 검증하자.
그리고 방식과 무관하게 href 값은 반드시 절대 URL이어야 한다. href="/en/pricing" 같은 상대 경로는 무효다. 프로토콜(https)과 도메인까지 전부 포함한 https://example.com/en/pricing 형태로 쓴다.
코드 규칙: 언어-국가, 그리고 kr·en-UK 함정
hreflang 값은 ISO 639-1 언어 코드(소문자 2자) 단독, 또는 언어-국가(ISO 3166-1 Alpha-2) 조합이다. 여기서 사고가 가장 많이 난다 — 국가 코드와 언어 코드는 별개 체계라서, 직관대로 쓰면 틀린다.
| 의도 | 올바른 값 | 흔한 오답 | 왜 틀렸나 |
|---|---|---|---|
| 한국어 (지역 무관) | ko | kr | kr는 국가 코드다. 언어 코드는 ko. ko-KR은 유효하지만 “한국의 한국어”로 범위가 좁아진다. |
| 영어 (지역 무관) | en | en-US만 등록 | en-US는 미국 사용자용이라는 뜻. 영국·호주 등 나머지 영어권은 매칭에서 빠진다. |
| 영국 영어 | en-GB | en-UK | ISO 3166에서 영국은 GB다. UK는 표준 코드가 아니라 무시된다. |
| 일본어 | ja | jp | jp는 국가 코드. 언어는 ja. |
| 국가만 지정 | 불가능 | KR, US | 국가 단독 지정은 없다. 반드시 언어 또는 언어-국가 형식이어야 한다. |
규칙은 간단하다: 언어는 필수, 국가는 선택. 통화·배송·법규 때문에 같은 언어라도 국가별 페이지가 다를 때만 en-GB/en-US처럼 국가를 붙이고, 그렇지 않으면 ko·en처럼 언어만 쓰는 편이 매칭 범위가 넓어 유리하다.
x-default와 상호참조(return tag) — 무시당하지 않는 조건
x-default는 “어느 언어 규칙에도 매칭되지 않는 사용자에게 보여줄 기본 페이지”다. 보통 언어 선택 페이지나 글로벌 기본 버전(영어인 경우가 많다)을 지정한다. 필수는 아니지만 넣는 것이 안전하다 — 스페인어 사용자가 ko/en만 있는 사이트를 검색했을 때 어느 쪽을 보여줄지 구글이 추측하게 두지 않는 것이다. x-default가 기존 언어 버전(예: 영어 페이지)과 같은 URL을 가리켜도 전혀 문제없다.
그리고 hreflang의 가장 중요한 단일 규칙이 상호참조다:
- 모든 언어 버전 페이지는 자기 자신을 포함한 전체 alternate 집합을 나열해야 한다.
- A 페이지가 B를 가리키면, B도 반드시 A를 가리켜야 한다(return tag).
- 한쪽이라도 빠지면 그 쌍은 통째로 무효다. 구글은 “B가 A를 인정하지 않으니 A의 주장을 믿을 수 없다”고 판단하고 두 태그를 모두 무시한다. 제3자가 남의 사이트를 자기 alternate라고 주장하는 것을 막기 위한 설계다.
즉 언어가 N개면 모든 페이지가 동일한 N+1줄(x-default 포함) 블록을 갖는 구조가 정답이다. 페이지마다 블록이 다르면 어딘가 상호참조가 깨져 있다는 뜻이다. Search Console의 “국제 타겟팅” 리포트나 SEO 메타태그 검사기로 각 URL의 실제 태그를 뽑아 비교하면 빠르게 찾을 수 있다.
canonical 함정: 언어별로 자기 자신을 가리켜야 한다
hreflang이 완벽해도 canonical이 어긋나면 전부 물거품이 된다. 흔한 실수는 “중복을 없애야 하니까” 영어 페이지의 canonical을 한국어 원본으로 걸어버리는 것이다:
<!-- /en/pricing 페이지 — 잘못된 설정 --> <link rel="canonical" href="https://example.com/ko/pricing" /> <link rel="alternate" hreflang="en" href="https://example.com/en/pricing" />
이러면 구글에게 “/en/pricing은 색인하지 말고 /ko/pricing을 대표로 삼아라”와 “/en/pricing을 영어 사용자에게 보여줘라”는 모순된 신호가 동시에 들어간다. 구글은 보통 canonical을 우선해 영어 페이지를 색인에서 제외하고, hreflang 클러스터는 무너진다. 원칙은 하나다: 각 언어 버전의 canonical은 자기 자신(self-referencing). 언어 버전은 중복이 아니라 각각 색인되어야 할 독립 페이지이고, 중복 판정을 막는 역할은 canonical이 아니라 hreflang이 맡는다.
실전 예시: ko/en 2페이지 — 정상 블록 vs 구글이 무시하는 블록
https://example.com/ko/pricing(한국어)과 https://example.com/en/pricing(영어) 두 버전이 있고, 영어를 글로벌 기본으로 삼는다고 하자. 두 페이지 모두 head에 정확히 이 블록이 들어가야 한다(canonical만 페이지별로 다르다):
<!-- /ko/pricing 의 <head> --> <link rel="canonical" href="https://example.com/ko/pricing" /> <link rel="alternate" hreflang="ko" href="https://example.com/ko/pricing" /> <link rel="alternate" hreflang="en" href="https://example.com/en/pricing" /> <link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing" /> <!-- /en/pricing 의 <head> --> <link rel="canonical" href="https://example.com/en/pricing" /> <link rel="alternate" hreflang="ko" href="https://example.com/ko/pricing" /> <link rel="alternate" hreflang="en" href="https://example.com/en/pricing" /> <link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing" />
alternate 3줄이 두 페이지에서 완전히 동일하다는 점에 주목하자. 이제 실무에서 자주 보이는 깨진 변형이다:
<!-- /ko/pricing — 영어 버전만 가리킴 (자기 자신 누락) --> <link rel="alternate" hreflang="en" href="https://example.com/en/pricing" /> <!-- /en/pricing — 아무 hreflang 도 없음 -->
이 설정이 무효가 되는 이유는 두 겹이다. 첫째, ko 페이지가 자기 자신(ko)을 나열하지 않았다 — 자기 참조 태그는 필수다. 둘째, en 페이지에 return tag가 없다. ko→en 방향 주장만 있고 en→ko 확인이 없으므로 구글은 이 쌍을 검증할 수 없고, 결과적으로 태그가 아예 없는 것과 동일하게 취급한다. 겉보기에는 “절반은 설정했으니 절반은 효과가 있겠지” 싶지만, hreflang은 쌍 단위로 전부 아니면 전무다. 이런 블록을 손으로 짜다 보면 페이지 수 × 언어 수만큼 실수 지점이 생기므로, hreflang 태그 생성기에 URL 패턴과 언어 목록을 넣어 전체 세트를 한 번에 뽑는 것을 권한다. 사이트맵 방식을 택했다면 생성 후 사이트맵 검사기까지 돌려서 URL이 전부 200을 반환하는지 확인하자 — 리다이렉트되거나 404인 URL을 alternate로 등록하는 것도 클러스터를 깨뜨리는 단골 원인이다.
자주 묻는 질문
hreflang을 넣으면 순위가 올라가나요?
언어가 2개뿐인데도 x-default가 필요한가요?
hreflang을 head 태그와 사이트맵에 둘 다 넣으면 더 확실하지 않나요?
ko-KR과 ko 중 무엇을 써야 하나요?
번역이 안 된 페이지도 hreflang으로 묶어야 하나요?
설정이 제대로 됐는지 어떻게 확인하나요?
이 가이드와 함께 쓰면 좋은 도구
관련 가이드
- robots.txt 작성법: 문법·예제·흔한 실수robots.txt의 규칙 문법과 사이트 유형별 예제, 색인을 망치는 흔한 실수를 정리했습니다.
- 301 vs 302 vs 307/308: 올바른 리다이렉트리다이렉트 상태코드의 차이와 SEO·메서드 보존 관점에서 올바르게 고르는 법.