SEO 가이드 10단계: 다국어 SEO

이것은 13단계 SEO 가이드의 10단계입니다. 다국어 SEO는 모든 시장에 그들의 언어로 콘텐츠를 제공함으로써 유기적 트래픽을 곱할 수 있게 해줍니다. 잘못하면 중복 콘텐츠 혼란을 초래합니다.

추가하는 각 언어는 기존 콘텐츠에 곱셈 효과를 줍니다. 한 언어로 50개의 페이지가 있는 사이트는 50개의 인덱스 가능한 URL을 가집니다. 5개 언어를 추가하면 250개가 되고, 20개 언어를 추가하면 1,000개가 됩니다. 이 URL들 각각은 지역 Google 결과에서 독립적으로 순위에 오를 수 있습니다.

하지만 다국어 SEO는 SEO의 가장 기술적으로 복잡한 영역 중 하나입니다. 잘못된 구현은 중복 콘텐츠, 순위 희석 및 크롤링 예산 낭비를 초래합니다. 올바르게 국제화된 사이트와 잘못된 사이트의 차이는 10배의 트래픽 차이가 날 수 있습니다.

LANGR 자체는 89개의 활성 로케일에서 108개 언어로 운영됩니다. 우리는 이러한 문제를 대규모로 해결했습니다. 이 가이드는 우리가 배운 모든 것을 공유합니다.

다국어 SEO가 포함하는 것

다국어 SEO는 8개의 중요한 영역으로 구분됩니다:

Hreflang 구현 — Google에 각 페이지가 어떤 언어를 제공하는지 알리기
로케일 라우팅 전략 — 서브도메인 vs 서브폴더 vs TLD
번역 품질 — 기계 번역 vs 인간 번역 vs 하이브리드 번역
국제 타겟팅 — 서치 콘솔 설정
콘텐츠 현지화 — 번역을 넘어서: 문화적 적응
RTL 지원 — 우에서 좌로 읽는 언어(아랍어, 히브리어, 페르시아어)
언어 감지 — 올바른 버전을 자동으로 제공
중복 콘텐츠 — 언어 간 상충 방지

1. Hreflang 구현

Hreflang 태그는 검색 엔진에게 어떤 URL이 어떤 언어와 지역을 제공하는지를 알려줍니다. 그것들은 다국어 SEO의 기술적인 기초이며 가장 일반적으로 잘못 구성되는 요소입니다.

기본 hreflang 구문:

<link rel="alternate" hreflang="en" href="https://example.com/page" />
<link rel="alternate" hreflang="da" href="https://example.com/da/page" />
<link rel="alternate" hreflang="de" href="https://example.com/de/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />

중요 규칙:

모든 페이지는 모든 대체 버전을 참조해야 합니다(자기 자신 포함)
x-default는 기본값을 지정합니다(보통 영어 또는 언어 선택기)
Hreflang 태그는 상호 참조해야 합니다(페이지 A가 B를 링크하면 B도 A로 링크해야 함)
국가 코드가 아닌 ISO 639-1 언어 코드를 사용해야 합니다(en, da, de)
지역 특정 콘텐츠의 경우: en-us, en-gb, pt-br (언어-지역)
페이지당 최대 ~50개의 hreflang 항목(성능 제한)

세 가지 배치 옵션:

| 방법 | 최적 대상 | 단점 | |--------|----------|-----------| | in | 소규모 사이트 (< 10 언어) | HTML 부풀림, 느린 파싱 | | HTTP 헤더 | 비HTML 파일 (PDF, API) | 널리 지원되지 않음 | | XML 사이트맵 | 대규모 사이트 (10개 이상의 언어) | 크롤러에 의한 느린 발견 |

사이트맵 hreflang 예시:

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

일반적인 hreflang 오류:

자기 참조 태그가 없음 (페이지가 자기 자신을 포함하지 않음)
비상호 참조 태그 (A가 B를 참조하는데 B는 A를 참조하지 않음)
잘못된 언어 코드 (dk 대신 da 사용)
비200 URL을 가리킴 (리디렉션, 404)
언어 특정 페이지와 함께 x-default 혼합

빠른 승리: 사이트를 크롤링하고 모든 hreflang 태그를 내보내세요. 비상호 관계를 확인하세요 — 이는 가장 일반적인 오류이며 Google이 전체 hreflang 설정을 무시하게 만듭니다.

2. 로케일 라우팅 전략

다양한 언어에 대한 URL 구조는 SEO, 사용자 경험 및 기술적 복잡성에 영향을 미칩니다. 주요 접근 방식에는 세 가지가 있습니다:

서브폴더 (권장)

example.com/en/page
example.com/da/page
example.com/de/page

장점: 단일 도메인 권한, 관리 용이, SSL 인증서 하나, 분석 속성 하나, 서치 콘솔 속성 하나, 대부분의 사이트에 최적.

단점: ccTLD보다 지리적 타겟팅 신호가 적습니다.

서브도메인

en.example.com/page
da.example.com/page
de.example.com/page

장점: 각 지역에 따라 다른 서버/CDN에서 호스팅할 수 있으며, 별도의 크롤링 예산.

단점: 각 서브도메인은 별도로 권한을 구축하며 (링크 자산이 자동으로 흐르지 않음), 여러 서치 콘솔 속성이 필요하며, 설정이 더 복잡합니다.

국가 코드 TLD (ccTLD)

example.com (영어)
example.dk (덴마크어)
example.de (독일어)

장점: 가장 강력한 지리적 타겟팅 신호, 사용자가 현지 TLD를 신뢰, 각 도메인이 독립적입니다.

단점: 비쌈 (20개 이상의 도메인 구매), 각 도메인에 대한 별도의 권한, 복잡한 링크 구축, 분석/콘솔 분리.

우리의 추천: 서브폴더 라우팅은 90%의 사이트에 최적입니다. 이는 단일 도메인에서 모든 링크 권한을 집중시키면서 명확한 로케일 신호를 제공합니다. /{locale}/page 형식을 사용하세요.

https://langr.org/page        (영어, 기본값)
https://langr.org/da/page     (덴마크어)
https://langr.org/de/page     (독일어)
https://langr.org/ja/page     (일본어)

빠른 승리: 서브도메인을 사용하고 권한 문제로 어려움을 겪고 있다면 서브폴더로 마이그레이션을 고려하세요. 서브도메인에서 서브폴더로 마이그레이션하는 사이트는 일반적으로 링크 자산이 통합되면서 3-6개월 이내에 20-50%의 유기적 트래픽 증가를 경험합니다.

3. 번역 품질 vs 기계 번역

번역 품질은 순위에 직접적인 영향을 미칩니다. Google은 기계 번역을 감지할 수 있으며 잘못 번역된 페이지의 가치를 낮출 수 있습니다. 그러나 2026년의 AI 번역은 2020년의 규칙과는 비교할 수 없을 만큼 개선되었습니다.

번역 품질 스펙트럼:

| 수준 | 방법 | 품질 | 비용 | 최적 대상 | |-------|--------|---------|------|----------| | 1 | 원시 GPT/DeepL 출력 | 60-75% | ~$0 | 내부 사용, 초안 | | 2 | AI + 후 편집 프롬프트 | 75-90% | ~$0 | 블로그 콘텐츠, 비핵심 페이지 | | 3 | AI + 인간 검토 | 90-97% | $0.03-0.08/단어 | 제품 페이지, 주요 랜딩 페이지 | | 4 | 전문 원어민 번역가 | 97-100% | $0.10-0.25/단어 | 법률, 의료, 브랜드 필수 |

2026년 주요 통찰: 레벨 2(질 높은 프롬프트를 갖춘 AI)는 이제 대부분의 웹 콘텐츠에 충분합니다. Google의 중복 콘텐츠 알고리즘은 잘 된 기계 번역을 더 이상 처벌하지 않습니다 — 그들이 처벌하는 것은 가치를 제공하지 않는 잘못된 번역입니다.

SEO에 해로운 번역의 징후:

번역된 콘텐츠와 섞인 번역되지 않은 섹션
여전히 소스 언어에 있는 UI 요소 (버튼, 레이블)
지역 특정 포맷이 적응되지 않음 (날짜, 통화, 전화번호)
번역되지 않는 문화적 참조 (관용구, 농담, 예시)
모든 언어에 동일한 메타 제목/설명

번역 품질 검증 방법:

모든 가시 텍스트가 번역되었는지 확인 (내비게이션, 하단 정보, 양식 포함)
지역 특정 포맷 검증 (DD/MM/YYYY vs MM/DD/YYYY)
CTA 테스트 — 목표 언어에서 자연스럽게 들리나요?
메타 태그 확인 — 제목과 설명은 각 언어마다 독립적으로 작성되어야 합니다.
원시 i18n 키가 노출되지 않도록 확인 (예: "Home" 대신 nav.home)

빠른 승리: 번역된 페이지에서 혼합 언어 콘텐츠를 확인하세요. 어떤 버튼, 레이블 또는 UI 요소가 여전히 소스 언어에 있다면 즉시 수정하세요 — 혼합 언어 페이지는 Google에게 낮은 품질을 신호로 보냅니다.

4. 서치 콘솔의 국제 타겟팅

Google 서치 콘솔의 국제 타겟팅 설정은 Google이 어떤 페이지가 어떤 국가에서 순위가 매겨져야 하는지를 이해하는 데 도움을 줍니다.

서브폴더 설정의 경우:

서브폴더당 국가 타겟팅을 설정할 수 없습니다 (도메인/서브도메인당만)
대신, hreflang + 콘텐츠 언어 + 사용자 신호에 의존하세요
지역별 사이트맵 제출: sitemap-en.xml, sitemap-da.xml

ccTLD의 경우:

.dk는 자동으로 덴마크를 타겟팅합니다.
.de는 자동으로 독일을 타겟팅합니다.
수동 설정이 필요하지 않습니다.

일반 TLD(.com, .org, .net) 경우:

서치 콘솔의 각 속성에서 "국제 타겟팅"을 설정하세요
hreflang을 주요 신호로 사용하세요

실용적인 단계:

서치 콘솔에서 사이트를 검증하세요 (서브폴더 설정용으로 단일 속성)
hreflang 주석이 있는 사이트맵 제출
오류에 대한 "국제 타겟팅" 보고서 확인
언어별로 "커버리지" 보고서 모니터링 (URL 매개변수 필터링 사용)
"사용자가 선택한 캐노니컬 없이 중복" 경고를 확인하세요 — 이는 종종 hreflang 문제를 나타냅니다.

빠른 승리: 서치 콘솔 > 성과 > 국가별 필터로 이동하세요. 독일의 사용자가 독일어 대신 영어 페이지에 도달하고 있는지 확인하세요. 그렇다면 hreflang 구성이 오류가 있는 것입니다.

5. 콘텐츠 현지화 (번역을 넘어서)

현지화는 단순한 단어 번역을 초월합니다. 콘텐츠를 문화적 맥락, 지역 검색 행동 및 마켓 특정 필요에 맞게 조정합니다.

현지화해야 할 것들:

통화 및 가격: 현지 통화 표시 (€ 독일, kr 덴마크, ¥ 일본)
날짜/시간 형식: 25/06/2026 (EU) vs 06/25/2026 (미국) vs 2026/06/25 (ISO/일본)
전화번호: 국제 통화를 위한 현지 형식
주소: 현지 우편 형식에 맞게 조정
사회적 증거: 현지 고객 이름, 현지 기업, 현지 사례 연구
CTA: 톤 조정 (독일어/일본어는 격식, 영어/덴마크어는 캐주얼)
이미지: 이미지 내 텍스트 현지화, 문화적으로 적절한 비주얼 사용
법적: EU의 GDPR, 국가별 쿠키 동의 요구사항 상이
예시: 현지 브랜드, 현지 웹사이트, 현지 참조

직접 번역하지 않아야 할 콘텐츠:

지역 주제에 관한 블로그 게시물 (시장별로 독창적으로 작성)
사례 연구 (현지 기업 사용)
가격 페이지 (시장에서 가격이 다르게 설정하는 것은 유효함)
뉴스 콘텐츠 (지역적 관련성이 다름)

키워드 현지화: 키워드를 번역하지 마세요 — 원어민이 연구하세요. "Car insurance"는 영어에서는 "bilforsikring"일 수 있지만, 검색량 리더는 실제로 "forsikring bil"(단어 순서 다름)일 수 있습니다. 현지 키워드 연구 도구를 사용하세요.

빠른 승리: 모든 언어의 가격 페이지를 확인하세요. 올바른 현지 통화가 표시되고 있습니까? CTA가 문화적으로 적절합니까? "무료로 시작하기" CTA는 독일어로는 "Jetzt kostenlos testen"이 필요할 수 있습니다 — 이는 문자 그대로의 번역이 아니라 독일 사용자가 기대하는 모습입니다.

6. RTL 지원

우에서 좌로 읽는 언어(아랍어, 히브리어, 페르시아어/파르시, 우르두, 파슈토)는 상당한 레이아웃 조정이 필요합니다. RTL 컨텐츠를 좌에서 우로 구성된 레이아웃으로 제공하면 약 5억 명의 원어민이 사이트를 사용할 수 없게 됩니다.

기술적 구현:

<!-- 방향 감지 및 적용 -->
<html lang="ar" dir="rtl">

RTL에서 바뀌어야 할 것들:

텍스트 정렬 (우측 정렬 본문 텍스트)
레이아웃 방향 (사이드바가 좌에서 우로 이동)
내비게이션 순서 (역방향)
방향이 있는 아이콘 (화살표, 진행 표시줄)
패딩 및 여백 (좌/우 값 교체)
경계 반지름 (코너 값 교체)
CSS 플렉스박스/그리드 방향

바뀌지 말아야 할 것들:

전화번호와 수학적 표현
좌에서 우로 읽는 브랜드 이름과 로고
오디오/비디오 플레이어 컨트롤
수평 스크롤 표시기
포함된 코드 블록

CSS 접근법 (모던):

/* 논리적 속성 사용 */
.card {
  margin-inline-start: 1rem;  /* margin-left 대체 */
  padding-inline-end: 0.5rem; /* padding-right 대체 */
  border-start-start-radius: 8px; /* LTR에서는 상단 왼쪽, RTL에서는 상단 오른쪽 */
}

RTL 테스트:

에 dir="rtl"을 추가하고 모든 페이지를 확인하세요
아랍어/히브리어 텍스트가 읽을 수 있는지 확인 (garbled Unicode 아님)
양식 입력 테스트 (텍스트 입력 방향)
숫자가 RTL 텍스트 내에서 올바르게 표시되는지 확인

빠른 승리: 아랍어 또는 히브리어를 지원하는 경우 해당 로케일에 대해 HTML 요소에 dir="rtl"을 추가하고 CSS 논리 속성을 사용하세요 (margin-inline-start 대신 margin-left). 이 단일 변경 사항이 80%의 RTL 레이아웃 문제를 해결합니다.

7. 언어 감지 및 라우팅

어떤 언어 버전을 사용자에게 보여주기로 결정하는 방법은 UX와 SEO 모두에 영향을 미칩니다.

모범 사례: URL 기반 + 기본 설정 쿠키

첫 방문: URL에 따라 콘텐츠를 보여줍니다 (예: /da/page = 덴마크어)
루트 URL(/): Accept-Language 헤더에 따라 리디렉션하거나 기본값(영어)을 보여줍니다
수동 전환: 사용자가 언어를 선택하면 쿠키를 설정하고 이후 방문에서 이를 존중합니다
절대 피할 것: 언어 특정 URL에서 리디렉션하지 마세요

피해야 할 것들:

IP 기반 리디렉션 (Google은 미국 IP에서 크롤링하므로 → 영어만 색인)
JavaScript 전용 언어 감지 (검색 엔진이 JS를 신뢰할 수 있도록 실행하지 못함)
/de/page를 영어 사용자에게 /en/page로 리디렉션 (hreflang 파괴)
클로킹 (사용자 에이전트에 따라 다른 콘텐츠 표시)

올바른 리디렉션 동작:

사용자가 방문: /             → 302 리디렉션 /{감지된-로케일}/로
사용자가 방문: /da/page      → 덴마크어 콘텐츠 제공 (절대 이탈하지 않음)
사용자가 방문: /nonexistent  → 404 (기본 언어로 리디렉션하지 않음)

SEO에 중요한 규칙: 모든 언어 URL은 리디렉션 없이 Googlebot이 직접 접근할 수 있어야 합니다. Google이 /da/page를 크롤링할 때 /en/page로 리디렉션된다면 덴마크어 콘텐츠는 절대 색인되지 않습니다.

빠른 승리: Googlebot이 모든 언어 URL에 직접 접근할 수 있는지 확인하세요. Search Console에서 URL 검사 도구를 비영어 URL에 사용하세요. 리디렉션이 표시되면 라우팅 논리가 수정되어야 합니다.

8. 언어 간 중복 콘텐츠

다국어 사이트는 독특한 중복 콘텐츠 문제에 직면합니다: 서로 다른 언어로 비슷한 페이지가 검색 결과에서 경쟁할 수 있습니다.

중복 콘텐츠 문제가 발생하는 경우:

언어 간 90% 이상 동일한 페이지 (번역되지 않은 콘텐츠)
로케일 접두사 유무에 관계없이 동일한 URL 접근 가능 (/page와 /en/page)
두 버전이 색인될 수 있도록 허용하는 캐노니컬 태그 누락
hreflang 오류로 Google이 "잘못된" 버전을 선택하게 되는 경우

해결 방법:

| 문제 | 해결책 | |---------|----------| | 번역되지 않은 페이지 | 번역될 때까지 noindex를 사용하거나 명확한 언어 지시가 있는 영어로 표시 | | 이중 URL (/page + /en/page) | 하나를 다른 하나로 301 리디렉션 | | Google이 잘못된 언어 색인 | hreflang 상호성을 수정하고 서치 콘솔에서 확인 | | 낮은 품질의 번역이 색인됨 | 번역 품질 개선 또는 더 적은 언어로 통합 |

캐노니컬 태그 전략:

<!-- 각 언어 페이지는 저마다의 캐노니컬 -->
<!-- /en/page -->
<link rel="canonical" href="https://example.com/en/page" />

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

언어 간 캐노니컬 태그를 설정해서는 안 됩니다 (예: 덴마크어 캐노니컬이 영어를 가리키는 경우) — 이는 Google이 덴마크어 버전을 전체적으로 무시하게 만듭니다.

빠른 승리: Google에서 site:yourdomain.com "your page title"을 검색하세요. 동일한 쿼리에 대해 영어 및 번역된 버전이 모두 나타나면 중복 콘텐츠 또는 hreflang 문제가 있는 것입니다.

다국어 SEO 체크리스트

모든 국제화된 사이트에 대해 이 리스트를 실행하세요:

[ ] 모든 페이지에서 hreflang 태그, 자기 참조 및 x-default 포함
[ ] 모든 hreflang 관계가 상호적임 (크롤러로 확인)
[ ] 올바른 로케일 라우팅 (서브폴더 권장): /{locale}/page
[ ] 언어 특정 URL에서 자동 리디렉션이 없음
[ ] 번역 품질 검증 (혼합 언어 페이지 없음)
[ ] 각 언어별로 메타 제목 및 설명 고유 (중복되지 않음)
[ ] 통화, 날짜 및 형식이 시장별로 현지화됨
[ ] 아랍어/히브리어/페르시아어에 대한 RTL 지원이 구현됨 (해당하는 경우)
[ ] 각 로케일 사이트맵을 서치 콘솔에 제출
[ ] 각 언어 페이지는 자기만의 캐노니컬 URL을 가지고 있음 (다른 언어로 가리키지 않음)
[ ] 모든 페이지에서 원시 i18n 키가 보이지 않음
[ ] 모든 페이지에서 언어 전환기가 접근 가능 (동일한 페이지로 연결, 홈페이지가 아님)

LANGR가 다국어 SEO를 점검하는 방법

LANGR에는 다국어 SEO를 위한 두 개의 전용 모듈이 있습니다:

i18n-checker: 최대 5개 로케일 변형의 페이지를 크롤링하고 확인합니다:

hreflang 태그 완전성 및 상호성
접근할 수 없는 로케일 URL (404 또는 리디렉션 반환)
로케일에 따라 하드코딩된/번역되지 않은 문자열 (대체 탐지)
가시 텍스트로 노출된 원시 i18n 키
번역 범위 비율

Translation scanner: AI 기반 품질 평가:

번역 자연스러움을 0-100 스케일로 평가
기계 번역 유물 감지
전반적으로 번역된 페이지 내 번역되지 않은 부분 식별
UI 요소 (버튼, 레이블, 내비게이션)를 본문 콘텐츠와 별도로 확인

이렇게 두 가지 모듈이 기술적(hreflang, 라우팅, 캐노니컬) 및 품질(번역, 현지화) 관점에서 다국어 구현을 점검합니다 — 이것이 LANGR의 13가지 SEO 분야 중 두 가지입니다.

일반적인 다국어 실수 (영향에 따라 순위 매김)

비상호 hreflang — Google이 전체 설정을 무시함
IP 기반 자동 리디렉션 — Googlebot이 비영어 버전을 색인하지 못하게 함
언어 간 동일한 메타 태그 — 번역된 페이지의 순위 잠재력을 낭비함
혼합 언어 페이지 — 영어 버튼, 독일어 콘텐츠 = 낮은 품질 신호
x-default 없음 — Google이 기본 버전을 결정할 수 없음
URL의 문자 그대로 번역 — /about-us → /uber-uns는 괜찮지만 일관성을 유지해야 함
RTL 무시 — 5억 명 이상의 원어민에게 깨진 레이아웃 제공
다른 언어로 가리키는 캐노니컬 — Google의 색인에서 번역된 버전을 죽임

다음 단계는 무엇인가요?

11단계: B2B 리드 발견 — 자동화된 발굴, 도메인 기반 리드 점수 및 SEO 결과에 의해 강화된 아웃리치를 통해 SEO 데이터를 유자격 리드로 전환하기.

이 가이드는 LANGR의 13단계 SEO 시리즈의 일환입니다. 무료 감사 진행하기 를 통해 귀하의 사이트가 13가지 분야에서 어떻게 진행되고 있는지 확인하세요.

SEO 가이드 10단계: 다국어 SEO — 순위를 희석하지 않으면서 글로벌 오디언스에 도달하기