이 주제를 찾아오는 계기가 되는 증상은 거의 언제나 같습니다. 회사에 일본어 섹션이 있고 색인도 되어 있는데, 일본의 검색 사용자는 계속 영어 페이지로 들어옵니다. 일본어 검색어에서 영어 페이지가 일본어 페이지보다 순위가 높은 경우도 있습니다.

hreflang은 대개 그 원인의 일부입니다. 전부는 아닐 때도 있습니다. 아무도 검색하지 않는 일본어 페이지는 어떻게 마크업하든 상위에 오르지 않으니까요. 하지만 hreflang은 확실하게 고칠 수 있는 부분이며, 다른 결론을 내리기 전에 먼저 고쳐 둘 가치가 있습니다.

hreflang이 실제로 하는 일

hreflang은 페이지의 순위를 올려 주지 않습니다. 여러 URL이 같은 콘텐츠의 다른 언어 또는 지역 버전이라는 사실을 구글에 알려, 그중 하나가 검색 결과에 오를 자격을 얻었을 때 사용자의 언어와 위치에 맞는 버전으로 바꿔 보여 줄 수 있게 하는 것입니다.

이 정의에서 두 가지 결과가 따라 나오며, hreflang 실수 대부분은 그중 하나를 놓친 데서 비롯됩니다.

첫째, hreflang은 교체 장치이지 순위를 끌어올리는 장치가 아닙니다. 일본어 페이지가 자체적으로 검색에 노출되지 않고 영어 페이지도 마찬가지라면, hreflang을 올바르게 설정해도 아무것도 달라지지 않습니다.

둘째, hreflang은 사이트 단위가 아니라 URL 클러스터 단위로 작동합니다. 모든 페이지에는 각자의 클러스터가 있습니다. /services/technical-seo/와 /ja/services/technical-seo/가 하나의 클러스터를 이루고, 두 홈페이지가 또 다른 클러스터를 이룹니다. 각 언어의 홈페이지를 가리키는 사이트 공통 마크업 블록 하나를 모든 페이지에 반복해 넣는 것은, hreflang이 있는데도 아무 효과를 보지 못하는 가장 흔한 방식 중 하나입니다.

ja인가, ja-JP인가?

언어 하위 태그는 ja입니다. jp가 아닙니다. jp는 국가 코드로 .co.jp나 ja-JP에 등장하는 값이며, 단독으로는 유효한 언어 값이 아닙니다. hreflang="jp"는 유효하지 않으며 그대로 무시됩니다. 저희가 일본어 섹션에서 가장 자주 보는 hreflang 오류가 바로 이것이고, 유효하지 않은 마크업은 아무 경고 없이 실패하기 때문에 몇 년씩 방치되기도 합니다.

ja와 ja-JP 중에서는, 솔직히 말해 대부분의 사이트에 ja가 맞습니다.

  • ja는 “이 페이지는 전 세계 어디에 있든 일본어 사용자를 위한 것”이라는 뜻입니다.
  • ja-JP는 “이 페이지는 일본에 있는 일본어 사용자를 위한 것”이라는 뜻이며, 다른 지역에서 접속하는 일본어 사용자는 제외됩니다.

지역 하위 태그는 국가별로 구분된 일본어 버전이 실제로 둘 이상 있을 때만 사용하십시오. 예를 들어 일본 가격을 표시하는 ja-JP 페이지와 싱가포르 법인용 ja-SG 페이지가 있는 경우입니다. 일본어 페이지가 하나뿐이라면 ja로 해외 출장 중이거나 해외에 거주하는 일본어 사용자를 포함해 이 페이지를 봐야 할 모든 사람을 포괄할 수 있습니다. 이유 없이 ja-JP로 좁히면 그저 사용자층 일부를 잃을 뿐입니다.

지역 하위 태그를 사용한다면 ISO 3166-1 alpha-2 국가 코드여야 하며, 관례적인 대소문자 표기는 ja-JP입니다(값 자체는 대소문자를 구분하지 않지만, 일관되게 쓰면 점검이 쉬워집니다).

가장 많이 무너지는 규칙, 상호 참조

클러스터 안의 모든 URL은 자기 자신을 포함해 그 클러스터의 모든 URL을 나열해야 합니다. 페이지 A가 페이지 B를 일본어 대체 페이지로 지정했는데 페이지 B가 페이지 A를 거꾸로 지정하지 않으면, 구글은 해당 마크업을 완전히 무시할 수 있습니다.

자기 참조는 실제로 필수이며, 실제로 자주 누락됩니다. 일본어 페이지에는 영어 페이지를 가리키는 줄뿐 아니라 자기 자신을 가리키는 hreflang="ja" 줄도 있어야 합니다.

영어 원본과 일본어 버전이 있는 사이트라면, 두 페이지 모두에 다음과 동일한 블록이 들어갑니다.

<link rel="alternate" hreflang="en" href="https://example.com/services/pricing/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/services/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services/pricing/" />

상호 참조를 가장 확실하게 맞추는 방법은 수작업 관리를 그만두는 것입니다. 각 페이지가 어떤 언어로 존재하는지 알고 있는 페이지 레지스트리 같은 단일 정보원에서 클러스터를 생성하면, 클러스터 안의 모든 페이지가 구조적으로 같은 목록을 출력하게 됩니다. 수작업으로 관리하는 hreflang은 누군가 페이지를 처음 추가하는 순간부터 무너지기 시작합니다.

x-default

x-default는 사용자에게 맞는 다른 버전이 없을 때 보여 줄 페이지를 지정합니다. 선택 사항이며, 자주 오해받습니다.

“더 적합한 버전이 없는 사용자”에게 합리적인 대체 페이지가 되는 곳을 가리키도록 하십시오. 대개 글로벌 영어 버전이며, 실제 언어 선택 페이지가 있다면 그 페이지입니다. x-default를 일본어 페이지로 지정해서는 안 됩니다. 의도하지 않은 사용자에게 일본어 페이지가 노출됩니다.

x-default도 상호 참조에 포함됩니다. 같은 마크업이 클러스터의 모든 페이지에, 그것이 가리키는 페이지 자신에게도 들어가야 합니다.

알아 둘 만한 미묘한 점이 하나 있습니다. x-default는 선택할 버전이 둘 이상 있을 때만 제 역할을 합니다. 한 가지 언어로만 존재하는 페이지에서는 마크업 블록 전체가 군더더기일 뿐입니다.

어디에 넣을 것인가

구글 입장에서는 세 가지 전달 방식이 모두 똑같이 유효합니다.

  • <head> 안의 <link> 요소 — 가장 단순하며 대부분의 사이트에 적합한 기본값입니다. JavaScript로 <body>에 삽입하는 것이 아니라 원본 HTML의 <head>에 있어야 합니다.
  • HTTP Link 헤더 — PDF처럼 HTML이 아닌 파일에 쓸 수 있는 유일한 방법입니다.
  • XML 사이트맵 마크업 — 대규모 사이트에서는 수천 개의 템플릿에 흩어 두는 대신 클러스터 전체 맵을 생성된 파일 하나에서 관리할 수 있어, 유지보수 측면에서 가장 나은 선택인 경우가 많습니다.

하나만 고르십시오. 서로 어긋나는 두 가지 방식을 함께 쓰는 것은 어느 하나만 쓰는 것보다 나쁘며, 플러그인과 수작업 템플릿이 동시에 작동할 때 의외로 자주 생기는 결과입니다.

캐노니컬과 hreflang은 일치해야 한다

다른 부분은 제대로 되어 있는 설정도 여기서 깨지는 경우가 많습니다.

모든 언어 버전은 자기 참조 캐노니컬이어야 합니다. 일본어 페이지의 캐노니컬은 자기 자신입니다. 일본어 페이지에 영어 URL을 가리키는 <link rel="canonical">이 있다면(생각보다 자주 일어나며, 대개 중복 콘텐츠를 우려하던 시절의 잔재입니다), 일본어 페이지를 아예 색인하지 말라고 구글에 알린 셈이며, 그 페이지를 가리키는 hreflang 마크업은 의미가 없어집니다.

같은 원칙에서 따라 나오는 관련 규칙은 다음과 같습니다.

  • hreflang은 캐노니컬이면서 색인 가능한 URL을 가리켜야 합니다. 리다이렉트, 매개변수가 붙은 변형, noindex 페이지를 가리켜서는 안 됩니다.
  • 프로토콜을 포함한 절대 URL을 사용하십시오. 상대 URL로 된 hreflang은 지원되지 않습니다.
  • 후행 슬래시, www, https 규칙을 정확히 맞추십시오. https://example.com/ja/pricing과 https://example.com/ja/pricing/은 서로 다른 URL이며, 브라우저에서는 같은 곳에 도착하더라도 불일치가 있으면 상호 참조가 깨집니다.

하위 디렉터리, 서브도메인, 아니면 .co.jp

hreflang은 세 가지 모두에서 똑같이 작동합니다. example.com/ja/, ja.example.com, example.co.jp는 모두 서로의 대체 페이지로 마크업할 수 있으며, 구글은 도메인 간 hreflang 클러스터도 문제없이 처리합니다.

따라서 URL 구조 결정은 hreflang의 문제가 아니라 권위, 운영, 신뢰의 문제이며, 이는 일본에서 상위 노출하려면 .co.jp 도메인이 꼭 필요할까?에서 따로 다룹니다. hreflang과 관련해 짚을 점은 하나뿐입니다. 도메인 간 클러스터는 상호 참조를 유지하기가 더 어렵습니다. 양쪽을 대개 서로 다른 팀이 서로 다른 릴리스 주기로 관리하기 때문입니다. 이는 순위 리스크가 아니라 운영 리스크이지만, 실재하는 리스크입니다.

가장 먼저 확인해야 할 실패 패턴

저희가 발견하는 빈도 순으로 대략 정리하면 다음과 같습니다.

  1. hreflang="ja" 대신 hreflang="jp"를 사용.
  2. 한쪽 또는 양쪽에 자기 참조 마크업이 없음.
  3. 상호 참조되지 않는 클러스터 — 대개 일본어 섹션이 나중에, 다른 팀에 의해, 다른 템플릿으로 만들어졌기 때문.
  4. 모든 페이지가 두 홈페이지를 가리키는 사이트 공통 마크업.
  5. 리다이렉트되거나, 404를 반환하거나, noindex가 붙은 hreflang 대상.
  6. 일본어 페이지의 캐노니컬이 영어 페이지를 가리킴.
  7. 마크업과 실제 URL 사이의 프로토콜, www, 후행 슬래시 불일치.
  8. 클라이언트 측 JavaScript로 삽입된 마크업.
  9. IP 기반 자동 리다이렉트로 인해 Googlebot(주로 미국 IP 주소에서 크롤링함)이 일본어 페이지에 아예 접근하지 못함.

마지막 항목은 다른 모든 것을 무력화하기 때문에 특히 강조할 필요가 있습니다. 일본 IP의 방문자는 강제로 /ja/로 보내고 나머지는 모두 강제로 다른 곳으로 보낸다면, 마크업은 구글이 크롤링할 수 없는 사이트를 설명하고 있는 셈입니다. 언어 전환은 닫을 수 있는 배너로 제안하고, 강제하지 마십시오.

검증하는 방법

구글이 Search Console의 전용 ‘국제 타겟팅’ 보고서를 폐지했기 때문에, 더 이상 구글이 직접 제공하는 hreflang 검증 도구에 기댈 수 없습니다. 이제 검증은 직접 해야 하는 일이지만, 어렵지 않습니다.

  • 두 언어 섹션을 모두 크롤링하십시오. hreflang을 추출할 수 있는 크롤러를 사용하고, 페이지 하나를 표본 점검하는 대신 전체 집합에서 상호 참조를 확인하십시오. 상호 참조 오류는 체계적으로 발생합니다. 한 페이지에 있다면 수백 페이지에 있을 가능성이 높습니다.
  • 모든 대상 URL이 200을 반환하는지, 자기 참조 캐노니컬인지, 색인 가능한지 확인하십시오.
  • 브라우저 개발자 도구의 렌더링된 DOM이 아니라 원본 HTML을 확인하십시오. 둘은 다를 수 있습니다.
  • 대표적인 일본어 페이지에 URL 검사 도구를 사용해, 구글이 의도한 캐노니컬을 인식하고 있는지 확인하십시오.
  • Search Console 실적 보고서를 일본으로 필터링해 관찰하고, 일본어 검색어의 노출이 어느 URL에 발생하는지 보십시오. 수정 후 몇 주가 지나도 여전히 영어 URL이라면, 마크업이 반영되지 않고 있거나 일본어 페이지가 해당 검색어에 대해 신뢰할 만한 결과가 아닌 것입니다.

이 마지막 구분을 꼭 기억해 두십시오. hreflang은 귀사의 페이지 중 어느 것을 보여 줄지를 결정합니다. 그중 어느 것이라도 보여 줄 가치가 있는지는 결정하지 않습니다. 일본어 페이지가 영어 검색 수요를 기반으로 만든 영어 페이지의 직역이라면, 마크업을 올바르게 해도 아무도 찾지 않는 페이지가 노출될 뿐입니다. 이에 대해서는 웹사이트 번역이 일본 SEO가 아닌 이유에서 자세히 설명했습니다.

기술 계층을 먼저 고치십시오. 확인 가능하고, 한 번 고치면 유지되기 때문입니다. 그다음 더 어려운 나머지 절반에 착수하십시오.

설정을 제대로 점검받고 싶으시다면, 이는 저희 일본 대상 인터내셔널 SEO 및 기술적 SEO 업무의 일부입니다. URL을 보내 주시면 발견한 내용을 알려 드리겠습니다.