다국어 웹사이트 SEO와 Hreflang 모범 사례

중복 콘텐츠와 낭비되는 크롤 예산을 피하기 위한 hreflang, URL 구조, 현지화 선택으로 다국어 SEO를 설정하는 방법.

지구본과 언어 태그 은유 스케치노트, 텍스트 없음
이 페이지에서

두 번째 언어를 출시하는 것은 Search Console이 “잘못된 반환 태그”로 가득 차고 Google이 독일 쇼핑객에게 계속 영어를 보여줄 때까지는 승리처럼 느껴집니다. 다국어 SEO는 문자열을 번역하는 것보다, 각 시장에 안정적인 URL, 명확한 언어 또는 로케일 신호, 그리고 그곳 사람들이 실제로 사는 것과 맞는 콘텐츠를 주는 것에 가깝습니다.

이 가이드는 URL 구조 선택, hreflang 작동 방식(상호성과 x-default 포함), 언어 대 로케일, 번역 대 현지화, 흔한 실패 모드, 크롤 예산, CMS 함정, 실무 시나리오, 출시 체크리스트를 다룹니다.

무엇이든 주석 달기 전에 URL 구조를 고르기

Hreflang은 URL을 가리킬 뿐입니다. URL이 지저분하거나, 파라미터 기반이거나, 반쯤 마이그레이션되면 주석이 프로젝트를 구할 수 없습니다. 다중 지역·다국어 사이트 관리에 대한 Google 가이드가 일반적인 패턴을 제시합니다. 주 패턴 하나를 고르고 지키세요.

패턴 예 강점 비용
ccTLD example.de, example.fr 강한 국가 신호, 로컬 신뢰 별도 사이트, 더 많은 운영, 링크 자산 분할
서브도메인 de.example.com 명확한 분리, 유연한 호스팅 ccTLD보다 약한 국가 신호
서브디렉터리 example.com/de/ 한 도메인, 공유 권위, 더 단순한 CMS 국가 신호가 콘텐츠와 hreflang에 더 의존

한 브랜드 도메인에서 아직 권위를 쌓는 대부분의 제품·콘텐츠 사이트에는 서브디렉터리가 이깁니다. ccTLD는 법무 주체, 가격, 또는 컴플라이언스가 국가별로 진짜 다르고 각 사이트를 인력으로 운영할 수 있을 때 의미가 있습니다. 서브도메인은 모든 TLD를 사지 않고 별도 스택(예: 중국 향 오리진)이 필요할 때 중간에 앉습니다.

쿼리 문자열로 언어를 쓰지 마세요(?lang=de). 그런 URL은 복제하기 쉽고, 공유하기 어렵고, 분석에 어색합니다. 올바르게 주석하면 Google이 이해할 수 있지만, 파라미터 로케일과 사는 운영자는 보통 필터와 캠페인이 충돌할 때 후회합니다.

엔지니어와 번역가가 둘 다 읽는 한곳에 선택한 패턴을 문서화하세요. 나중에 /de/에서 de.example.com으로 바꾸는 것은 전체 리다이렉트 맵과 hreflang 재작성을 의미합니다. 그 마이그레이션 세금이 URL 결정을 첫 번역 페이지 출시 전에 두게 하는 이유입니다.

다국어 사이트용 세 URL 패턴: ccTLD, 서브도메인, 서브디렉터리

그림 1: 같은 브랜드의 나란한 ccTLD, 서브도메인, 서브디렉터리 레이아웃.

Hreflang이 실제로 작동하는 방식

Hreflang은 Google에게 주어진 언어 또는 언어-지역 조합의 의도된 버전 URL이 무엇인지 알립니다. 자체로 순위를 만들지 않습니다. 거의 맞는 페이지가 여러 개일 때 올바른 대안을 고르게 도와, 독일어 URL이 영어의 유효한 대안일 때 독일 사용자가 독일어 URL을 볼 가능성을 높입니다.

Google이 문서화한 세 가지 방식으로 대안을 선언할 수 있습니다:

  1. 페이지 <head>의 HTML <link rel="alternate" hreflang="..." href="...">
  2. 비HTML 파일(PDF 등)용 HTTP 헤더
  3. 대형 카탈로그용 XML 사이트맵 주석

대부분 마케팅 사이트는 HTML 태그 또는 사이트맵 항목을 씁니다. 대형 이커머스 카탈로그는 템플릿을 얇게 유지하려고 사이트맵을 자주 선호합니다. 주어진 URL 세트에 주 방법을 하나 고르고 일관되게 유지하세요. 같은 페이지 세트에 부분 HTML과 부분 사이트맵 주석을 섞는 것이 드리프트의 흔한 원인입니다.

코드는 Google이 받는 BCP 47 스타일 값을 따릅니다. en 또는 de 같은 언어 코드, 선택적으로 en-GB 또는 pt-BR 같은 지역. ISO 639-1 언어 코드와, 지역이 필요할 때 ISO 3166-1 Alpha 2 국가 코드를 쓰세요. 영국 영어에 uk 같은 단축을 발명하지 마세요(en-GB가 보통 선택). 지역만의 코드를 쓰지 마세요.

세트의 모든 페이지가 자기 참조 항목을 포함해 모든 대안을 나열해야 합니다. https://example.com/pricing/이 영어이고 https://example.com/de/pricing/이 독일어이면, 두 페이지(또는 사이트맵 행) 모두 최종, 인덱싱 가능한 URL을 가리키는 en과 de 항목이 필요합니다.

대안 사이의 상호 확인

Google의 현지화 버전 문서는 주석이 반대편에서 확인되어야 한다고 명시합니다. 페이지 A가 페이지 B를 de로 가리키면, 페이지 B는 페이지 A를 en(또는 A의 언어)으로 다시 가리켜야 합니다. 일방향 링크는 그 관계에 대해 무시됩니다.

상호성은 CMS가 “주” 로케일에만 태그를 생성할 때, 번역가가 옛 페이지를 업데이트하지 않고 새 언어를 발행할 때, 또는 CDN이 라이브 페이지가 이동하는 동안 옛 head를 캐시할 때 조용히 실패합니다. Search Console의 International Targeting / hreflang 리포트(속성에 사용 가능할 때)와 link[rel=alternate][hreflang]을 추출하는 크롤이 HTML을 눈으로 보는 것보다 빨리 잡습니다.

영어와 독일어 페이지 사이의 상호 hreflang 화살표

그림 2: 각 대안이 다시 가리켜야 합니다. 일방향 화살표는 확인된 쌍으로 치지 않습니다.

x-default와 매칭되지 않는 방문자

x-default는 다른 hreflang 값이 사용자의 언어나 지역 설정과 맞지 않을 때 원하는 URL을 표시합니다. Google은 같은 현지화 버전 문서에서 매칭되지 않는 언어의 폴백으로 설명합니다.

전형적인 용도:

  • 언어 선택기 또는 글로벌 게이트웨이 페이지
  • 별도 선택기를 운영하지 않을 때 주 영어(또는 다른 허브) URL
  • 신중히 고른 “나머지 세계” 스토어프론트

x-default는 “영어를 하는 사람을 위한 페이지”가 아닙니다. 영어는 여전히 자체 hreflang="en"(또는 en-US, en-GB 등)이 필요합니다. x-default는 정직할 때 en과 같은 URL을 가리킬 수 있습니다. 인덱싱 가능하고 유용한 선택기를 가리킬 수도 있습니다. soft 404, 절대 정착하지 않는 geo-IP 리다이렉트 인터스티셜, 또는 무작위 블로그 글을 가리켜서는 안 됩니다.

사용자(또는 Googlebot)가 안정적 URL을 보기 전에 IP로 자동 리다이렉트하면, 사용성과 크롤링 둘과 싸웁니다. Google의 다중 지역 가이드는 콘텐츠를 보여주기 위해 IP만 의존하지 말라고 경고합니다. 로케일당 안정적 URL과 보이는 언어 전환기를 선호하고, 매칭 작업은 hreflang에 맡기세요.

en, de, fr과 맞지 않을 때 폴백인 x-default

그림 3: x-default는 주석된 세트 밖의 언어를 가진 방문자를 잡습니다.

언어 코드 대 로케일 코드

de는 국가와 무관하게 독일어를 의미합니다. de-DE는 독일에서 쓰이는 독일어입니다. de-AT는 오스트리아에서 쓰이는 독일어입니다. 통화, 배송, 법적 카피, 또는 철자가 갈리면 다른 의도입니다.

한 URL이 그 언어의 모든 화자에게 정직하게 서비스할 때 언어만의 코드를 쓰세요. 언어 문자열이 같아 보여도 시장별로 페이지가 다를 때 언어-지역 코드를 쓰세요. 글로벌 독자를 위한 단일 영어 페이지는 종종 en 플러스 x-default입니다. 가격과 철자가 다른 별도 영국·미국 스토어프론트는 보통 각각 자체 URL이 있는 en-GB와 en-US입니다.

국기 아이콘과 CDN 엣지만 다른 en-US와 en-GB 중복을 만들지 마세요. Hreflang은 의미 있는 차이를 발명할 수 없습니다. 페이지가 거의 동일하면 통합하거나 제대로 현지화하세요.

스크립트와 지역 중국어는 주의가 필요합니다. 본토 독자를 위한 간체와 대만·홍콩을 위한 번체는 다른 읽기 경험입니다. 스크립트를 섞는 하나의 zh 페이지보다 별도 URL과 정밀한 코드(zh-Hans, zh-Hant, 또는 스택이 일관되게 지원하는 지역 형태)를 선호하세요. 무엇을 고르든 HTML, 사이트맵, 언어 전환기에서 같은 코드 패밀리를 유지하세요.

언어만의 태그 대 언어-지역 로케일 태그

그림 4: 언어 코드는 화자를 넓게 커버합니다. 로케일 코드는 콘텐츠가 실제로 다를 때 시장을 고정합니다.

번역이 멈추고 현지화가 시작되는 곳

USD, 미국 배송 매트릭스, 미국 사례 연구, 미국 법적 푸터를 그대로 두고 단어만 바꾸는 기계 또는 인간 번역은, hreflang이 완벽해도 저성과입니다. 현지화는 상업 표면을 바꿉니다. 통화, 세금 표시, 결제 수단, 지원 시간, 신뢰 신호, 예시, 규제 텍스트 모두 시장 패스가 필요합니다.

SEO 측면에서 현지화는 또한 다음을 포함합니다:

  • 영어 키워드의 직역이 아니라, 그 언어로 사람들이 검색하는 방식에 쓴 title과 메타 설명
  • 동등본이 있을 때마다 같은 언어 허브 안에 머무는 내부 링크
  • 중요한 곳의 로컬 UI나 캡션이 있는 이미지와 스크린샷
  • 여전히 전체 대안으로 주석되는 빈약한 “coming soon” 로케일 껍데기 건너뛰기

시장이 준비되지 않았으면, 페이지가 진정으로 동등할 때까지 hreflang에서 빼두세요. 플레이스홀더를 fr로 주석하면 Google에 프랑스어 대안이 약하다고 가르칩니다.

모범 사례: 사이트맵에 반쯤 번역된 폴더 열 개를 뿌리기 전에, 상업적으로 완성된 로케일을 더 적게 출시하세요.

원시 번역을 넘는 현지화 계층: 통화, 법률, 예시, 검색 표현

그림 5: 단어 교체를 넘어. 통화, 증거, 법적 표면도 시장 패스를 받습니다.

흔한 hreflang과 국제 SEO 실패

다국어 크롤 리뷰 거의 모두에서 나타납니다.

깨진 상호성. 새 로케일이 옛 언어를 나열하는 태그로 출시되지만, 옛 언어는 업데이트되지 않습니다. 모든 로케일에서 전체 대안 세트를 재생성하는 단일 진실 원천(빌드 단계 또는 CMS 필드)으로 고치세요.

잘못된 코드. eng, uk, zh-CN과 zh-Hans의 비일관 혼용, 또는 언어가 의도된 곳에 지역 코드. URL 문서에서 표준화한 코드 목록에 대해 검증하세요.

비canonical 또는 비인덱싱 URL에 주석. Hreflang은 최종 선호 URL을 가리켜야 합니다. 독일어 페이지가 영어로 canonicalize하거나 noindex를 반환하면 대안 세트가 거짓말입니다. 먼저 canonical과 인덱싱을 고치세요.

HTTP와 HTTPS 혼재, 또는 www와 non-www 혼재. 대안 세트의 모든 href가 canonical로 고른 같은 호스트와 프로토콜을 써야 합니다.

부분 커버리지. 홈페이지만 hreflang이 있고 제품 템플릿은 없습니다. 또는 사이트맵에만 항목이 있고 HTML이 모순됩니다. 트래픽을 버는 템플릿을 끝에서 끝까지 커버하세요.

파라미터 중복을 만드는 언어 전환기. /de/ 위에 ?currency=EUR를 추가하면서 canonical 규율이 없는 전환기는 거의 중복을 늘리고 크롤을 낭비합니다.

자동 리다이렉트 루프. 언어를 감지하고, 다른 폴더로 302한 뒤, 다른 규칙이 봇을 다른 곳으로 보냅니다. Googlebot에 안정적 로케일 URL의 200을 주세요.

경고: Hreflang 오류는 거의 보이는 온페이지 버그를 던지지 않습니다. 사용자가 탐색하는 동안 Google은 대안 맵을 무시할 수 있습니다. Search Console과 크롤 diff를 모니터링 표면으로 다루세요.

흔한 실패 아이콘: 일방향 태그, 잘못된 코드, noindex 대상, 혼합 호스트

그림 6: 흔한 고장은 상호성, 코드, 인덱싱 가능성, 호스트 비일관성입니다.

다국어 사이트의 크롤 예산

새 로케일마다 URL 수가 늘어납니다. 페이지가 고유하고 링크되어 있으면 괜찮을 수 있습니다. 빈약한 템플릿을 복제하고, 모든 언어의 패싯 필터, 번역을 원한 적 없는 태그 아카이브를 만들면 해롭습니다.

크롤 예산은 신비한 점수가 아닙니다. 실무에서 Googlebot이 수익 URL에 시간을 쓰는지 잡동사니에 쓰는지가 중요합니다. 다국어 잡동사니는 이렇게 보입니다:

  • 수천의 거의 빈 목록을 만드는 번역된 필터 조합
  • 모든 언어의 빈약한 글 페이지네이션 아카이브
  • 푸터에서 링크된 채 남은 스테이징 또는 미리보기 로케일
  • CMS 발행 실패 후 404 또는 soft-404인 대안

단일어 감사에서처럼 각 로케일의 저가치 표면을 통합하거나 noindex하세요. 사이트맵을 대안 맵에 속하는 canonical, 200, 인덱싱 가능 URL로 제한하세요. 언어를 추가할 때 유지할 수 있는 템플릿만 추가하세요.

내부 링크는 같은 로케일 경로를 선호해야 합니다. 영어 카테고리 허브에만 링크하는 독일어 아티클은 추가 홉을 강제하고 언어 클러스터를 희석합니다.

빈약한 번역 필터보다 수익 로케일 URL을 선호하는 크롤 경로

그림 7: 더 많은 언어는 더 많은 URL을 의미합니다. 번역된 필터 소음보다 상업 템플릿의 크롤을 선호하세요.

CMS와 플러그인 함정

WordPress, Shopify, Webflow, 커스텀 Next.js 앱, 엔터프라이즈 CMS는 모두 다르게 hreflang 버그를 키웁니다. 밑의 패턴은 같습니다. 페이지를 렌더하는 시스템이 대안을 소유한다고 생각하는 유일한 시스템이 아닙니다.

주의할 것:

  • link rel="alternate"를 둘 다 출력하며 동의하지 않는 플러그인 둘
  • 로케일 슬러그를 저장하는 헤드리스 CMS와, 프로덕션에서 경로를 다르게 다시 쓰는 프론트엔드
  • 모든 로케일을 나열하는 사이트맵 플러그인과 HTML 태그가 부분만 나열
  • 자기 참조를 생략하는 “Hreflang” 모듈
  • noindex나 스테이징 canonical을 복제하는 새 로케일로 복사 워크플로
  • 봇과 사용자에게 다른 HTML을 제공하는 CDN 또는 리버스 프록시 계층(의도적일 때는 드물고, 우연일 때는 지저분함)

웹사이트 국제화 작업에서는 hreflang을 주요 변경마다 재검증하는 릴리스 체크리스트 항목으로 다루세요. 특히 WordPress 다국어 스택에서는 주요 플러그인이나 테마 업데이트 후 각 로케일의 수익 페이지 라이브 HTML을 검증하세요.

앱에서 태그를 생성한다면, 템플릿당 예상 대안 수를 세는 CI 체크나 크롤 assert를 추가하세요. 수동 스팟 체크는 열 번째 언어를 놓칩니다.

hreflang 출력에서 충돌하는 CMS 계층: 테마, 플러그인, 사이트맵, CDN

그림 8: 테마, 플러그인, 사이트맵, CDN HTML이 각각 다른 대안 이야기를 내보낼 수 있습니다.

릴리스 데이를 견디는 구현 경로

내구성 있는 롤아웃은 이렇게 보입니다.

  1. URL 패턴과 상업적으로 준비된 로케일 목록을 동결합니다.
  2. 스프레드시트나 데이터베이스에 동등본을 매핑합니다. 각 행은 하나의 콘텐츠 단위. 열은 로케일 URL. 빈 셀은 “아직 대안 없음”(채워질 때까지 hreflang에서 생략).
  3. 그 템플릿 클래스의 진실 원천으로 HTML, HTTP, 또는 사이트맵을 고릅니다.
  4. 의도적 폴백이 있는 곳에 x-default를 포함해 자기 참조, 상호 태그를 생성합니다.
  5. 인덱싱되어야 할 때 각 로케일 URL이 자신을 canonicalize하도록 canonical을 정렬합니다.
  6. 각 로케일이 홈페이지를 추측하지 않고 매핑된 동등본에 링크하도록 언어 전환기를 업데이트합니다.
  7. 관리하는 각 속성에 대해 Search Console에서 사이트맵을 제출하거나 새로고침합니다.
  8. 배포 후 크롤하고 diff합니다. 수익 템플릿에서 상호성이나 코드 검증이 실패하면 릴리스를 실패시킵니다.
  9. hreflang 이슈와 실적 리포트의 예상치 못한 국가·언어 착륙 패턴을 Search Console에서 모니터링합니다.

현지화 페이지 버전에 대한 Google 문서가 태그 구문과 상호성의 규범적 참조입니다. 서드파티 검증기가 도움이 되고, Google이 무엇을 받는지는 여전히 공식 규칙이 결정합니다.

URL 동결부터 크롤 검증까지의 구현 단계

그림 9: 먼저 동등본을 매핑하고, 상호 태그를 생성한 뒤, 배포 후 크롤로 검증합니다.

독일어와 프랑스어를 추가하는 SaaS 사이트 실무 시나리오

Acme는 https://www.acme.example/에서 영어 블로그와 가격이 있는 B2B 분석 제품을 출시합니다. 마케팅은 EU 확장을 위해 독일어와 프랑스어를 원합니다. 엔지니어링은 한 도메인을 선호합니다. 서브디렉터리를 고릅니다: /de/와 /fr/.

옛 블로그 태그 아카이브를 전부 번역하지 않습니다. 홈페이지, 가격, 제품 개요, 문서 진입점, 아직 파이프라인을 버는 20개 글을 현지화합니다. 법무가 EU 준비 개인정보 부록을 씁니다. 가격은 필요한 곳에 VAT 노트와 함께 EUR을 보여줍니다. 사례 연구는 실제로 사용 권한이 있는 EU 로고로 바꿉니다.

동등본 맵(단순화):

단위 en de fr
홈 / /de/ /fr/
가격 /pricing/ /de/pricing/ /fr/pricing/
제품 /product/ /de/product/ /fr/product/

그 여섯 URL(플러스 자기) 각각이 en, de, fr, 그리고 영어 홈이나 인덱싱 가능하게 유지하기로 한 작은 지역 선택기를 가리키는 x-default를 내보냅니다. 영어에만 있는 블로그 글은 번역될 때까지 de/fr을 생략합니다. 독일어 홈을 프랑스어 가격 URL에 가리키지 않습니다.

출시 후 1주차, 크롤이 캐싱 계층이 옛 head를 제공해 영어 가격에 여전히 새 대안이 없음을 찾습니다. purge하고, 재크롤하며, 상호성을 확인합니다. 처리 후 Search Console이 그 URL의 반환 태그 오류 보고를 멈춥니다.

성공을 /de/와 /fr/ 수익 페이지에 착륙하는 독일어·프랑스어 쿼리로 측정합니다. 인덱싱된 URL 수만으로는 여기서 약한 성공 지표입니다.

매핑된 홈, 가격, 제품 URL로 /de/와 /fr/을 추가하는 SaaS 사이트

그림 10: Acme가 완성된 동등본 몇 개를 매핑하고, 상호 태그를 출시하며, 빈약한 아카이브 번역을 건너뜁니다.

다국어 SEO 체크리스트

프로젝트를 완료라고 부르기 전에 쓰세요.

  • 일관되게 쓰인 문서화된 URL 패턴 하나(ccTLD, 서브도메인, 또는 서브디렉터리)
  • 상업적으로 준비된 로케일만 라이브이고 주석됨
  • 주석된 모든 URL이 200을 반환하고, 인덱싱 가능하며, 순위가 필요할 때 자기 canonicalize
  • Hreflang 코드가 언어 대 로케일 정책과 일치(de vs de-DE 등)
  • 각 멤버 페이지 또는 사이트맵 행에 자기 참조를 포함한 전체 대안 세트
  • 세트 전반의 상호 확인
  • x-default가 의도적 폴백을 가리킴
  • 언어 전환기가 파라미터 중복을 만들지 않고 실제 동등본에 링크
  • 사이트맵이 크롤을 원하는 canonical 로케일 URL만 나열
  • 빈약한 번역 필터, 태그, 스테이징 로케일이 대안 맵 밖
  • 배포 후 크롤이 수익 템플릿의 태그를 검증
  • 관리하는 호스트에 대해 Search Console 속성과 사이트맵 업데이트됨

다국어 SEO와 hreflang 런치 준비용 체크리스트 클립보드

그림 11: 런치 준비는 URL, 코드, 상호성, 인덱싱 가능성, 배포 후 검증을 커버합니다.

자주 묻는 질문

언어가 하나뿐이면 hreflang이 필요한가요?

아니요. Hreflang은 같은 콘텐츠의 대안 언어 또는 로케일 버전용입니다. 단일 언어 사이트는 깨끗한 canonical과 크롤 접근에 집중해야 합니다. 쓸모없는 곳을 가리키는 장식용 hreflang을 추가하면 모니터링 소음만 만듭니다.

Hreflang이 자체로 중복 콘텐츠를 고칠 수 있나요?

유효한 버전 중 올바른 대안을 Google이 고르게 돕습니다. Canonical 규율을 대체하지 않고, 빈약한 복사 페이지를 재활하지 않습니다. 먼저 중복과 품질을 고친 뒤, 실제 동등본에 주석하세요.

모든 블로그 글이 모든 언어로 있어야 하나요?

유지할 때만. 부분 커버리지는 괜찮습니다. 그 단위에 존재하는 언어에 주석하고, 출시될 때까지 나머지는 대안 목록에서 빼두세요.

국제 SEO에 ccTLD가 항상 나은가요?

아니요. ccTLD는 강한 국가 신호이고 로컬 사용자에게 종종 신뢰 신호이지만, 운영 비용이 더 들고 각 속성에 투자하지 않으면 권위를 분할합니다. 많은 글로벌 브랜드는 서브디렉터리와 올바른 hreflang으로 잘합니다. 포럼 스레드의 경험 규칙이 아니라 법률, 호스팅, 리소스 제약에서 고르세요.

대형 카탈로그의 hreflang은 어디에 두나요?

SKU가 수만일 때 XML 사이트맵이 더 잘 확장됩니다. 사이트맵 항목을 canonical 제품 URL과 동기화하세요. 스택이 head 태그도 출력하면 HTML을 스팟 체크하고 충돌을 제거하세요.

Hreflang과 content-language 메타 태그의 차이는?

Hreflang은 Google 검색을 위한 언어와 지역의 대안 URL을 매핑합니다. content-language 메타 태그는 그 맵의 대체가 아닙니다. 대안에 Google의 현지화 버전 메커니즘을 따르세요.

마무리

다국어 SEO는 URL이 안정적이고, 로케일이 실제 제품이며, hreflang이 그 URL의 상호 맵일 때 유지됩니다. 고생하는 팀은 보통 먼저 주석하고 나중에 현지화했거나, 세 번째 언어가 출시된 뒤 아무도 재검증하지 않은 플러그인이 태그를 내보내게 했습니다.

로케일 롤아웃을 계획하거나 기존 대안 맵을 정리 중이라면 문의 양식으로 연락해 주세요.