Published on

GEO를 위한 다국어 사이트 설계: URL·hreflang·canonical

Authors
  • 테크버킷
    Name
    테크버킷
    Twitter

목차

다국어 사이트에서 한국어와 영어 본문을 같은 URL에 번갈아 보여주면 검색엔진과 AI 시스템은 어떤 언어의 문서를 발견하고 인용해야 하는지 안정적으로 판단하기 어렵습니다. 언어마다 고유 URL을 만들고, 각 페이지가 자신을 canonical로 가리키며, hreflang으로 대응 관계를 알리는 구조가 기본입니다.

이 설정이 AI 인용을 직접 보장하지는 않습니다. 다만 언어별 콘텐츠가 고유한 주소에서 크롤링·색인되고, 사용자가 선택한 언어로 연결되며, 분석에서도 구분되는 기반을 만듭니다. GEO에서도 별도의 특수 마크업보다 이 기본기가 먼저입니다.

같은 URL에서 언어만 바꾸면 무엇이 문제일까?

예를 들어 /pricing 한 주소에서 브라우저 설정에 따라 한국어 또는 영어를 보여준다고 가정해봅니다. URL만 봐서는 두 문서를 구분할 수 없고, 크롤러가 접속한 조건에 따라 한 언어만 발견할 수 있습니다. 사용자가 공유한 링크도 상대방 환경에서 다른 언어로 열릴 수 있습니다.

분석도 모호해집니다. Search Console과 GA4에서 /pricing의 성과는 보이지만 한국어·영어 중 어느 콘텐츠가 노출과 전환을 만들었는지 분리하기 어렵습니다. AI 답변에서 영어 페이지를 인용했는지 한국어 페이지를 인용했는지 재현하는 일도 힘들어집니다.

언어별 URL은 이 문제를 다음과 같이 바꿉니다.

구분같은 URL에서 언어 전환언어별 고유 URL
공유환경에 따라 다른 언어가 열릴 수 있음링크의 언어가 유지됨
크롤링크롤러 조건에 따라 한 언어를 놓칠 수 있음각 언어를 독립적으로 발견 가능
색인언어 버전의 경계가 불명확함언어별 문서와 canonical이 명확함
측정언어별 노출·유입 분리가 어려움URL 경로로 분리 가능
유지관리숨은 분기와 자동 전환에 의존대응 URL을 테스트할 수 있음

다국어 URL 구조는 무엇을 선택할까?

대표적인 선택지는 국가 코드 도메인, 서브도메인, 서브디렉터리입니다.

방식예시적합한 경우주의점
국가 코드 도메인example.kr, example.com국가별 사업·브랜드·운영이 크게 다를 때도메인별 권한과 운영을 따로 관리
서브도메인ko.example.com언어별 앱이나 인프라를 분리할 때분석·배포·사이트 신호가 분산될 수 있음
서브디렉터리example.com/ko/, /en/같은 제품과 브랜드의 언어 버전일 때경로 규칙과 번역 대응 관계를 일관되게 유지

같은 제품을 한국어와 영어로 제공한다면 /ko/, /en/ 같은 서브디렉터리가 대체로 단순합니다. 모든 언어가 같은 도메인의 신뢰와 기술 기반을 공유하고, 배포와 측정도 한곳에서 관리할 수 있습니다.

쿼리 파라미터 방식인 ?lang=ko는 주소가 쉽게 중복되고 내부 링크, canonical, 캐시 정책이 복잡해질 수 있어 핵심 공개 콘텐츠의 기본 구조로는 권하지 않습니다.

/ko와 /en으로 전환한 실제 사례

Weplet은 처음에 같은 URL에서 한국어와 영어 본문을 전환했습니다. 이후 같은 제품의 언어 버전이라는 점을 기준으로 서브디렉터리 구조를 선택하고, 명시적인 /ko와 /en URL을 만들었습니다.

구현에서 중요했던 결정은 단순히 경로를 추가하는 것보다 사용자가 고른 언어를 덮어쓰지 않는 것이었습니다.

  • /ko/...와 /en/...으로 들어온 요청은 자동으로 다른 언어로 보내지 않는다.
  • 언어 전환 버튼은 현재 페이지와 대응하는 다른 언어 URL로 이동한다.
  • 루트 /처럼 언어가 없는 주소에서만 언어 선택 정책을 적용한다.
  • 루트의 판단 순서는 저장된 사용자 선택, 브라우저 Accept-Language, 기본 언어 순으로 둔다.
  • 대응 번역이 없다면 홈페이지로 보내지 말고 명시한 fallback 정책을 적용한다.

이 방식은 크롤러가 명시적인 언어 URL을 그대로 방문할 수 있게 하고, 사용자가 검색 결과에서 고른 언어도 보존합니다. 언어 경로를 분리한 뒤에는 각 URL의 색인 상태와 실제 랜딩페이지를 언어별로 확인해 전환 전후의 차이를 비교할 수 있습니다.

hreflang은 어떻게 연결할까?

hreflang은 같은 내용의 언어·지역별 URL 관계를 검색엔진에 알립니다. 한국어와 영어 페이지가 서로를 가리키고, 각 페이지도 자기 자신을 포함해야 합니다.

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

영어 페이지에도 같은 세 줄이 있어야 양방향 관계가 완성됩니다. 한쪽만 상대를 가리키는 연결은 누락으로 처리될 수 있습니다.

지역까지 구분할 필요가 있을 때만 ko-KR, en-US처럼 언어-지역 코드를 사용합니다. 단순히 한국어와 영어를 나누는 사이트라면 ko, en으로 시작하는 편이 관리하기 쉽습니다. x-default는 특정 언어·지역에 해당하지 않는 사용자를 위한 기본 URL을 뜻하며 필수는 아니지만 언어 선택 페이지나 기본 언어 URL을 명시할 때 유용합니다.

canonical은 언어마다 자기 자신을 가리킨다

한국어 페이지와 영어 페이지가 각각 번역된 독립 문서라면 두 페이지 모두 자기 URL을 canonical로 선언합니다.

<!-- /ko/pricing -->
<link rel="canonical" href="https://example.com/ko/pricing" />

<!-- /en/pricing -->
<link rel="canonical" href="https://example.com/en/pricing" />

한국어 페이지의 canonical을 영어 페이지로 통일하면 검색엔진에 한국어 URL보다 영어 URL을 대표로 선택해달라는 상충된 신호를 줄 수 있습니다. 언어 대응은 hreflang, 중복 URL의 대표 선택은 canonical로 역할을 나눕니다.

각 문서의 <html lang="ko">, <html lang="en">도 실제 본문 언어와 맞춥니다. lang은 화면 읽기 도구와 브라우저가 발음·번역을 판단하는 데 도움을 주며, hreflang을 대신하지는 않습니다.

리디렉션은 어디까지 자동화할까?

IP나 브라우저 언어만으로 모든 요청을 자동 리디렉션하면 사용자와 크롤러가 다른 언어 버전을 열기 어려워질 수 있습니다. 특히 명시적인 /en/... 요청을 한국 IP라는 이유로 /ko/...로 바꾸면 검색 결과의 링크와 사용자의 선택이 무시됩니다.

안전한 원칙은 다음과 같습니다.

  1. 언어가 들어간 URL은 그대로 제공한다.
  2. 루트나 언어 없는 경로에서만 언어를 추천하거나 선택한다.
  3. 사용자가 전환한 언어를 브라우저 설정보다 우선한다.
  4. 언어 선택기를 크롤링 가능한 일반 링크로 제공한다.
  5. 어떤 언어에서도 다른 모든 언어 버전에 접근할 수 있게 한다.

자동 판단이 필요하더라도 영구 리디렉션을 성급하게 사용하지 않습니다. 기본 언어와 URL 정책이 바뀔 가능성, 캐시가 사용자별 응답을 섞을 가능성, 봇이 한 언어에 갇히는 문제를 함께 테스트합니다.

사이트맵과 내부 링크는 어떻게 구성할까?

사이트맵에는 색인시키려는 canonical URL만 넣습니다. 작은 사이트는 하나의 사이트맵에 /ko/와 /en/을 함께 넣어도 되고, 운영상 분리가 필요하면 sitemap-ko.xml, sitemap-en.xml을 만든 뒤 사이트맵 인덱스로 묶을 수 있습니다.

분리 자체가 순위를 높이지는 않습니다. 언어별 색인 문제를 진단하고 제출 상태를 관리하기 쉬운지가 기준입니다. 어떤 방식을 택하든 다음을 확인합니다.

  • 사이트맵의 URL이 200으로 응답한다.
  • 각 URL의 canonical이 사이트맵 URL과 일치한다.
  • 대응하는 언어 페이지가 실제로 존재한다.
  • 언어 전환 링크가 JavaScript 없이도 발견 가능한 <a href>이다.
  • 내부 링크가 리디렉션 주소를 거치지 않고 최종 언어 URL로 바로 연결된다.

GEO 관점에서 무엇을 측정할까?

다국어 전환 뒤에는 “색인이 늘었다”만 보지 않습니다. 언어와 시장별로 발견, 인용, 방문, 전환을 분리합니다.

단계확인할 항목
발견언어별 색인 URL 수, Search Console 검색어와 노출
정확성올바른 언어 URL이 검색 결과와 AI 답변에 선택되는지
인용같은 질문을 한국어·영어로 측정했을 때 인용 URL과 문맥
유입/ko/, /en/ 랜딩페이지별 AI 추천 세션과 참여
전환언어별 가입·문의·구매와 이탈 지점

한국어 질문에서 영어 URL이 계속 인용된다면 한국어 페이지의 품질만 문제가 아닐 수 있습니다. hreflang의 상호 연결, self-canonical, 사이트맵, 내부 링크, 번역 페이지의 색인 상태를 함께 확인합니다.

배포 전에 확인할 테스트

  • 한국어와 영어 콘텐츠에 각각 고유한 URL이 있다.
  • 명시적인 언어 URL을 자동으로 다른 언어로 보내지 않는다.
  • 언어 전환 후에도 현재 페이지의 맥락이 유지된다.
  • 각 페이지의 html lang이 본문 언어와 일치한다.
  • 각 언어 페이지가 self-canonical을 사용한다.
  • hreflang이 자기 자신과 모든 대응 언어를 양방향으로 연결한다.
  • x-default가 의도한 기본 URL을 가리킨다.
  • 사이트맵에는 최종 canonical URL만 포함된다.
  • 존재하지 않는 번역 URL의 fallback이 정해져 있다.
  • Search Console과 GA4에서 언어별 결과를 분리할 수 있다.

다국어 GEO의 목표는 번역 페이지 수를 늘리는 것이 아닙니다. 각 언어의 사용자가 같은 주제를 자기 언어의 안정적인 URL에서 찾고, 검색엔진과 AI 시스템이 그 대응 관계를 오해 없이 발견하도록 만드는 것입니다.

다음 글

참고 자료