국제화 사이트를 만들면서 가장 골치 아픈 게 뭐냐고 물으면, 우리는 망설임 없이 hreflang를 꼽습니다. 페이지 디자인이나 번역 품질은 눈에 보이니까 그래도 챙기는데, hreflang는 안 보이는 곳에서 조용히 망가져 있다가 어느 날 갑자기 “왜 미국 사용자한테 한국어 페이지가 뜨지?” 하는 사고로 터지거든요. 이번 글은 그동안 여러 다국어 계정을 굴리면서 실제로 밟았던 지뢰들을 기준으로, 2026년 현재 구글 공식 가이드(support.google.com)에 맞춰 정리한 내용입니다.
hreflang가 정확히 뭘 하는 태그인가
한 줄로 말하면 hreflang는 “이 페이지는 어떤 언어, 어떤 지역 사용자를 위한 버전이다”라고 구글한테 알려주는 신호입니다. 같은 내용을 한국어, 영어, 일본어로 만들었을 때, 검색엔진이 이 세 페이지가 서로 번역 관계라는 걸 자동으로 알 방법이 없어요. 사람이 보면 당연히 같은 글이지만 봇 입장에선 그냥 별개의 URL 세 개거든요.
여기서 hreflang가 들어갑니다. 각 페이지에 “내 한국어 짝꿍은 여기, 영어 짝꿍은 여기” 식으로 좌표를 박아주는 거죠. 그러면 구글이 검색하는 사용자의 언어와 위치를 보고 가장 맞는 버전을 검색 결과에 노출해 줍니다. 한국에서 검색하면 terg.kr/ko/, 미국에서 검색하면 terg.kr/en/ 이런 식으로요.
주의할 점 하나 – hreflang는 순위를 올려주는 태그가 아닙니다. 솔직히 이걸 SEO 부스터로 오해하는 분들이 의외로 많은데, 이건 순위가 아니라 “맞는 버전을 맞는 사람한테” 보여주는 매칭 신호예요. 중복 콘텐츠로 오인받아서 페이지끼리 서로 깎아먹는 상황을 막아주는 효과가 더 본질에 가깝습니다.
값 형식은 ISO 639-1 언어 코드 + 선택적으로 ISO 3166-1 Alpha-2 지역 코드 조합입니다. ko는 한국어 전체, en-US는 미국 영어, en-GB는 영국 영어. 지역만 단독으로 쓰는 건 안 되고 반드시 언어가 먼저 와야 합니다. 그리고 자주 헷갈리는 게 영국 – 코드가 uk가 아니라 gb예요. uk는 우크라이나어로 처리됩니다.
국제화 사이트에서 hreflang를 안 쓰면 생기는 일
“우리는 그냥 /ko/, /en/ 폴더로 나눠놨는데 그걸로 충분하지 않나요?” 이 질문 정말 많이 받습니다. URL 구조를 나눈 거랑 hreflang를 선언한 건 완전히 다른 얘기예요. 구조만 나눠두면 구글은 그게 번역본인지, 그냥 비슷한 다른 페이지인지 추측에 의존합니다. 그 추측이 틀리는 순간 문제가 시작되죠.
대표적인 증상 세 가지를 봤습니다. 첫째, 잘못된 언어 노출 – 영어권 사용자 검색 결과에 한국어 페이지가 떠서 직행 이탈로 이어지는 경우. 클릭은 했는데 읽을 수가 없으니 바로 나가버립니다. 둘째, 자기잠식 – 한국어판과 영어판이 같은 키워드로 서로 경쟁하면서 둘 다 어중간하게 묻히는 현상. 셋째, 색인 통합 오류 – 구글이 여러 버전 중 하나만 정규 URL로 골라버리고 나머지는 색인에서 빼버리는 케이스입니다.
한 다국어 커머스 사이트에서 hreflang 없이 6개국 버전을 돌리다가, 정작 매출 비중이 큰 동남아 영어 버전이 자국 영어 버전한테 밀려 검색 노출이 거의 사라진 적이 있어요. 태그 정리하고 약 한 달 지나니 해당 지역 유입이 회복되더라고요. 안 보이던 손실이 그제서야 숫자로 잡힌 거죠.
hreflang 구현 방법 세 가지
구글은 hreflang를 선언하는 방법으로 세 가지를 인정합니다. 페이지 성격에 따라 골라 쓰면 되는데, 하나만 일관되게 쓰는 게 핵심이에요. 섞어 쓰면 관리가 지옥이 됩니다.
1. HTML head 태그 방식
가장 직관적이고 가장 많이 쓰는 방식입니다. 각 페이지의 <head> 안에 자기 자신을 포함한 모든 버전을 나열해요.
<link rel="alternate" hreflang="ko" href="https://terg.kr/ko/" />
<link rel="alternate" hreflang="en" href="https://terg.kr/en/" />
<link rel="alternate" hreflang="x-default" href="https://terg.kr/" />
단점은 버전이 많아질수록 head가 무거워진다는 점. 10개국 버전이면 모든 페이지에 10줄씩 들어가야 하니까요. HTML 페이지에만 가능하고 PDF 같은 비HTML 문서에는 못 씁니다.
2. HTTP 헤더 방식
PDF, 이미지처럼 head를 못 넣는 문서에 hreflang를 걸어야 할 때 씁니다. 서버 응답 헤더에 Link 필드로 같은 정보를 실어 보내는 방식이에요. 설정이 서버 단이라 개발 협의가 필요한 편이고, HTML 페이지에 굳이 이 방식을 쓰는 경우는 드뭅니다.
3. XML 사이트맵 방식
버전이 많고 페이지가 수천 개 단위로 넘어가면 우리는 사이트맵 방식을 권합니다. head를 건드리지 않고 사이트맵 한 곳에서 모든 언어 관계를 중앙 관리할 수 있거든요. 각 URL에 xhtml:link 자식 요소로 대체 버전을 명시합니다. 페이지 코드를 안 건드려도 되니까 대규모 사이트일수록 유지보수가 편합니다. 근데 사이트맵이 깨지면 전부 한 번에 무너지니 검증은 더 꼼꼼히 해야 해요.
지금 운영 중인 다국어 사이트의 hreflang가 제대로 박혀 있는지 확신이 안 서시나요?
terg.kr에서 무료 진단을 받아보세요. 실제 색인 상태와 언어 매칭 오류를 함께 점검해 드립니다. 무료 진단 신청하기
x-default와 양방향 링크 – 가장 많이 틀리는 부분
현장에서 hreflang 사고의 8할은 이 두 가지에서 납니다. 진짜로요.
먼저 양방향 링크(return link). hreflang는 짝사랑을 인정 안 합니다. A 페이지가 B를 가리키면, B도 반드시 A를 가리켜야 해요. 한국어판이 영어판을 alternate로 선언했는데 영어판에는 한국어판 선언이 빠져 있으면, 구글은 그 신호 전체를 무시해 버립니다. 한쪽만 작업하고 끝낸 줄 알았다가 통째로 무효 처리되는 거죠. 모든 버전이 서로를 빠짐없이 가리키는 완전한 그물망이어야 합니다.
다음은 x-default. 이건 “위에 나열한 어떤 언어에도 안 맞는 사용자가 오면 여기로 보내라”는 기본값 페이지입니다. 언어 선택 페이지나 글로벌 메인이 보통 여기 해당하죠. 필수는 아니지만 다국어 사이트라면 거의 항상 넣는 걸 권합니다. 안 넣으면 매칭 안 되는 사용자한테 구글이 알아서 아무거나 골라 보여주는데, 그 선택이 마음에 들 확률은 낮거든요.
자기 참조도 빠뜨리면 안 됩니다. 한국어 페이지의 hreflang 목록에는 자기 자신(ko)도 반드시 들어가야 해요. 의외로 “나는 나니까 빼도 되겠지” 하고 누락하는 경우가 많은데, 자기 참조가 없으면 그 페이지의 hreflang 묶음 자체가 불완전한 걸로 처리됩니다.
실무에서 자주 터지는 실수들
지금까지 정리하면서 반복적으로 마주친 패턴들을 모아봤습니다. 체크리스트처럼 훑어보시면 좋아요.
절대 URL을 안 쓰고 상대 경로(/en/)를 박는 실수가 첫 번째. hreflang href는 무조건 프로토콜 포함 전체 URL이어야 합니다. https://부터 다 들어가야 해요. 두 번째는 정규 태그(canonical)와의 충돌 – 각 언어 페이지의 canonical은 다른 언어 버전이 아니라 반드시 자기 자신을 가리켜야 합니다. 영어판 canonical을 한국어판으로 걸어버리면 영어판이 색인에서 통째로 사라집니다. 이거 실제로 꽤 자주 봅니다.
세 번째, 리디렉션되거나 404 나는 URL을 hreflang에 넣는 경우. 지정한 대체 URL은 200 응답을 주는 실제 페이지여야 합니다. 사이트 개편하면서 URL은 바뀌었는데 hreflang는 옛날 주소 그대로 둔 사이트, 정말 흔해요. 네 번째는 언어 코드 오타나 잘못된 조합 – 앞서 말한 uk(영국 의도였는데 우크라이나어), 존재하지 않는 지역 코드, 대소문자 혼동 같은 거요. 구글은 대소문자를 구분 안 하지만 우리끼리 일관성을 위해 보통 언어는 소문자, 지역은 대문자로 통일합니다.
다섯 번째가 좀 미묘한데, 언어와 지역을 혼동하는 문제입니다. 미국 영어 사용자를 노린다고 무조건 en-US로 다 박으면, 영어를 쓰는 다른 나라(캐나다, 호주) 사용자는 그 페이지를 못 받습니다. 지역까지 한정할지, 언어만 잡을지는 콘텐츠가 실제로 지역 특화인지 보고 결정하셔야 해요. 가격이나 통화가 미국 전용이면 en-US, 그냥 영어 콘텐츠면 en이 맞습니다.
2026년 기준 hreflang 검증과 모니터링
과거에는 구글 서치 콘솔 안에 hreflang 전용 인터내셔널 타깃팅 리포트가 따로 있어서 오류를 거기서 봤지만, 지금은 그 리포트가 사라진 상태입니다. 그래서 2026년 현재 우리가 쓰는 검증 방식은 좀 달라졌어요. 한 군데서 다 보여주던 시절은 지났다고 보시면 됩니다.
요즘 우리 워크플로우는 이렇습니다. 먼저 URL 검사 도구로 개별 페이지가 색인됐는지, 구글이 어떤 정규 URL을 골랐는지 확인합니다. 그다음 사이트 크롤러(스크리밍 프로그 같은 도구)로 전체 hreflang 그물망을 떠서 양방향 링크 누락, 깨진 URL, 자기 참조 빠짐을 한 번에 잡아냅니다. 마지막으로 실제 검색 결과에서 지역별로 어떤 버전이 노출되는지 VPN이나 위치 기반 시뮬레이션으로 눈으로 검증하죠.
모니터링은 일회성이 아니라 정기 작업으로 돌려야 합니다. 사이트 개편, 신규 언어 추가, URL 구조 변경 – 이런 이벤트가 있을 때마다 hreflang 그물망은 십중팔구 어딘가 끊깁니다. 분기마다 한 번씩 전체 크롤을 돌려 끊긴 곳을 메우는 루틴을 권합니다. 솔직히 처음 구축보다 유지가 더 어렵습니다.
한국 사이트의 글로벌 진출 시 실전 체크리스트
한국 기업이 해외로 나갈 때 자주 마주치는 상황 기준으로 정리해 드릴게요. 우리가 클라이언트한테 첫 미팅에서 항상 짚는 항목들입니다.
출발은 URL 구조 결정이에요. 서브디렉터리(terg.kr/en/), 서브도메인(en.terg.kr), 별도 도메인(terg.com) 중 어느 쪽이든 hreflang는 다 작동하지만, 권위를 한 도메인에 모으고 싶으면 보통 서브디렉터리를 추천합니다. 운영 부담도 가장 가볍고요.
그다음 언어판과 지역판을 구분합니다. 영어 하나만 추가할 거면 en + x-default + ko 조합으로 단순하게 가는 게 낫습니다. 처음부터 en-US, en-GB, en-SG를 다 쪼개면 관리만 복잡해지고 정작 콘텐츠 차별화가 없어서 의미가 없거든요. 지역별로 가격, 통화, 법적 고지가 진짜 다를 때만 지역 코드를 쪼개세요.
마지막으로 번역 품질과 hreflang는 별개라는 걸 잊지 마시고요. 기계번역 페이지에 hreflang만 완벽하게 박아봐야 사용자가 어색한 번역에 이탈하면 결국 성과는 안 납니다. 태그는 길 안내일 뿐이고, 도착지의 콘텐츠가 좋아야 전환이 일어납니다. 근데 그 반대도 마찬가지예요 – 번역이 아무리 좋아도 hreflang가 끊겨 있으면 그 페이지에 사람이 도달을 못 합니다. 둘 다 챙겨야 비로소 글로벌 유입이 숫자로 잡히기 시작합니다.
다국어 사이트 구축부터 hreflang 설계, 색인 점검까지 한 번에 정리하고 싶으시다면 terg.kr이 도와드립니다. 글로벌 진출 단계에 맞춰 URL 구조 설계와 검증 루틴까지 함께 잡아드려요.
자주 묻는 질문
hreflang 태그를 달면 검색 순위가 올라가나요
아닙니다. hreflang는 순위 상승 요소가 아니라 맞는 언어/지역 버전을 맞는 사용자에게 매칭해 주는 신호입니다. 다만 다국어 버전끼리 중복으로 오인돼 서로 깎아먹는 자기잠식을 막아주기 때문에, 결과적으로 검색 성과가 개선되는 효과는 있습니다.
hreflang와 canonical 태그는 어떻게 같이 써야 하나요
각 언어 페이지의 canonical은 반드시 자기 자신을 가리켜야 합니다. 영어판 canonical을 한국어판으로 걸면 영어판이 색인에서 빠집니다. canonical은 자기 참조, hreflang는 대체 버전 안내 – 역할이 다르므로 충돌하지 않게 분리해서 설정하세요.
언어 코드만 쓸지 지역 코드까지 붙일지 어떻게 정하나요
콘텐츠가 실제로 지역 특화인지를 기준으로 판단합니다. 가격, 통화, 배송, 법적 고지가 지역마다 다르면 en-US처럼 지역 코드까지 붙이고, 단순히 같은 언어 콘텐츠라면 en처럼 언어만 지정하는 편이 더 많은 사용자를 포괄합니다.
x-default는 꼭 넣어야 하나요
필수는 아니지만 다국어 사이트라면 거의 항상 권장합니다. 지정한 어떤 언어/지역에도 맞지 않는 사용자가 들어왔을 때 보낼 기본 페이지를 명시하는 값입니다. 안 넣으면 구글이 임의로 버전을 골라 노출하므로, 언어 선택 페이지나 글로벌 메인을 x-default로 지정해 두는 게 안전합니다.
hreflang를 다 넣었는데 적용이 안 되는 이유는 뭔가요
가장 흔한 원인은 양방향 링크 누락입니다. A가 B를 가리키면 B도 A를 가리켜야 하는데 한쪽이 빠지면 신호 전체가 무효 처리됩니다. 그다음으로 자기 참조 누락, 상대 경로 사용, 리디렉션되거나 404 나는 URL 지정, 언어 코드 오타가 흔한 원인입니다. 크롤링 도구로 전체 그물망을 점검하면 대부분 잡아낼 수 있습니다.
![[2026 최신] 스키마 마크업을 통한FAQ 페이지 구조화 데이터 구현 방법 완벽 가이드 | 테라그로스](https://terg.kr/wp-content/uploads/2026/06/featured_20260610150218-500x383.png)
![[2026 최신] 스키마 마크업을 통한 FAQ 페이지 최적화 완벽 가이드 | 테라그로스](https://terg.kr/wp-content/uploads/2026/06/featured_20260604130237-500x383.png)
![[2026 최신] 스키마 마크업 적용 시 고려사항 완벽 가이드 | 테라그로스](https://terg.kr/wp-content/uploads/2026/05/featured_20260525103340-500x383.png)
