다국어 홈페이지 hreflang 태그 제대로 쓰는 법

다국어 홈페이지에서 hreflang을 잘못 쓰면 엉뚱한 언어가 검색에 뜹니다. 코드 형식, 구현 방법, 흔한 실수 9가지까지 예시로 정리했습니다.

이루웹2026년 8월 2일29분 분량

해외 손님을 받으려고 한국어·영어·일본어로 홈페이지를 나눠 만들었는데, 정작 구글 검색에는 한국어 페이지만 계속 뜬다면 원인은 대부분 하나다. hreflang 태그가 없거나 잘못 걸려 있는 것이다.

결론부터 말하면 이렇다. hreflang은 "이 페이지의 한국어 버전은 여기, 영어 버전은 저기에 있다"고 구글에게 언어별 페이지 지도를 그려주는 태그다. 형식만 정확히 지키면 코드 몇 줄로 끝나지만, 형식이 조금만 어긋나도 구글은 태그 전체를 통째로 무시해 버린다.

그래서 hreflang은 "달았다"와 "제대로 달았다" 사이의 격차가 유독 큰 항목이다. 실제로 국제 SEO 감사에서 발견되는 오류의 상당수가 hreflang에서 나온다. 코드 자체는 몇 줄뿐이라 얕보기 쉽지만, 형식 규칙이 촘촘해서 오히려 손이 많이 가는 작업이기도 하다.

다국어 홈페이지 hreflang 태그 설정 가이드 — hreflang은 언어별 페이지를 구글에게 정확히 안내하는 지도 역할을 한다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

hreflang의 정확한 역할: 순위를 올리는 태그가 아니라 "맞는 언어를 맞는 사람에게" 보여주는 태그
코드 형식: 언어코드(ISO 639-1) + 지역코드(ISO 3166-1), x-default의 정확한 용법
구현 방법 3가지: HTML 링크 태그, HTTP 헤더, XML 사이트맵 — 셋을 섞으면 오히려 손해
가장 흔한 실수 9가지: 자기 참조 누락부터 상대경로까지, 좋은 예와 나쁜 예로 비교
서브디렉토리·서브도메인·ccTLD 중 다국어 홈페이지에 맞는 구조와 검증 방법까지

조금 더 풀어 말하면, 다국어 홈페이지는 단순히 "번역본을 하나 더 만드는 일"이 아니다. 구글 입장에서는 완전히 다른 두 페이지가 갑자기 나타난 것과 같다. 이 둘을 "같은 내용의 다른 언어 버전"이라고 설명해 주지 않으면, 구글은 둘을 경쟁 관계의 중복 콘텐츠로 오해하거나, 검색하는 사람의 언어와 무관하게 아무 버전이나 보여줄 수 있다.

이 글은 코드를 처음 만져보는 사업가도 오늘 바로 자기 홈페이지에 적용할 수 있도록, 정의부터 구현 방법, 실수 사례, 검증 방법까지 예시 중심으로 쉽게 정리한다. 이미 다국어 홈페이지를 운영 중이라면 지금 상태를 점검하는 체크리스트로 써도 좋다.

쇼핑몰이 해외 배송을 시작하며 영어 페이지를 추가하는 경우, 여행사가 일본어·중국어 관광객을 받으려는 경우, 제조업체가 해외 바이어에게 카탈로그를 영문으로 보여주려는 경우까지 — 다국어 홈페이지가 필요한 상황은 제각각이지만, hreflang을 다루는 원리는 동일하다. 아래 순서대로 하나씩 짚어보자.

hreflang 태그란 무엇인가?

hreflang은 "이 페이지와 같은 내용을 다른 언어·지역으로 옮긴 페이지가 어디에 있는지" 검색엔진에게 알려주는 HTML 속성이다. 정식 이름은 rel="alternate" hreflang="언어코드"이고, 2011년 구글이 처음 지원을 발표한 이후 국제 SEO의 표준 도구로 자리 잡았다.

역할을 한 문장으로 요약하면 이렇다. hreflang은 순위를 올려주는 태그가 아니라, 맞는 사람에게 맞는 버전을 보여주는 태그다. 한국에서 검색하면 한국어 페이지가, 일본에서 검색하면 일본어 페이지가 뜨도록 안내판을 세우는 것이지, 검색 결과 자체를 더 위로 끌어올리는 기능은 없다.

hreflang이 없으면 어떤 일이 벌어질까?

미국에 있는 사람이 검색해도 한국어 페이지가 노출될 수 있다.
한국어·영어 페이지가 서로 경쟁하는 중복 콘텐츠로 오해받을 수 있다.
사용자가 클릭 후 자신이 못 읽는 언어를 만나 곧바로 이탈한다.

반대로 hreflang을 정확히 걸어두면, 검색하는 사람의 언어·지역 설정에 맞는 버전이 노출될 확률이 크게 올라간다. 해외 진출을 준비하는 홈페이지, 다국적 고객을 받는 쇼핑몰, 여러 나라에 지사를 둔 기업 사이트라면 반드시 챙겨야 하는 이유다.

hreflang은 "번역했다"는 사실을 알리는 태그가 아니라 "이 페이지들은 서로의 대체 버전"이라는 관계를 알리는 태그다. 관계 선언이 빠지면 구글은 두 페이지를 남남으로 본다.

hreflang 개념도 - 한국어 영어 일본어 페이지가 자기 자신과 서로를 가리키는 구조 — 모든 언어 버전이 자기 자신을 포함해 서로를 빠짐없이 링크해야 한다.

업종별로 어떤 문제가 생기는지 구체적으로 보면 이렇다.

쇼핑몰: 해외 배송을 시작하며 영어 상품 페이지를 만들었지만 hreflang이 없으면, 미국 사용자가 검색해도 원화 가격이 적힌 한국어 상품 페이지가 뜨는 일이 흔하다. 결제 통화·배송비 안내가 다른 언어로 보이는 순간 구매 전환은 크게 떨어진다.
여행사·숙박업: 일본어·중국어 관광객을 겨냥해 언어별 예약 페이지를 만들어도, hreflang이 없으면 검색 결과에 한국어 페이지만 계속 노출돼 애써 만든 다국어 페이지가 트래픽을 못 받는다.
제조업·B2B: 해외 바이어에게 보여줄 영문 카탈로그 페이지가 있어도, hreflang과 canonical이 꼬여 있으면 구글이 영문 페이지를 "한국어 페이지의 중복"으로 판단해 색인에서 제외해 버리는 경우가 있다.

세 사례의 공통점은 다국어 페이지 자체는 이미 잘 만들어 놓고도, 지도(hreflang)가 없어서 검색엔진이 못 찾아간다는 것이다.

hreflang 코드는 어떻게 쓰나?

hreflang 값은 언어코드 단독 또는 언어코드-지역코드 두 형태로 쓴다. 언어코드는 ISO 639-1(예: ko, en, ja), 지역코드는 ISO 3166-1 알파-2(예: KR, US, JP) 표준을 따르며, 둘을 붙일 때는 하이픈(-)으로 연결한다.

좋은 예:

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

나쁜 예:

<link rel="alternate" hreflang="KR" href="https://example.com/ko/" />
<link rel="alternate" hreflang="en_US" href="https://example.com/en-us/" />

위 나쁜 예는 두 가지가 틀렸다. KR은 지역코드일 뿐 언어코드가 아니어서 무효고(언어코드 없이 지역코드만 쓰는 것은 규격에 없다), en_US처럼 밑줄(_)을 쓰면 하이픈 규격을 벗어나 인식되지 않는다. 언어코드는 소문자, 지역코드는 대문자가 관례지만, 대소문자 자체는 구글이 관대하게 처리하는 편이다. 다만 구분 기호는 반드시 하이픈이어야 한다.

x-default는 별도의 언어다. "방문자의 브라우저 언어·지역과 어떤 버전도 맞지 않을 때 보여줄 기본 페이지"를 지정하는 값으로, 언어·국가를 직접 선택하는 랜딩 페이지나 첫 화면에 주로 쓴다. 모든 사이트에 필수는 아니지만, 다국어 홈페이지의 첫 진입점(도메인 루트)이 있다면 지정해 두는 것이 안전하다.

간체·번체 중국어처럼 스크립트(문자 체계)가 다른 경우는 zh-Hans(간체), zh-Hant(번체)처럼 스크립트 코드를 붙여 구분한다. 단순히 zh-CN, zh-TW로만 써도 동작하지만, 문자 체계 기준으로 명확히 나누고 싶다면 스크립트 코드가 더 정확하다.

hreflang을 구현하는 방법은 몇 가지인가?

구현 방법은 세 가지이며, 셋 중 하나만 골라 일관되게 쓰는 것이 원칙이다. 여러 방법을 동시에 섞어 쓴다고 효과가 더 좋아지지 않고, 오히려 서로 다른 정보가 충돌해 혼란만 커진다.

방법	적용 위치	이런 사이트에 적합
HTML 링크 태그	각 페이지 `<head>` 안	일반적인 다국어 홈페이지 대부분
HTTP 헤더	서버 응답 헤더	PDF 등 HTML이 아닌 파일
XML 사이트맵	사이트맵 파일 내 `xhtml:link`	페이지 수가 많아 각 파일을 일일이 수정하기 번거로운 대규모 사이트

1. HTML 링크 태그는 가장 널리 쓰는 방법이다. 각 언어 페이지의 <head> 안에, 자기 자신을 포함한 모든 언어 버전을 나열한다.

<head>
  <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/pricing" />
</head>

2. HTTP 헤더 방식은 PDF나 이미지처럼 <head> 자체가 없는 파일에 쓴다. 서버 설정에서 응답 헤더에 다음처럼 넣는다.

Link: <https://example.com/ko/file.pdf>; rel="alternate"; hreflang="ko",
      <https://example.com/en/file.pdf>; rel="alternate"; hreflang="en"

3. XML 사이트맵 방식은 각 URL 항목 안에 xhtml:link 자식 요소로 언어 버전을 나열한다. 페이지마다 태그를 넣는 대신 사이트맵 파일 하나로 한꺼번에 관리할 수 있어, 페이지 수가 많은 사이트에서 유지보수가 편하다.

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

hreflang 구현 방법 3가지 비교 - HTML 링크 태그, HTTP 헤더, XML 사이트맵 — 세 방법 중 하나만 골라 사이트 전체에 일관되게 적용하는 것이 안전하다.

세 방법을 동시에 다 써도 추가 이득은 없다는 것이 구글의 공식 입장이다. 규모가 작은 홈페이지는 HTML 링크 태그 하나면 충분하다.

hreflang에서 가장 흔한 실수는 무엇인가?

hreflang 오류의 대부분은 아래 아홉 가지 중 하나에서 나온다. 하나만 틀려도 구글이 태그 전체를 무시할 수 있으므로, 발행 전에 하나씩 대조해 보는 것이 좋다.

hreflang 흔한 실수 - 자기 참조 누락과 리턴 태그 누락 나쁜 예와 좋은 예 비교 — 자기 참조와 리턴 태그(상호 링크)가 빠지면 나머지가 다 맞아도 무시될 수 있다.

자기 참조(self-reference) 누락: 페이지는 다른 언어 버전뿐 아니라 자기 자신도 hreflang 목록에 포함해야 한다. 한국어 페이지라면 한국어 페이지 자신을 가리키는 hreflang="ko" 태그도 있어야 한다.
리턴 태그(return link) 누락: A 페이지가 B 페이지를 가리키면, B 페이지도 반드시 A를 가리켜야 한다. 한쪽만 걸린 편도 링크는 무효 처리된다. 언어가 3개면 각 페이지가 3개 버전을 모두 링크해야 한다.
잘못된 언어·지역 코드: KR처럼 지역코드만 쓰거나, en_US처럼 밑줄을 쓰는 경우. 언어코드 없이 지역코드만 쓰면 구글이 아예 다른 언어(예: be는 벨라루스어)로 잘못 해석하기도 한다.
canonical과의 충돌: 각 언어 버전은 자기 자신을 가리키는 canonical을 가져야 한다. 영어 페이지의 canonical이 한국어 페이지를 가리키면, 구글은 영어 페이지를 "중복본"으로 보고 색인에서 제외해 버릴 수 있다. hreflang과 canonical은 서로 다른 목적의 태그이므로 혼동하지 않아야 한다.
상대경로 사용: href="/en/pricing"처럼 도메인을 뺀 상대경로는 인식되지 않는다. https://로 시작하는 완전한 URL을 써야 한다. 개발 환경에서 테스트할 때 상대경로로 써두고 배포 시 그대로 놓치는 경우가 의외로 많다.
차단되거나 깨진 페이지 연결: noindex 처리된 페이지나 404 페이지를 hreflang 목록에 넣으면 안 된다. 크롤러가 도달할 수 없는 페이지를 가리키는 hreflang은 신뢰를 잃는다.
x-default 오류: 존재하지 않는 페이지를 가리키거나, 값 자체를 빠뜨리는 경우. 다국어 랜딩(언어 선택) 페이지가 따로 있다면 그 페이지를 x-default로 지정하는 것이 자연스럽다.
여러 버전이 같은 URL을 공유: 언어별로 URL이 달라야 하는데, 실수로 여러 언어 태그가 같은 주소를 가리키는 경우. 흔히 다국어 페이지를 나중에 추가하면서 임시로 원본 URL을 복사해 두고 내용만 바꾸지 않은 채 방치할 때 생긴다.
<head> 밖에 배치: hreflang 태그가 본문(<body>) 안에 들어가 있으면 무시된다. 반드시 <head> 안에 있어야 하며, 일부 콘텐츠관리시스템(CMS)에서 본문 HTML 편집기에 태그를 실수로 붙여넣는 경우가 있으니 주의한다.

이 중에서도 1번과 2번이 실무에서 가장 자주 나오고, 파급력도 가장 크다. 자기 참조나 리턴 링크가 빠지면 구글은 "이 hreflang 세트 자체가 신뢰할 수 없다"고 판단해 나머지 언어 태그까지 통째로 무시하는 경우가 많기 때문이다.

자동 번역 콘텐츠에 hreflang을 써도 될까?

써도 된다. 다만 번역의 품질이 관건이다. hreflang 자체는 번역 방식(사람이 했는지, AI가 했는지)을 따지지 않는다. 문제는 hreflang이 아니라 콘텐츠의 가치다.

구글의 스팸 정책 중 "대량 생성 콘텐츠 남용" 항목은 "번역을 포함한 자동 변환으로 대량의 페이지를 만들어 검색 순위 조작을 노리는 행위"를 스팸으로 규정한다. 즉 기계 번역 자체가 아니라, 사용자에게 별다른 가치를 더하지 않으면서 페이지 수만 늘리는 행위가 문제가 된다는 뜻이다.

실제로 구글은 대형 커뮤니티 사이트가 AI로 수백만 페이지를 번역해 다국어 서비스를 확장한 사례에 대해, 사용자에게 실질적 가치가 있다면 문제 삼지 않는다는 취지의 입장을 보인 바 있다. 반대로 원문 품질이 낮은 콘텐츠를 기계 번역만 돌려 여러 언어로 찍어내듯 뿌리는 방식은 스팸으로 분류될 가능성이 있다.

실무 판단 기준은 이렇게 잡으면 된다.

자동 번역을 쓰더라도 사람이 한 번 검수하고, 어색한 표현이나 현지 관용구를 다듬는 과정을 거치면 안전하다. 완전 자동·무검수 대량 번역은 피하는 것이 좋다.

특히 가격, 법적 고지, 상품 스펙처럼 오역이 손해로 이어지는 페이지는 기계 번역만으로 발행하지 말고, 최소한 담당자가 한 번은 읽어보는 절차를 두는 것을 권한다.

번역만 하면 검색엔진에 잘 잡힐까?

아니다. 언어마다 키워드 리서치를 따로 해야 한다. 한국어 문장을 그대로 영어로 옮긴다고, 그 영어 표현이 실제로 미국 사람들이 검색하는 단어와 일치하는 것은 아니기 때문이다.

예를 들어 한국어로 "임플란트 비용"을 그대로 직역하면 "implant cost"가 되지만, 실제 영어권 사용자는 "dental implant cost" 또는 "tooth implant price"처럼 조금 다른 표현을 검색하는 경우가 많다. 번역가는 뜻이 통하는 문장을 만들지만, 검색엔진 최적화는 사람들이 실제로 입력하는 단어를 써야 하는 별개의 작업이다.

그래서 다국어 홈페이지를 제대로 하려면 다음 순서를 권한다.

각 언어권에서 실제로 많이 검색되는 키워드를 그 언어의 검색 도구로 따로 조사한다.
조사한 키워드를 자연스럽게 반영해 번역이 아니라 그 언어로 새로 쓴다는 마음가짐으로 카피를 다듬는다.
제목 태그, 메타 디스크립션도 언어별로 각각 최적화한다. 하나를 번역해 재사용하지 않는다.

이 과정을 생략하면, hreflang을 완벽하게 걸어도 애초에 그 언어권에서 검색되지 않는 단어로 채워진 페이지라 노출 자체가 잘 일어나지 않는다.

다국어 사이트 URL 구조는 어떻게 정해야 하나?

hreflang을 걸기 전에 먼저 정해야 할 것이 URL 구조다. 크게 세 가지 방식이 있고, 대부분의 홈페이지에는 서브디렉토리 방식이 가장 무난하다.

구조	예시	장점	단점
서브디렉토리	`example.com/ko/`, `example.com/en/`	도메인 신뢰도(권위)를 언어 버전끼리 공유. 관리가 쉽고 비용도 들지 않음	언어별로 완전히 분리된 브랜딩은 어려움
서브도메인	`ko.example.com`, `en.example.com`	언어별로 서버·팀을 분리하기 쉬움	구글이 부분적으로 별도 사이트처럼 취급할 수 있어 권위 공유 효과가 약함
ccTLD(국가별 도메인)	`example.co.kr`, `example.jp`	현지 사용자에게 신뢰도가 가장 높고, 지역 타겟팅 신호가 가장 강함	도메인을 나라마다 새로 사야 해 비용과 관리 부담이 가장 큼

소규모·중소 홈페이지라면 서브디렉토리를 권한다. 도메인 하나로 관리할 수 있고, 검색엔진이 쌓아온 도메인 신뢰도를 언어 버전끼리 나눠 쓸 수 있어 새 언어를 추가할 때도 초반 노출이 비교적 빠르다. 반대로 국가마다 완전히 다른 법인·브랜드로 운영한다면 ccTLD가 더 어울린다.

주의할 점: URL 구조를 무엇으로 하든 hreflang은 똑같이 필요하다. "서브디렉토리로 나눴으니 hreflang 없이도 구글이 알아서 구분하겠지"라고 생각하면 오산이다. URL 구조는 사람이 봤을 때 언어를 구분하는 장치이고, hreflang은 검색엔진에게 그 관계를 명시적으로 알려주는 별개의 장치다.

이미 단일 언어로 운영 중인 사이트에 새 언어를 추가한다면, 굳이 기존 구조를 바꿀 필요는 없다. 예를 들어 한국어 페이지가 이미 도메인 루트(example.com)에서 잘 운영되고 있었다면, 영어 버전만 example.com/en/ 서브디렉토리로 새로 만들고 한국어 페이지는 그대로 두는 방식이 가장 무난하다. 굳이 기존 한국어 페이지까지 /ko/로 옮기면 URL이 바뀌면서 그동안 쌓인 색인·백링크 효과가 일시적으로 흔들릴 수 있으니, 정말 필요한 경우가 아니라면 피하는 것이 좋다.

현지화까지 해야 다국어 홈페이지가 완성되나?

아니다. 번역은 시작일 뿐, 현지화(로컬라이제이션)까지 해야 완성이다. 문장을 다른 언어로 옮기는 것과, 그 나라 사람이 자연스럽게 느끼도록 다듬는 것은 다른 작업이다.

나쁜 예: 한국어 원문을 그대로 기계 번역기에 돌려, 통화 단위는 원화 그대로 두고, 전화번호도 한국 국가번호 없이 그대로 표기하고, 주소 형식도 한국식 그대로 옮긴 영어 페이지.

좋은 예: 통화 단위를 방문자 지역에 맞게 바꾸고(또는 최소한 통화 기호를 명시하고), 국가번호를 포함한 전화번호를 쓰고, 날짜·주소 표기를 현지 관습에 맞추고, 결제 수단도 그 나라에서 실제로 쓰는 방식을 안내한 영어 페이지.

현지화가 특히 중요한 항목은 다음과 같다.

통화·가격 표기: ₩50,000을 그대로 보여주면 해외 방문자는 실제 부담 금액을 가늠하기 어렵다.
전화번호·주소 형식: 국가번호(+82)를 빠뜨리면 해외에서 전화를 걸 수 없다.
날짜·단위: 2026.08.02 같은 표기는 나라마다 읽는 순서가 달라 오해를 부를 수 있다.
문화적 관용구: 한국어 특유의 표현(예: "믿고 맡겨주세요")을 직역하면 어색하거나 뜻이 통하지 않는 경우가 많다.

번역은 언어를 바꾸는 일이고, 현지화는 신뢰를 쌓는 일이다. 다국어 홈페이지의 이탈률을 낮추는 힘은 대부분 후자에서 나온다.

언어 선택기(랭귀지 스위처)는 어떻게 만들어야 안전한가?

방문자가 스스로 언어를 바꿀 수 있는 버튼은 모든 페이지에 남겨두어야 한다. IP나 브라우저 언어를 감지해 자동으로 다른 언어 페이지로 넘기는 기능 자체는 사용자 경험에 도움이 되지만, 이를 강제 리다이렉트로 구현하면 두 가지 문제가 생긴다.

첫째, 검색엔진 크롤러까지 자동으로 다른 페이지로 튕겨 나가면서 원하는 언어 버전에 접근하지 못해 색인이 안 되는 경우가 생긴다. 둘째, 사용자가 일부러 다른 나라 언어로 보고 싶어도(예: 한국에 사는 외국인이 영어 페이지를 원하는 경우) 강제로 한국어 페이지로 돌아가 버려 불편을 준다.

안전한 구현 방식은 이렇다.

자동 감지는 첫 방문 시 안내(팝업이나 배너) 정도로만 쓰고, 강제로 리다이렉트하지 않는다.
페이지 상단이나 하단에 모든 언어 버전으로 이동하는 링크를 항상 노출한다.
한 번 사용자가 언어를 직접 선택했다면, 이후 방문에서는 그 선택을 쿠키 등으로 기억해 존중한다.

이렇게 만들어야 크롤러도 모든 언어 페이지를 문제없이 발견하고, 실제 방문자도 원하는 언어를 자유롭게 오갈 수 있다.

국내 홈페이지 빌더에서도 다국어·hreflang이 가능한가?

가능하다. 아임웹, 카페24 같은 국내 홈페이지 제작 플랫폼도 다국어 사이트(언어별 별도 사이트) 기능을 제공하며, 이 경우 플랫폼이 언어 버전 간 연결 정보를 자동으로 처리해 주는 경우가 많다. 다만 플랫폼마다 hreflang을 어디까지 자동으로 생성해 주는지는 차이가 크고, 계속 업데이트되는 영역이므로 도입 전에 반드시 해당 플랫폼의 최신 고객센터 안내나 담당 매니저에게 직접 확인하는 것이 안전하다.

워드프레스처럼 직접 구축하는 방식이라면 다국어 플러그인을 설치해 언어 버전을 관리하면서, 플러그인이 hreflang을 자동 생성하는지 여부를 설정 화면에서 확인해야 한다. 자동 생성 기능이 없다면 앞서 설명한 HTML 링크 태그 방식을 직접 추가하거나, 개발자에게 요청해야 한다.

플랫폼을 고를 때 체크할 질문은 이렇게 정리할 수 있다.

언어별로 별도 URL(서브디렉토리 또는 서브도메인)이 만들어지는가?
hreflang 태그가 자동으로 생성되는가, 수동으로 입력해야 하는가?
자동 번역 기능이 있다면, 번역문을 직접 수정할 수 있는가?

이 세 가지에 "예"라고 답할 수 있는 플랫폼이라면 다국어 SEO 기반은 충분히 갖춘 셈이다. 반대로 세 질문 중 하나라도 "잘 모르겠다"는 답이 나온다면, 계약이나 요금제를 결정하기 전에 반드시 확인부터 하는 것을 권한다. 다국어 기능은 플랫폼을 옮긴 뒤에 다시 세팅하려면 URL 구조 자체가 바뀌어 처음부터 다시 색인을 쌓아야 하는 경우가 많기 때문이다.

바로 쓰는 hreflang 템플릿

한국어·영어·일본어 세 언어로 서비스 페이지를 운영한다면, 세 페이지 모두 <head> 안에 아래와 같은 동일한 세트를 넣으면 된다. x-default는 언어 선택이 가능한 루트 페이지(예: 도메인 최상단)로 지정했다.

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

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

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

핵심은 세 페이지 모두 완전히 같은 태그 세트를 갖는다는 점이다. 새 페이지 하나를 추가할 때마다 이미 있던 언어 버전들의 태그에도 새 페이지를 빠짐없이 추가해야 리턴 태그 누락을 막을 수 있다. 페이지 수가 늘어날수록 이 작업은 수작업보다 앞서 설명한 XML 사이트맵 방식이나 CMS의 자동 생성 기능에 맡기는 편이 안전하다.

어떤 페이지부터 다국어로 만들어야 하나?

전체 사이트를 한 번에 번역하려 하지 말고, 손님이 실제로 구매·문의를 결정하는 페이지부터 순서를 정한다. 처음부터 모든 페이지를 다국어로 만들려다 예산과 시간에 밀려 흐지부지되는 경우가 많다.

우선순위는 대략 이렇게 잡으면 된다.

홈페이지(메인): 첫인상을 결정하는 페이지이자 x-default로 지정하기도 좋은 위치다.
핵심 상품·서비스 소개 페이지: 방문자가 "이 회사가 무엇을 파는지" 판단하는 페이지다.
가격·견적 안내 페이지: 통화·결제 방식 현지화가 가장 중요한 페이지다.
문의·상담(컨택트) 페이지: 실제 전환이 일어나는 페이지이므로 번역 품질에 가장 신경 써야 한다.
회사 소개, 이용약관, 개인정보처리방침: 신뢰를 뒷받침하지만 급하지 않은 페이지로, 뒤로 미뤄도 무방하다.

이 순서로 진행하면, 예산이 한정돼 있어도 전환에 직접 영향을 주는 페이지부터 다국어·hreflang 세팅을 끝낼 수 있다.

hreflang이 제대로 적용됐는지 어떻게 확인하나?

발행만 하고 끝내면 안 된다. hreflang은 형식 오류가 조용히 묻히는 태그라서, 검증 절차를 꼭 거쳐야 한다.

구글 서치 콘솔: 페이지 색인 상태 보고서에서 언어 버전별로 URL을 확인한다. 특정 언어 페이지만 계속 "색인 생성 제외"로 뜬다면 hreflang·canonical 충돌을 가장 먼저 의심한다. 새로 hreflang을 추가·수정했다면 해당 URL을 "URL 검사" 도구로 재크롤링 요청해 반영 속도를 앞당길 수 있다.
페이지 소스 보기: 각 언어 페이지에서 Ctrl+U(또는 우클릭 → 페이지 소스 보기)로 <head> 안에 hreflang 태그가 정확히 들어갔는지, 자기 자신과 다른 언어 버전이 모두 있는지 눈으로 확인한다. 페이지를 열 때마다 실제로 렌더링된 HTML을 보는 것이지, 개발 문서상의 설계도가 아니라는 점이 중요하다.
전용 검증 도구: 무료로 hreflang 태그를 검사해 주는 온라인 도구들이 있다. URL을 입력하면 리턴 태그 누락, 잘못된 코드, 자기 참조 누락 같은 오류를 항목별로 잡아 알려주므로, 언어 버전이 3개 이상이라면 수작업 대조보다 훨씬 빠르고 정확하다.
site: 검색: site:example.com/en/처럼 언어별 경로로 검색해, 실제로 그 언어 버전이 색인돼 있는지 눈으로 확인한다. 검색 결과가 전혀 안 뜬다면 hreflang 문제이기 전에 애초에 크롤링·색인 자체가 안 됐을 가능성도 함께 점검해야 한다.

이 네 가지를 새 언어 버전을 추가할 때마다 반복하면, 오류를 몇 달씩 방치하는 일을 막을 수 있다. hreflang 오류는 사이트가 "겉보기엔 멀쩡한데 특정 언어권에서만 유입이 안 되는" 형태로 나타나기 때문에, 원인을 모르면 엉뚱한 곳(콘텐츠, 광고)에서 해법을 찾다가 시간을 허비하기 쉽다.

발행 전 체크리스트

모든 언어 페이지가 자기 자신을 hreflang 목록에 포함했는가
모든 언어 버전이 서로를 되돌아 링크(리턴 태그)하는가
언어·지역 코드가 ISO 639-1 / ISO 3166-1 표준을 따르는가
href 값이 완전한 URL(https://로 시작)인가
각 언어 버전의 canonical이 자기 자신을 가리키는가
HTML 링크 태그·HTTP 헤더·사이트맵 중 한 가지 방법만 쓰고 있는가

자주 묻는 질문

hreflang을 걸면 순위가 오르나요?

아니다. hreflang은 순위 신호가 아니라 어떤 버전을 누구에게 보여줄지 정하는 신호다. 순위 자체는 각 언어 페이지의 콘텐츠 품질, 내부 링크, 로딩 속도 같은 일반적인 SEO 요소로 결정된다. 다만 엉뚱한 언어가 노출돼 이탈하던 손님이 맞는 언어를 만나게 되면서, 결과적으로 클릭률과 체류시간이 개선되는 효과는 자주 나타난다.

언어가 하나뿐인 홈페이지도 hreflang이 필요한가요?

필요 없다. hreflang은 같은 내용을 여러 언어·지역 버전으로 운영할 때만 의미가 있다. 한국어 페이지 하나만 있다면 hreflang을 걸 대상 자체가 없으므로 신경 쓰지 않아도 된다.

자동 번역기로 만든 페이지도 hreflang을 걸 수 있나요?

걸 수 있다. 앞서 설명했듯 hreflang 자체는 번역 방식을 문제 삼지 않는다. 다만 자동 번역만으로 대량 발행하는 방식은 콘텐츠 품질 측면에서 위험할 수 있으니, 최소한 한 번은 사람이 검수하는 절차를 두는 편이 안전하다.

hreflang을 잘못 걸면 페널티(제재)를 받나요?

패널티는 없다. hreflang 오류는 스팸 행위가 아니라 단순한 형식 오류이므로, 구글이 사이트를 불이익 처리하지 않는다. 다만 오류가 있는 태그는 통째로 무시되고, 그 결과 "엉뚱한 언어가 노출된다"는 원래의 문제가 그대로 남을 뿐이다. 즉 벌을 받는 것이 아니라, 기대한 효과를 아예 못 보는 것에 가깝다고 이해하면 된다.

영어 페이지 하나로 미국·영국 손님을 모두 상대해도 되나요?

가능하다. 굳이 en-US, en-GB로 나누지 않고 지역 구분 없는 en 하나로도 충분하다. 실제로 표현 차이(스펠링, 통화 단위 등)를 크게 신경 쓸 정도의 사업이 아니라면, 언어코드만 쓰는 쪽이 관리도 간단하고 실수도 줄어든다. 지역별로 가격·법률·프로모션이 크게 다른 경우에만 지역코드를 세분화하는 것을 권한다.

이미 운영 중인 사이트에 hreflang을 나중에 추가해도 되나요?

언제 추가해도 상관없다. hreflang은 처음부터 설계에 넣어야만 효과가 있는 태그가 아니라, 다국어 페이지가 존재하는 한 언제든 추가하면 바로 적용된다. 다만 페이지 수가 많다면 HTML 링크 태그를 페이지마다 일일이 넣는 대신, 앞서 소개한 XML 사이트맵 방식으로 한 번에 관리하는 편이 실수를 줄인다.

네이버에서도 hreflang이 똑같이 통하나요?

네이버 자체 검색(블로그·카페 등)에는 해당하지 않는다. hreflang은 구글이 처음 제안하고 주요 검색엔진들이 따르는 국제 표준으로, 자체 도메인으로 운영하는 홈페이지의 구글·빙 노출에 효과가 있다. 네이버 통합검색에서 다국어 홈페이지가 어떻게 다뤄지는지는 별도로 확인이 필요하며, 국내 고객이 중심이라면 hreflang보다 네이버 SEO 기본기(등록, 콘텐츠 최적화)를 먼저 챙기는 것이 우선이다.

마무리: 지도를 정확히 그려야 손님이 길을 잃지 않는다

다국어 홈페이지를 만드는 이유는 결국 하나다. 자기 나라 말로 편하게 둘러보고, 편하게 문의하게 하려는 것이다. 그런데 hreflang이 빠지거나 틀리면, 정작 그 언어를 쓰는 손님에게 엉뚱한 언어 페이지가 먼저 보이는 역설이 생긴다.

다행히 hreflang은 한 번 제대로 이해하고 나면 반복 작업이다. 자기 참조, 리턴 태그, 정확한 코드, 완전한 URL 이 네 가지만 지켜도 대부분의 오류는 사라진다. 오늘 글에서 정리한 체크리스트를 인쇄해 두고, 새 언어 버전을 추가할 때마다 하나씩 대조해 보는 것을 권한다.

여기에 언어별 키워드 리서치와 현지화까지 더하면, 다국어 홈페이지는 단순히 "번역본이 있는 사이트"에서 "그 나라 손님이 검색해서 찾아오고, 편하게 읽고, 실제로 문의까지 남기는 사이트"로 한 단계 올라선다. hreflang은 그 여정의 첫 관문일 뿐이지만, 이 관문을 놓치면 나머지 노력이 전혀 빛을 보지 못한다는 점을 기억해 두자.

해외 진출을 준비하고 있다면, 홈페이지의 코드 한 줄이 첫인상을 좌우한다는 사실을 기억해 두면 좋다. 이루웹은 해외 진출을 준비하는 기업과 다국어 쇼핑몰의 홈페이지를 검색과 AI에 잘 잡히는 구조로 설계하고, hreflang 같은 국제 SEO 세팅부터 canonical 태그·사이트맵 정리까지 함께 챙겨드리고 있습니다. 다국어 홈페이지를 새로 준비 중이거나, 이미 운영 중인 사이트의 hreflang이 제대로 걸려 있는지 궁금하시다면 SEO 홈페이지 제작 서비스를 살펴보시고, 무료 상담으로 현재 상태를 점검받아 보시길 권해 드립니다. 손님의 언어로 정확히 말을 거는 홈페이지, 이루웹이 함께 만들어 가겠습니다.

검색되는 사이트가 필요하신가요?

이 글의 원칙을 그대로 적용해 사이트를 만듭니다. 상담은 무료입니다.

무료 상담 신청