[2026 최신] 국제적인 웹사이트의 hreflang 태그 사용법 완벽 가이드 | 테라그로스

hreflang 태그, 왜 이걸 제대로 안 박으면 다국어 사이트가 안 굴러갈까 [2026 최신]

해외 진출하는 클라이언트가 늘면서 hreflang 태그 관련 문의가 매주 들어온다. 근데 솔직히, 이 태그만큼 잘못 박혀있는 사이트가 또 없다. 우리가 작년에 인수한 클라이언트 중 한 곳은 한국어/영어/일본어 3개 언어로 운영 중이었는데, hreflang을 잘못 박아둬서 일본 사용자가 구글에서 검색해도 한국어 페이지가 노출되고 있었다. 매출 손실이 얼마였는지 짐작이 가는가.

2026년 현재, 구글의 다국어 처리 방식은 예전보다 훨씬 정교해졌다. 과거에는 hreflang 없이도 IP 기반으로 어느 정도 자동 매칭이 됐지만, 지금은 그렇지 않다. AI Overviews가 도입되면서 언어/지역 시그널이 더 중요해졌고, 잘못된 hreflang은 즉시 노출 손실로 이어진다.

hreflang 태그가 정확히 뭘 하는 건지부터

구글 공식 문서(support.google.com/webmasters/answer/189077)를 그대로 옮기면 “특정 페이지의 언어 및 지역 버전을 검색엔진에 알리는 속성”이라고 나온다. 근데 이 설명만으로는 부족하다. 실무적으로 말하면, hreflang은 구글한테 “이 페이지는 한국어 사용자용이고, 영어 사용자에게는 저쪽 URL을 보여줘”라고 지시하는 라벨이다.

예를 들어 terg.kr/services/ 페이지가 한국어용이고, terg.kr/en/services/가 영어용이라고 치자. hreflang이 제대로 박혀있으면 미국 IP에서 구글 검색했을 때 영어 페이지가 노출된다. 안 박혀있으면? 구글이 알아서 판단하는데, 솔직히 그 판단이 자주 틀린다.

2026년 기준 hreflang 작동 방식

구글은 hreflang을 “신호(signal)”로 받아들이지 “명령”으로 받지 않는다. 즉 hreflang을 박았다고 무조건 그 페이지가 노출되는 게 아니라, 구글이 다른 시그널(canonical, 콘텐츠 언어, 사용자 위치 등)과 종합해서 판단한다. 그래서 hreflang만 박고 끝나면 안 되고 canonical, 콘텐츠 자체의 언어 일관성, 서버 응답 헤더까지 같이 손봐야 한다.

과거에는 hreflang 단독으로도 어느 정도 효과가 있었지만, 지금은 다른 시그널과 충돌하면 무시당한다. 구글 Search Central 블로그가 2025년 말 업데이트에서 명확히 정리했다.

hreflang 코드 – 정확한 작성법

3가지 방식이 있다. HTML head, HTTP 헤더, sitemap.xml. 우리가 가장 많이 쓰는 건 sitemap.xml 방식인데, 이유는 뒤에서 설명한다.

HTML head 방식

가장 흔하게 보는 형식이다. head 태그 안에 이렇게 박는다.

<link rel="alternate" hreflang="ko" href="https://example.com/ko/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

여기서 함정. 모든 페이지가 자기 자신을 포함한 모든 언어 버전을 다 나열해야 한다. 한국어 페이지에 영어 페이지 링크만 박으면 안 되고, 한국어 페이지에도 ko, en, ja, x-default 4개 다 박아야 한다. 이걸 “return tag” 또는 “reciprocal link”라고 한다.

HTTP 헤더 방식

PDF나 이미지처럼 HTML이 아닌 파일에 쓴다. Link 헤더에 박는데, 일반 웹사이트에서는 거의 안 쓴다.

Sitemap 방식 – 우리가 추천

대규모 사이트라면 무조건 이 방식. 페이지마다 head에 박는 게 아니라 sitemap.xml에 xhtml:link로 한 번에 처리한다. 관리도 편하고 페이지 로딩 속도에도 영향이 없다.

sitemap에 박을 때는 이런 식이다.

<url>
  <loc>https://example.com/ko/services/</loc>
  <xhtml:link rel="alternate" hreflang="ko" href="https://example.com/ko/services/" />
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/services/" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/services/" />
</url>

sitemap 시작 부분에 xmlns:xhtml="http://www.w3.org/1999/xhtml" 네임스페이스 선언 빠뜨리면 안 된다. 이거 빼먹는 분들 많다.

언어 코드와 지역 코드 – 가장 많이 틀리는 부분

hreflang 값은 ISO 639-1(언어) + ISO 3166-1 Alpha 2(지역) 형식이다. 이거 헷갈리면 끝장난다. 우리가 직접 본 실수 몇 가지 공유하면.

UK는 잘못된 코드다

영국을 가리킬 때 en-UK라고 박는 분들이 가끔 있는데, 이거 ISO 3166-1에 존재하지 않는 코드다. 정답은 en-GB(Great Britain). UK는 ISO 표준이 아니라서 구글이 무시한다.

중국어는 zh-cmn-Hans 같은 거 쓰지 마라

중국 본토용은 zh-CN, 대만용은 zh-TW, 홍콩용은 zh-HK다. 간체/번체 구분하겠다고 BCP 47 풀 코드 쓰는 분들 있는데, 구글은 그렇게까지 안 본다. 단순하게 가는 게 정답.

스페인어 ES vs LATAM

스페인어 사이트 운영하는 클라이언트가 멕시코랑 스페인 동시에 타겟팅하는 경우 많은데, es만 박으면 어디 살든 다 같이 잡힌다. 구분하려면 es-ES(스페인), es-MX(멕시코), es-AR(아르헨티나) 식으로 지역까지 명시해야 한다. 단, 너무 잘게 쪼개면 페이지 수가 폭발하니까 클라이언트 트래픽 분포 보고 결정한다.

x-default는 뭘까

어느 언어 버전도 매칭이 안 되는 사용자한테 보여줄 기본 페이지다. 보통 영어 페이지나 언어 선택 랜딩페이지로 지정한다. 이거 안 박으면 구글이 알아서 판단하는데, 자주 엉뚱한 결과가 나온다. 무조건 박아라.

canonical과 hreflang의 미묘한 관계

이게 진짜 함정이다. hreflang을 박으면서 canonical을 한국어 페이지로 통일시키는 분들이 있다. 예를 들어 영어 페이지 head에 hreflang으로 한국어/영어 둘 다 박으면서 canonical을 한국어 페이지로 지정하는 케이스. 이렇게 되면 구글은 영어 페이지를 인덱싱 안 한다. canonical 시그널이 hreflang을 덮어버린다.

정답은 – 각 언어 페이지는 자기 자신을 canonical로 지정한다. 영어 페이지의 canonical은 영어 URL, 한국어 페이지의 canonical은 한국어 URL. 그리고 hreflang으로 서로 연결한다.

self-referencing canonical 필수

구글이 2025년 11월 Search Central 업데이트에서 이 부분을 다시 강조했다. self-referencing canonical 없으면 hreflang 클러스터 자체가 깨진다. 클라이언트 사이트 점검 들어가면 가장 먼저 보는 것 중 하나다.

도메인 구조 결정 – 가장 본질적인 부분

hreflang 박기 전에 결정해야 할 게 있다. 다국어 사이트를 어떤 URL 구조로 가져갈 건가. 옵션은 4가지.

1. ccTLD – example.co.kr, example.jp

지역 시그널이 가장 강하다. 근데 도메인을 나라마다 사야 하고, 도메인 권위가 분산된다. 본격 진출한 기업만 추천.

2. 서브도메인 – ko.example.com, en.example.com

관리 분리는 좋은데 도메인 권위가 약하게 분산된다. 가끔 별도 사이트로 취급된다.

3. 서브디렉토리 – example.com/ko/, example.com/en/

우리가 가장 많이 추천하는 방식. 도메인 권위를 그대로 가져가면서 hreflang으로 지역/언어 분리. 신생 사이트나 중소기업한테 거의 항상 이 방식 권한다.

4. URL 파라미터 – example.com?lang=ko

이건 쓰지 마라. 구글이 별로 안 좋아한다. 캐싱도 어렵고 SEO 관점에서 거의 최악.

실수 사례 모음 – 우리가 직접 본 것들

지난 3년간 클라이언트 사이트 점검하면서 본 hreflang 실수 베스트.

실수 1 – 절대 URL 안 쓰기

hreflang href에 상대 경로(/en/services/) 박은 사이트가 의외로 많다. 무조건 절대 URL(https://example.com/en/services/) 써야 한다. 프로토콜(http/https)까지 정확히 매칭.

실수 2 – 404 페이지를 가리키는 hreflang

리뉴얼하면서 영어 페이지를 삭제했는데 hreflang은 그대로 둔 경우. 구글이 hreflang 클러스터 전체를 무시한다. 페이지 삭제할 때 hreflang도 같이 정리해야 한다.

실수 3 – 페이지마다 다른 hreflang 세트

홈페이지엔 5개 언어 박혀있는데 서브 페이지엔 3개만 박혀있는 경우. 일관성이 깨지면 구글이 신뢰 못 한다. 사이트 전체에 통일된 hreflang 정책 필요.

실수 4 – 리다이렉트 체인 안의 페이지를 hreflang으로 지정

301 리다이렉트되는 URL을 hreflang으로 박으면 구글이 처리하지 못한다. 최종 URL을 박아야 한다.

실수 5 – 자동 리다이렉트와 hreflang 동시 사용

IP 기반으로 자동 언어 리다이렉트 시키는 사이트들이 있는데, 이건 구글봇한테 치명적이다. 구글봇은 미국 IP로 크롤링하니까 영어 페이지로 자동 리다이렉트되면 한국어 페이지를 영원히 못 본다. 자동 리다이렉트 대신 언어 선택 배너나 modal 띄우는 게 정답.

점검 도구 – 어떻게 검증할까

박았다고 끝이 아니다. 제대로 작동하는지 검증해야 한다.

구글 서치 콘솔

Search Console > 색인 > Pages 보고서에서 hreflang 관련 오류를 확인할 수 있다. 2026년 들어 인터페이스가 좀 바뀌었는데, “International Targeting” 메뉴는 통합되어서 사라졌다. 대신 색인 오류 리포트에 hreflang 문제가 포함된다.

Screaming Frog

대규모 사이트 점검할 때 필수. hreflang 누락, return tag 없는 페이지, 잘못된 언어 코드까지 한 번에 잡아낸다. 클라이언트 사이트 30,000페이지 점검할 때도 이거 한 방으로 끝낸다.

hreflang.org 무료 검증기

단일 URL 빠르게 점검할 때 좋다. 클러스터가 제대로 연결됐는지 보여준다.

2026년 AI Overviews와 hreflang

최근 가장 많이 받는 질문. “AI Overviews 때문에 hreflang 더 중요해진 거 맞나요?” 답은 그렇다. 우리가 직접 테스트한 결과, AI Overviews는 사용자 언어/지역 시그널을 기존 검색보다 훨씬 적극적으로 활용한다.

한국어 사용자가 영문 콘텐츠를 검색했을 때, AI Overviews는 한국어 페이지가 있으면 그쪽을 우선 인용한다. 즉 hreflang이 잘 박혀있는 사이트는 AI Overviews 노출에서도 유리하다. 단순히 검색 결과뿐만 아니라 생성형 답변에서도 차이가 난다.

GEO 시대 hreflang 전략

Generative Engine Optimization 관점에서 보면, 콘텐츠 자체의 언어 일관성이 점점 더 중요해진다. 한국어 페이지에 영어 단어가 많이 섞이면 AI 모델이 헷갈린다. hreflang만 박지 말고 콘텐츠 톤 자체도 타겟 언어에 맞춰야 한다.

실전 체크리스트 – 클라이언트 사이트 점검할 때 우리가 보는 것

대행사에서 신규 클라이언트 받으면 hreflang은 이렇게 점검한다.

1. 모든 언어 페이지에 self-canonical 있는지 확인

2. hreflang 클러스터가 양방향(reciprocal)으로 연결되는지

3. x-default가 지정되어 있는지

4. 언어/지역 코드가 ISO 표준 준수하는지

5. 절대 URL을 사용하는지

6. 404, 301, noindex 페이지를 가리키지 않는지

7. sitemap.xml에 xhtml 네임스페이스 선언이 있는지

8. 자동 IP 리다이렉트가 없는지

9. Search Console에서 International Targeting 관련 오류가 없는지

10. 페이지별 hreflang 세트가 일관적인지

이 10개만 통과해도 hreflang은 90% 끝난 거다. 나머지 10%는 콘텐츠 품질과 도메인 권위 같은 본질적인 영역.

WordPress, Shopify에서 hreflang 처리

CMS별로 처리 방식이 다르다.

WordPress

WPML, Polylang, TranslatePress가 대표적. WPML이 가장 안정적이고 hreflang 자동 처리 기능이 강력하다. 우리가 클라이언트한테 추천하는 1순위. Polylang은 무료 버전이 있어서 예산 적은 클라이언트한테 추천.

Shopify

Shopify Markets 기능을 쓰면 hreflang이 자동으로 박힌다. 다만 세밀한 컨트롤이 어렵다. 커스텀이 필요하면 Langify 같은 앱을 추가로 써야 한다.

Next.js, Nuxt 같은 SSR 프레임워크

next-i18next, vue-i18n으로 처리한다. head 태그에 직접 박는 코드 작성하거나, sitemap 생성 시 xhtml:link 추가하는 로직 필요. 개발팀과 협업 필수.

비용 대비 효과 – hreflang 작업 가치 있나

이건 클라이언트가 자주 묻는 질문. 솔직히 단일 언어 사이트 운영하다가 hreflang 박는 건 비용 대비 효과 없다. 근데 이미 다국어로 운영 중이거나 해외 진출 계획이 있는 사이트라면 무조건 필요하다.

우리 클라이언트 중 한 곳은 hreflang 정비하고 3개월 만에 일본 시장 organic 트래픽이 2.4배 늘었다. 단순 트래픽 증가만 본 게 아니라 일본 검색에서의 매칭 정확도가 개선되면서 전환율도 같이 올라갔다. 작업 비용은 첫 달에 회수하고도 남았다.

마지막으로 – 흔히 놓치는 디테일

hreflang 박을 때 사람들이 잘 모르는 것 몇 가지.

첫째, hreflang 값에서 언어와 지역 사이는 하이픈(-)이지 언더스코어(_)가 아니다. ko_KR이 아니라 ko-KR. 의외로 헷갈리는 분들 많다.

둘째, hreflang에 대소문자 구분은 없지만, 관례적으로 언어는 소문자(ko), 지역은 대문자(KR)로 쓴다. en-US, ja-JP 이런 식.

셋째, return tag가 깨지면 그 클러스터 전체가 무시된다. A→B 연결만 있고 B→A 연결이 없으면 둘 다 효과 없음. 모든 페이지에서 양방향으로 연결해야 한다.

넷째, hreflang은 SEO에 직접 영향 안 미친다. 순위가 올라가는 게 아니라, “올바른 사용자한테 올바른 페이지가 보이도록” 도와주는 역할. 잘못 박혀서 손해를 막는 게 더 큰 효과다.