리소스다국어 WordPress에서 hreflang 태그를 구현하는 방법

다국어 WordPress에서 hreflang 태그를 구현하는 방법

SimplePoTranslate Team2026년 5월 31일

전체 WordPress 사이트를 6개 언어로 번역했습니다. .po 파일은 깔끔하고, .mo 파일은 컴파일되었으며, 모든 문자열이 프랑스어, 독일어, 일본어로 완벽하게 렌더링됩니다. 하지만 출시 몇 주 후 Google Search Console을 확인해보니 당황스러운 사실을 발견했습니다. 프랑스어 페이지가 독일어 쿼리에 순위가 매겨지고, 스페인-멕시코 페이지가 스페인 검색자에게 제공되며, 두 개의 언어 버전이 순위에서 서로를 잠식하고 있었습니다. 콘텐츠는 좋습니다. 문제는 Google이 어떤 버전이 어떤 잠재고객에게 속하는지 전혀 알지 못한다는 것입니다.

이것이 바로 hreflang WordPress 태그가 해결하기 위해 설계된 문제입니다. Hreflang은 검색 엔진에 어떤 페이지의 어떤 언어 및 지역 버전을 어떤 사용자에게 제공해야 하는지 알려주는 신호입니다. 잘못 구현하면 중복 콘텐츠 희석, 잘못된 언어 결과, 낭비되는 크롤링 예산에 시달리게 됩니다. 올바르게 구현하면 각 번역된 페이지가 작성된 잠재고객에게 도달합니다. 이 가이드에서는 구문, 언어 코드와 언어-지역 코드의 차이점, 필수 x-default, 반환 태그 상호성, 그리고 WordPress에서 이를 구현하는 세 가지 실용적인 방법을 다룹니다.

hreflang이 실제로 하는 일

Hreflang은 어떤 것도 번역하지 않습니다. 그것은 관계 지도입니다. 여러 언어로 동일한 페이지를 가지고 있을 때, hreflang 주석은 Google에게 "이 URL은 영어 버전이고, 이것은 독일어 버전이며, 이것은 멕시코의 스페인어 사용자용입니다"라고 알려줍니다. Google은 이 지도를 사용하여 사용자의 언어 설정과 위치에 따라 검색 결과에 올바른 버전을 제공합니다.

이 주석은 HTML의 <head>에 <link> 요소 집합으로 존재합니다. 각 요소는 대상 페이지와 해당 페이지가 제공하는 언어(선택적으로 지역)를 지정합니다. 다음은 미국 영어, 영국 영어, 멕시코 스페인어로 제공되는 페이지에 대한 올바른 hreflang 태그 집합으로, 기본 대체(default fallback)가 포함되어 있습니다:

<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />

세트에 있는 모든 페이지는 자기 자신을 포함한 모든 대체 버전을 나열하는 동일한 블록을 출력해야 합니다. 이 마지막 부분이 대부분의 사람들을 혼란스럽게 하는 부분이며, 이에 대해서는 다시 다룰 것입니다.

SEO에 왜 중요한가

hreflang이 없으면 Google은 번역된 페이지를 동일한 키워드를 두고 경쟁하는 거의 중복된 콘텐츠로 간주합니다. 그 결과는 희석입니다. 순위 신호가 통합되지 않고 여러 버전으로 분산됩니다. 올바른 hreflang을 사용하면 각 버전은 전체 세트의 권위를 상속받고 올바른 검색자에게 노출됩니다. 이는 다국어 사이트가 할 수 있는 가장 영향력 있는 SEO 조치 중 하나이며, .po 파일의 실제 콘텐츠 번역을 대체하기보다는 보완합니다. 콘텐츠 측면은 PO 파일 번역이 Google 순위에 미치는 영향 가이드에서 심층적으로 다룹니다.

언어 코드 대 언어-지역 코드

en과 en-GB 중 어떤 것을 사용해야 할까요? 가장 단순하고 정확한 코드를 사용하세요. 영어 콘텐츠가 일반적이고 영국 및 미국 버전을 별도로 유지하지 않는다면 en만 사용하세요. 다른 국가에 실제로 다른 콘텐츠를 제공할 때만 지역 하위 태그를 추가하세요.

Hreflang 값은 language 또는 language-region 형식을 따릅니다. 언어 부분은 ISO 639-1 코드(en, es, de, pt)입니다. 선택적 지역은 ISO 3166-1 Alpha 2 국가 코드(US, GB, MX, BR)입니다. 따라서:

en은 국가와 상관없이 모든 영어 사용자를 대상으로 합니다.
en-GB는 영국 내 영어 사용자를 대상으로 합니다.
es는 모든 스페인어 사용자를 대상으로 합니다.
es-MX는 특히 멕시코 내 스페인어 사용자를 대상으로 합니다.

중요한 세부 사항: 지역 하위 태그는 언어 변형이 아니라 국가입니다. es-MX는 "멕시코 스페인어 방언"을 의미하는 것이 아니라 "멕시코 사용자에게 표시되는 스페인어"를 의미합니다. Google은 여전히 사용자의 위치를 기반으로 이를 제공합니다. 번역에서 지역 방언을 유지하는 경우, 지역 코드가 이들을 라우팅하는 방법입니다. 이 언어학적 측면은 지역 스페인어 및 포르투갈어 변형 가이드에서 자세히 다룹니다.

흔히 발생하는 잘못된 예시

다음은 우리가 끊임없이 보는 잘못된 hreflang 블록입니다:

<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="sp" href="https://example.com/es/" />
<link rel="alternate" hreflang="pt-PT_BR" href="https://example.com/pt/" />

세 가지 오류가 있습니다. en-uk는 영국에 대한 국가 코드가 GB이지 UK가 아니므로 유효하지 않습니다. sp는 언어 코드가 전혀 아닙니다. 스페인어는 es입니다. 그리고 pt-PT_BR은 hreflang에서 의미가 없는 밑줄로 두 지역을 혼합했습니다. 검색 엔진은 잘못된 값을 자동으로 무시하므로 어떤 오류도 없고 이점도 없습니다. 그저 아무것도 변하지 않은 이유를 궁금해하며 디버깅하는 데 몇 시간만 낭비할 뿐입니다.

hreflang은 하이픈(en-GB)을 사용하는 반면, WordPress 로케일 파일은 밑줄(en_GB)을 사용한다는 점에 유의하세요. .po 파일명 코드를 hreflang 태그에 직접 복사하지 마세요.

x-default와 반환 태그 상호성

다른 어떤 것보다 더 많은 자동으로 실패하는 hreflang 오류를 유발하는 두 가지 규칙은 x-default 누락과 깨진 상호성입니다.

x-default 값은 다른 언어가 사용자에게 일치하지 않을 때 Google이 어떤 페이지를 제공해야 하는지 알려줍니다. 이는 일반적으로 언어 선택기 또는 기본 시장 홈페이지인 대체 페이지입니다. 사양상 엄격하게 필수는 아니지만, 실제로는 항상 포함해야 합니다. 이것이 없으면 포르투갈어 버전이 없는 포르투갈어 사용 방문자는 의도적인 기본값 대신 무작위로 페이지가 표시됩니다.

반환 태그 상호성은 협상 불가능합니다. hreflang 세트의 모든 페이지는 자기 자신을 포함한 다른 모든 페이지를 다시 가리켜야 합니다. 영어 페이지가 독일어를 대체 언어로 나열하면, 독일어 페이지는 영어를 대체 언어로 나열해야 합니다. 독일어 페이지가 반환 참조를 생략하면 Google은 전체 관계를 신뢰하지 않고 주석을 무시합니다.

<!-- On the German page, the set must still list ALL versions -->
<link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />

자기 참조(독일어 페이지를 볼 때 독일어 페이지를 가리키는 de)는 필수이며 선택 사항이 아닙니다. 5가지 언어 버전 세트는 5개 페이지 각각이 5개의 <link> 태그와 x-default를 모두 출력한다는 의미입니다.

WordPress에서 hreflang을 구현하는 세 가지 방법

완전 수동 제어부터 완전 자동화까지 세 가지 실용적인 옵션이 있습니다.

방법 1: wp_head를 통한 수동 구현

작은 정적 페이지 세트의 경우, 테마의 functions.php에서 wp_head 액션을 통해 hreflang 태그를 직접 삽입할 수 있습니다:

add_action( 'wp_head', function () {
    if ( ! is_page( 'pricing' ) ) {
        return;
    }
    $alternates = array(
        'en-US' => 'https://example.com/en-us/pricing/',
        'es-MX' => 'https://example.com/es-mx/pricing/',
        'x-default' => 'https://example.com/pricing/',
    );
    foreach ( $alternates as $lang => $url ) {
        printf(
            '<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
            esc_attr( $lang ),
            esc_url( $url )
        );
    }
} );

이것은 정확한 제어를 제공하지만 확장성이 떨어집니다. 수백 개의 게시물에 걸쳐 상호성을 수동으로 유지하는 것은 유지보수 함정입니다.

방법 2: 다국어 플러그인

Polylang, WPML 또는 TranslatePress를 사용하는 경우, hreflang은 번역 관계에 따라 자동으로 생성됩니다. 이 방법은 플러그인이 어떤 게시물이 어떤 게시물의 번역인지 이미 알고 있으므로 상호성 및 x-default가 자동으로 처리되므로 대부분의 사이트에 적합한 해결책입니다. 비용은 이러한 플러그인이 추가하는 런타임 오버헤드이며, 이는 수동 대 AI 번역 접근 방식 비교에서 검토하는 절충점입니다.

방법 3: xhtml:link를 사용한 XML 사이트맵

모든 페이지의 <head>에 hreflang을 넣는 대신, xhtml:link 네임스페이스를 사용하여 XML 사이트맵에 관계를 선언할 수 있습니다. 각 <url> 항목은 모든 언어 대체 버전을 나열합니다:

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

이것은 페이지 HTML을 간결하게 유지하고 하나의 크롤링 가능한 파일에 언어 맵을 중앙 집중화하여 Google이 쉽게 읽을 수 있습니다. 대부분의 SEO 플러그인은 이를 자동으로 생성할 수 있습니다.

hreflang은 번역을 보완할 뿐, 대체하지 않습니다

모두가 놓치는 점은 다음과 같습니다. hreflang은 기본 페이지가 실제로 번역되지 않았다면 가치가 없습니다. 이 태그는 Google에게 "이것은 독일어 버전입니다"라고 알려주지만, 독일어 URL이 여전히 영어 플러그인 문자열, 번역되지 않은 결제 라벨 또는 미완성 .po 파일을 보여준다면, Google에게 독일 사용자에게 손상된 콘텐츠를 완전한 확신을 가지고 제공하라고 단순히 지시한 셈입니다.

진정한 다국어 SEO는 두 개의 계층으로 이루어집니다. 콘텐츠 계층은 모든 테마 및 플러그인 문자열을 대상 언어로 변환하는 번역된 .po, .pot, .json, .xliff 파일입니다. 신호 계층은 완성된 각 버전을 해당 잠재고객에게 라우팅하는 hreflang입니다. 둘 다 견고해야 합니다. 40%만 번역된 사이트 위에 완벽한 hreflang 세트를 구축하는 것은 더 나쁜 경험을 더 빨리 보장할 뿐입니다.

여기서 번역 계층을 깨끗하게 유지하는 것이 가장 중요합니다. 인터페이스 파일을 번역할 때 %s, %1$s, {name}과 같은 플레이스홀더는 손상되지 않고 유지되어야 합니다. 그렇지 않으면 "번역된" 독일어 페이지가 사용자와 검색 엔진 모두에게 깨져 보이는 문자 그대로의 %s 토큰으로 렌더링됩니다. Syntax Locking이 적용된 gettext를 인식하는 번역 파이프라인은 이러한 토큰을 자동으로 보호하므로, hreflang이 가리키는 모든 대체 페이지가 진정으로 프로덕션 준비가 되어 있습니다. Smart Batching으로 클라우드에서 실행되므로, 해당 페이지를 제공하는 런타임을 비대화시키는 번역 플러그인을 설치하지 않고도 전체 다국어 사이트를 통해 번역을 진행할 수 있습니다.

콘텐츠를 먼저 올바르게 만든 다음, hreflang이 제 역할을 하도록 하세요. 이 둘이 함께 작동하여 순위 신호를 통합하고, 잘못된 언어 결과를 제거하며, 각 번역된 페이지를 읽을 수 있는 사람들에게 보여줍니다.

잘못된 언어 검색 결과를 원천적으로 수정할 준비가 되셨나요? SimplePoTranslate를 무료로 사용해보세요 — 신용카드 필요 없음. 무료 티어에서 .po, .pot, .json 파일을 번역한 다음, 모든 시장에 실제로 준비된 페이지로 hreflang 태그를 지정하세요.

이 기사 공유하기

Facebook X (Twitter)LinkedIn Reddit WhatsApp Email

이 페이지에서

대용량 파일을 번역하시나요?

구문 오류로 사이트를 망가뜨리지 마세요. 변수와 HTML을 안전하게 처리하는 AI를 사용하세요.

무료로 번역 시작하기

신용카드 필요 없음