해외 SEO 시작 기준 · hreflang 설정과 도메인 구조 선택
한국어 사이트를 번역만 해서 올린다고 해외 검색에 잡히는 것은 아니다. 도메인 구조를 정하는 기준과 hreflang의 자기 참조·상호 참조 규칙, 그리고 canonical과 충돌해 영어판이 아예 색인되지 않는 경우까지 함께 정리했다.
해외 SEO는 한국어 사이트를 영어로 번역해서 올리는 일이 아니다. 검색 엔진에 "이 페이지의 다른 언어판이 여기 있다"고 알려주는 구조를 먼저 만들고, 그다음에 각 언어의 검색어에 맞는 내용을 채우는 일이다. 순서를 바꾸면 번역은 다 해놓고 어느 쪽도 제대로 노출되지 않는 상태가 된다.
이 글은 그 구조를 다룬다. 도메인을 어떻게 나눌지, hreflang을 어떻게 쓰는지, 그리고 자주 틀리는 지점을 정리한다.
번역만으로 안 되는 이유
같은 내용의 페이지가 두 언어로 존재하면 검색 엔진은 두 가지를 판단해야 한다. 이 둘이 같은 페이지의 다른 버전인가, 아니면 서로 다른 페이지인가. 그리고 검색한 사람에게 어느 쪽을 보여줄 것인가.
알려주지 않으면 엔진이 알아서 정한다. 그 결과가 대개 이렇다.
한쪽만 색인되고 다른 쪽은 중복으로 취급된다. 한국어 검색자에게 영어 페이지가 나온다. 두 페이지가 같은 검색어로 서로 경쟁한다.
hreflang은 이 판단을 대신 알려주는 태그다. 순위를 올리는 장치가 아니라 어느 버전을 누구에게 보여줄지 정리하는 장치다.
도메인 구조를 먼저 정한다
hreflang을 쓰기 전에 주소 구조를 정해야 한다. 나중에 바꾸면 전부 다시 해야 한다.
| 구조 | 예시 | 장점 | 단점 |
|---|---|---|---|
| 서브디렉터리 | example.com/en/ | 도메인 평가가 합쳐진다 | 지역 타기팅이 약하다 |
| 서브도메인 | en.example.com | 분리 운영이 쉽다 | 평가가 나뉠 수 있다 |
| 국가 도메인 | example.co.kr | 지역 신호가 가장 강하다 | 도메인마다 처음부터 쌓아야 한다 |
| 파라미터 | example.com?lang=en | — | 권장되지 않는다 |
대부분의 경우 서브디렉터리가 무난하다. 하나의 도메인에 쌓인 평가를 언어판이 함께 쓰고, 관리도 한 곳에서 된다. 국가별 법인이 따로 있고 각 시장에서 독립적으로 운영하는 경우가 아니라면 도메인을 나눌 이유가 크지 않다.
파라미터 방식은 피한다. 같은 주소로 내용이 바뀌므로 각 언어판이 별도 페이지로 잡히지 않고, hreflang을 걸 대상 주소 자체가 명확하지 않아진다. 이미 그 구조라면 언어판을 나누는 것이 첫 작업이다.
hreflang은 어떻게 쓰나
각 페이지의 <head>에 그 페이지의 모든 언어판을 나열한다. 형식은 이렇다.
<link rel="alternate" hreflang="ko" href="https://example.com/ko/page" />
<link rel="alternate" hreflang="en" href="https://example.com/en/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/ko/page" />
여기서 규칙이 셋이다.
자기 자신을 포함한다. 한국어 페이지에도 한국어 링크가 들어가야 한다. 빠지면 전체가 무시된다.
상호 참조해야 한다. A가 B를 가리키면 B도 A를 가리켜야 한다. 한쪽만 있으면 인정되지 않는다.
절대 주소를 쓴다. https://부터 전부 적는다. 상대 경로는 인식되지 않는다.
x-default는 어느 언어에도 해당하지 않는 방문자에게 보여줄 기본값이다. 언어 선택 페이지가 있다면 그것을, 없다면 주력 언어판을 지정한다. 필수 항목은 아니지만 넣어두는 편이 낫다.
언어 코드와 지역 코드를 구분한다
가장 흔한 실수가 여기서 나온다.
hreflang="en"은 모든 영어 사용자를 뜻한다. hreflang="en-US"는 미국의 영어 사용자다. 뒤쪽 코드는 국가이지 언어가 아니다.
그래서 en-UK는 틀린 값이다. 영국의 국가 코드는 GB이므로 en-GB가 맞다. 이런 오타는 조용히 무시되므로 설정했다고 생각하는 채로 작동하지 않는다.
자주 쓰는 조합을 정리하면 이렇다.
| 값 | 뜻 | 언제 쓰나 |
|---|---|---|
ko | 한국어 사용자 전체 | 기본값으로 충분한 경우 |
en | 영어 사용자 전체 | 국가별 내용 차이가 없을 때 |
en-US | 미국의 영어 사용자 | 가격·배송이 미국 전용일 때 |
en-GB | 영국의 영어 사용자 | en-UK는 틀린 값 |
ja | 일본어 사용자 | — |
zh-Hans | 간체 중국어 | 대만·홍콩은 zh-Hant |
x-default | 해당 없음 | 언어 선택 페이지 또는 주력 언어 |
중국어는 국가가 아니라 문자로 나뉜다는 점이 다르다. zh-CN도 동작하지만 문자 기준인 zh-Hans·zh-Hant가 실제 사용자 구분에 더 맞는다.
지역을 나눌 이유가 없으면 언어 코드만 쓴다. 미국과 영국에 같은 영어 페이지를 보여줄 것이라면 en 하나면 충분하고, 나누면 관리할 조합만 늘어난다. 가격이나 배송처럼 국가별로 실제 내용이 다를 때만 지역을 붙인다.
canonical과 함께 쓸 때 주의할 것
두 태그의 역할이 다르다. hreflang은 언어판을 연결하고, canonical은 중복 중 대표를 지정한다.
각 언어판의 canonical은 자기 자신을 가리켜야 한다. 영어 페이지의 canonical이 한국어 페이지를 가리키면, 그건 "영어 페이지는 한국어 페이지의 사본이니 색인하지 말라"는 뜻이 된다. hreflang으로 연결해 놓고 canonical로 지워버리는 셈이다.
이 조합은 실제로 자주 나온다. 다국어 플러그인이 기본값으로 원본 언어를 canonical에 넣는 경우가 있어, 설치 후 확인이 필요하다.
자주 틀리는 지점
| 증상 | 원인 | 확인 방법 |
|---|---|---|
| hreflang이 무시됨 | 자기 참조 누락 | 페이지 소스에서 자기 언어 태그 확인 |
| 일부만 인정됨 | 상호 참조 안 됨 | 상대 페이지에서 역방향 링크 확인 |
| 오류 목록에 뜸 | 지역 코드 오타 (en-UK 등) | ISO 코드 대조 |
| 영어판이 색인 안 됨 | canonical이 한국어를 가리킴 | 각 페이지 canonical 확인 |
| 리디렉션으로 언어 강제 | IP 기반 자동 전환 | 크롤러가 한 언어만 보게 된다 |
| 번역 페이지가 중복 처리 | hreflang 자체가 없음 | head 태그 확인 |
마지막에서 두 번째가 특히 문제다. 방문자의 IP를 보고 자동으로 언어를 바꾸면, 크롤러는 자기 IP에 해당하는 한 언어만 보게 되어 나머지 언어판을 발견하지 못한다. 자동 전환 대신 언어 선택을 제안하고 사용자가 고르게 하는 편이 안전하다.
영어권 검색어는 다르게 생겼다
구조를 갖췄다면 다음은 내용이다. 여기서 번역의 한계가 드러난다.
한국어 검색어를 그대로 옮긴 표현은 영어권에서 아무도 쓰지 않는 경우가 많다. "블로그 대행"을 직역하면 blog agency지만, 실제로 검색되는 것은 content marketing agency나 blog writing service 쪽이다. 어느 쪽이 쓰이는지는 짐작이 아니라 측정으로 확인해야 한다.
검색 의도의 분포도 다르다. 같은 주제라도 한국에서는 "방법"을 찾는 검색이 많은데 영어권에서는 "도구 비교"가 많은 식이다. SERP를 열어보면 어느 쪽인지 바로 보인다.
그래서 영어판은 번역이 아니라 별도 기획이 되는 경우가 많다. 한국어 글 목록을 그대로 옮기는 대신, 영어권에서 실제로 검색되는 주제부터 골라 몇 편으로 시작하는 편이 낫다.
어디까지 번역할 것인가
전부 번역할 필요가 없다. 유지 비용이 언어 수만큼 늘어나기 때문이다.
먼저 옮길 것은 제품·서비스 설명, 회사 소개, 문의 경로다. 검색으로 들어오지 않더라도 링크를 타고 온 사람이 반드시 보는 페이지다.
나중에 봐도 되는 것은 블로그 아카이브 전체다. 한국 시장 맥락에 특화된 글은 옮겨도 영어권에서 검색되지 않는다.
아예 옮기지 않아도 되는 것은 국내 규제나 국내 플랫폼만 다루는 글이다. 번역해 두면 관리 대상만 늘고 아무도 읽지 않는다. 네이버나 카카오를 전제로 쓴 글이 대표적인데, 그 맥락 자체가 영어권 독자에게 전달되지 않는다.
부분 번역이라도 hreflang은 문제가 없다. 번역된 페이지끼리만 연결하고, 없는 언어는 그냥 태그에서 빼면 된다.
어떤 순서로 하나
한꺼번에 하면 무엇이 문제인지 알 수 없다. 앞 단계가 확인된 뒤 다음으로 넘어간다.
| 순서 | 할 일 | 확인 |
|---|---|---|
| 1 | 도메인 구조 결정 | 나중에 바꾸면 전부 다시 해야 한다 |
| 2 | 핵심 페이지 몇 개만 번역 | 제품·회사 소개·문의 |
| 3 | hreflang + canonical 설정 | 자기 참조와 상호 참조 확인 |
| 4 | 자동 언어 전환 해제 | 크롤러가 모든 언어판을 보게 |
| 5 | 색인 확인 (4주) | 안 되면 여기서 멈추고 원인 해결 |
| 6 | 영어권 검색어 조사 | 번역이 아니라 별도 기획 |
| 7 | 콘텐츠 추가 | 5번이 통과한 뒤에 |
5번이 관문이다. 색인이 안 되는 상태에서 글을 더 쓰면 늘어나는 것은 관리 대상뿐이다. 색인 자체가 처음부터 안 잡히는 경우의 확인 순서는 구글 검색 등록 방법에 정리했다. 대부분의 문제가 3번과 4번에서 나오므로, 색인이 안 되면 그 두 단계를 다시 본다.
Search Console에서 무엇을 확인하나
설정한 뒤 실제로 인식되는지 확인해야 한다. 태그를 넣었다고 적용되는 것이 아니다.
색인 상태. 각 언어판이 개별적으로 색인되어 있는지 본다. 한쪽만 색인되어 있다면 canonical이나 hreflang 문제다.
국가별 성과. 실적 보고서를 국가 기준으로 나눠 보면 어느 시장에서 노출이 나오는지 보인다. 영어판을 만들었는데 국내에서만 노출된다면 아직 그 시장에 잡히지 않은 것이다.
URL 검사. 개별 영어 페이지가 어떤 상태로 색인됐는지, 구글이 선택한 canonical이 무엇인지 직접 확인할 수 있다. 우리 의도와 다르면 그 자리에서 드러난다.
얼마나 걸리나
새 언어판이 검색에 자리 잡는 데는 국내 사이트를 새로 시작하는 것과 비슷한 시간이 든다. 기존 도메인의 평가를 일부 이어받지만, 그 시장에서의 이력은 처음부터 쌓인다.
기술 설정이 반영되는 것은 빠르다. hreflang과 canonical을 고치면 며칠에서 몇 주 안에 색인 상태가 바뀐다. 반면 새 언어권에서 순위가 오르는 것은 몇 개월 단위다.
그래서 판단 시점을 나눠 잡는다. 4주 시점에는 색인 여부를, 3개월 시점에는 노출 발생 여부를 본다. 4주에 색인이 안 됐다면 설정 문제이므로 콘텐츠를 더 만들기 전에 그것부터 고쳐야 한다. 3개월에 색인은 됐는데 노출이 0이라면 그때는 설정이 아니라 주제 선택을 다시 봐야 한다.
유지 비용을 먼저 계산한다
언어를 하나 늘리면 이후의 모든 작업이 그만큼 늘어난다. 시작 비용보다 이쪽이 크다.
가격이 바뀌면 두 페이지를 고쳐야 한다. 제품이 추가되면 두 번 쓴다. 문의가 영어로 오면 영어로 답할 사람이 있어야 하고, 없으면 응답이 늦어져 그 유입 자체가 낭비된다.
그래서 시작 전에 확인할 것이 있다. 영어 문의를 받을 준비가 되어 있는가. 페이지는 만들었는데 문의에 답을 못 하는 상태가 가장 나쁘다. 검색 노출까지 성공했는데 그 지점에서 끊긴다.
한 언어로 좁게 시작하는 편이 낫다. 세 언어를 얕게 하는 것보다 영어 하나를 제대로 하는 쪽이 관리도 되고 결과도 낫다.
자주 묻는 질문
hreflang을 넣으면 순위가 오르나요?
오르지 않습니다. hreflang은 어느 언어판을 누구에게 보여줄지 정리하는 태그이지 순위 요소가 아닙니다. 다만 잘못 설정하면 의도한 페이지가 노출되지 않으므로, 순위를 올리는 장치가 아니라 방해를 없애는 장치로 보는 편이 맞습니다.
영어 페이지가 색인되지 않습니다
먼저 canonical을 확인하세요. 다국어 플러그인이 영어 페이지의 canonical을 한국어 원본으로 넣어두는 경우가 흔하고, 그 상태면 색인되지 않습니다. 각 언어판의 canonical은 자기 자신을 가리켜야 합니다.
자동으로 언어를 바꿔주는 것이 편하지 않나요?
사용자에게는 편하지만 크롤러에게는 문제가 됩니다. IP로 자동 전환하면 크롤러가 한 언어판만 보게 되어 나머지가 발견되지 않습니다. 감지해서 배너로 제안하고 선택은 사용자가 하게 하는 방식이 안전합니다.
번역 품질이 순위에 영향을 주나요?
기계 번역을 그대로 올려 읽기 어려운 문장이 되면 영향이 있습니다. 검색 엔진은 생성 방식이 아니라 결과물이 사람에게 유용한지를 봅니다. 초안을 기계 번역으로 만들더라도 그 언어를 아는 사람이 다듬는 절차는 필요합니다.
언어를 몇 개까지 늘려도 되나요?
기술적 상한은 없지만 유지 비용이 언어 수만큼 곱해집니다. 가격이나 제품이 바뀔 때마다 모든 언어판을 고쳐야 하고, 각 언어로 오는 문의에 답할 수 있어야 합니다. 세 언어를 얕게 운영하는 것보다 하나를 제대로 하는 편이 대개 낫습니다.
한국어와 영어 페이지가 서로 경쟁하지 않나요?
hreflang이 제대로 설정되어 있으면 경쟁하지 않습니다. 검색 엔진이 사용자의 언어 설정에 맞는 쪽을 골라 보여주기 때문입니다. 경쟁이 일어난다면 대개 hreflang이 없거나 상호 참조가 끊긴 상태입니다.
참고 자료
- 현지화된 페이지 버전 알리기 — Google 검색 센터 — hreflang의 자기 참조·상호 참조 규칙과 x-default 사용법에 대한 공식 문서.
- 다지역 및 다국어 사이트 관리 — Google 검색 센터 — 도메인 구조 선택과 지역 타기팅에 대한 공식 문서.