다국어 구조화된 데이터: 언어·지역별 URL에 맞춘 JSON-LD 현지화

크롤링 가능한 각 언어·지역별 URL에서 schema.org JSON-LD를 현지화하고, inLanguage 및 엔터티를 hreflang과 일치시키며, 근거 없는 순위 상승 효과를 내세우지 않고 다국어 구조화된 데이터의 품질을 검수하는 방법을 알아보세요.

Grant Davies업데이트

다국어 구조화 데이터: 흰색 격자 위에 엔터티별 inLanguage 칩이 표시된 JSON-LD 노드 그래프

JSON-LD를 사이트 전체에서 사용하는 영어 스니펫으로 취급해 모든 로캘 URL에 붙여 넣으면 다국어 구조화 데이터를 잘못 구현하기 쉽습니다. 검색 엔진과 답변 엔진은 구조화 데이터를 특정 URL에 있는 페이지에 대한 설명으로 받아들입니다. 프랑스어 제품 페이지에 여전히 inLanguage: en, 영어로 된 name 값, 미국 사이트에서 복사한 기준 엔터티 그래프가 선언되어 있다면 서로 상충하는 신호를 보내게 됩니다. 이는 기존 검색 색인 생성과 답변 엔진의 명확한 이해를 모두 저해합니다.

이 가이드에서는 Google의 다국어 관련 문서와 실제 콘텐츠를 정확히 반영하는 스키마 구현 원칙을 바탕으로, 크롤링 가능한 로캘 URL별로 schema.org 마크업을 현지화하고, JSON-LD를 hreflang 및 표준 URL과 일치시키며, 조직 및 제품 엔터티의 일관성을 유지하고, 다국어 스키마 출시 시 QA를 수행하는 방법을 설명합니다. 근거 없는 순위 상승 효과를 주장하지 않습니다. 구조화 데이터는 시스템이 콘텐츠를 이해하도록 도울 뿐, 부실한 번역을 보완하지는 못합니다.

이 가이드에서 다루는 질문

  • 언어별 URL마다 구조화 데이터를 현지화해야 하는 이유는 무엇인가요?
  • inLanguage와 다른 언어 버전 페이지는 어떻게 표현해야 하나요?
  • 다국어 사이트에서 가장 중요한 스키마 유형은 무엇인가요?
  • hreflang 및 표준 URL은 구조화 데이터와 어떻게 상호작용하나요?
  • 어떤 실수가 언어 혼용이나 중복 엔터티 마크업을 유발하나요?
  • 로캘 간 조직 및 제품 엔터티의 일관성은 어떻게 유지해야 하나요?
  • 근거 없는 순위 요소를 내세우지 않고 구조화 데이터로 답변 엔진을 지원하려면 어떻게 해야 하나요?
  • 다국어 스키마 출시 시 어떤 QA 검사가 필요한가요?

핵심 답변: 크롤링 가능한 각 로캘 URL에서 스키마를 현지화하세요

간단히 말하면: 크롤링 가능한 모든 로캘 URL에 해당 언어로 표시되는 페이지를 정확히 설명하는 JSON-LD를 출력하세요. 올바른 inLanguage, 현지화된 텍스트 속성, 정확한 url, 시장 간에 일관되게 유지되는 엔터티 식별자가 필요합니다.

Google은 쿠키나 브라우저 언어에만 의존하지 말고 언어 또는 지역 버전별로 크롤링 가능한 URL을 따로 사용할 것을 권장합니다. 구조화 데이터는 사이트 전체에 삽입하는 공통 영어 틀이 아니라, 해당 URL에서 사용자와 크롤러가 보는 페이지를 설명해야 합니다.

각 블록은 화면에 표시되는 주요 콘텐츠와 동일한 언어를 사용해야 합니다. Google은 주로 화면에 표시되는 콘텐츠를 기준으로 페이지 언어를 판단합니다. 스키마가 본문과 모순되면 크롤러가 이를 해석하고 조정하는 데 불필요한 작업이 발생합니다.

구조화 데이터가 언어 버전별 구조를 따라야 하는 이유

구조화 데이터는 URL 구조와 동떨어진 별도의 국제 SEO 계층이 아니라, 그 구조를 반영합니다. /de/produkt/widget을 게시할 때 해당 URL의 JSON-LD는 독일어 페이지를 설명해야 합니다. 제목과 설명은 독일어여야 하며, 해당하는 경우 판매 조건도 반영해야 합니다. 또한 inLanguage는 de 또는 de-DE와 같은 유효한 BCP 47 태그로 설정해야 합니다.

언어 버전마다 크롤링 가능한 별도의 URL이 필요합니다. 구조화 데이터는 하나의 공통 영어 틀이 아니라, 해당 URL에서 사용자와 크롤러가 보는 페이지를 설명해야 합니다. CMS가 전역 공통 스키마 템플릿 하나만 렌더링하면 모든 로캘에 영어 엔터티 이름이 그대로 적용됩니다. 이는 언어 혼용으로 인한 리치 결과 표시 자격 문제와 답변 엔진의 부실한 요약을 유발하는 흔한 원인입니다.

hreflang은 검색 엔진에 대체 버전을 알리고, 구조화 데이터는 현재 페이지의 내용을 설명합니다. 두 신호 모두 각 URL이 다른 언어인 척하는 중복 페이지가 아니라 온전한 언어 버전임을 일관되게 나타내야 합니다.

언어 타기팅과 국가 타기팅의 전략적 차이는 국제 SEO와 다국어 SEO 비교에서 확인하세요.

핵심 속성: inLanguage, url, 엔터티 식별

모든 로캘 템플릿에서 우선적으로 살펴봐야 할 속성은 세 가지입니다.

inLanguage — 페이지와 일치하는 유효한 언어 또는 로캘 코드를 사용하세요. 현지화된 URL에 영어 설정을 그대로 두지 마세요. 지역별 변형(en-GB와 en-US)을 타기팅할 때는 hreflang 코드와 일치시키세요.

url — 설명 대상 페이지의 표준 URL로 연결되어야 합니다. 일반적으로 영어 홈페이지가 아니라 해당 로캘의 브라우저 주소창에 표시되는 URL과 같아야 합니다.

엔터티 @id 또는 고정 식별자 — 조직 및 제품 엔터티는 사람이 읽는 속성을 현지화하되, 로캘 간에 일관된 ID(https://example.com/#organization)를 유지해야 하는 경우가 많습니다. 일관된 ID는 시스템이 여러 언어에서 동일한 브랜드나 SKU를 인식하도록 돕습니다. 현지화된 name 및 description 필드는 각 시장에 맞는 언어를 담습니다.

하나의 URL에 서로 충돌하는 엔터티 정의를 중복해서 넣지 마세요. 플러그인마다 삽입한 세 개의 블록이 충돌하는 것보다 페이지당 하나의 일관된 Organization 그래프를 사용하는 편이 더 깔끔합니다.

주로 현지화가 필요한 스키마 유형

모든 스키마 유형을 번역해야 하는 것은 아니지만, 다국어 사이트에서는 다음 유형에 현지화가 필요한 경우가 많습니다.

  • WebPage / Article / BlogPosting — headline, description, inLanguage, url.
  • Product — name, description, offers에 적절한 통화 및 구매 가능 여부 텍스트를 사용합니다.
  • FAQPage — 질문과 답변은 페이지에 표시되는 해당 언어의 FAQ 콘텐츠와 일치해야 합니다.
  • Organization — 시장마다 법인명이나 상호가 다르면 name을 현지화하고, @id는 일관되게 유지합니다.
  • BreadcrumbList — 탐색 메뉴와 일치하도록 탐색 경로 레이블을 현지화합니다.
  • LocalBusiness — 해당하는 경우 로캘에 적합한 주소와 areaServed을 사용합니다.

유용하고 사용자 중심적인 콘텐츠가 여전히 기본입니다. 구조화 데이터는 부실한 번역을 보완하는 수단이 아니라 현지화된 콘텐츠를 정확히 반영해야 합니다. 내용이 거의 없는 빈 페이지에 마크업을 추가한다고 유용한 페이지가 되는 것은 아닙니다.

hreflang, 표준 URL, JSON-LD의 일치

hreflang 주석은 Google에 다른 언어 또는 지역 버전의 URL을 알려주며, 해당 페이지 집합 내에서 서로를 상호 참조해야 합니다. 표준 URL은 같은 언어의 중복 페이지 중 어떤 URL을 우선할지 Google에 알려줍니다. JSON-LD는 이 두 신호 중 어느 것과도 충돌해서는 안 됩니다.

실무에서 적용할 일치 원칙:

  1. 동일 언어의 표준 URL — 각 언어 또는 로캘 URL에는 명확한 표준 URL을 지정해야 하며, 중복 페이지가 있다면 같은 언어의 대표 URL을 우선하도록 설정해야 합니다. 완전히 현지화된 페이지를 게시하면서 모든 로캘의 표준 URL을 영어 페이지로 지정하지 마세요.
  2. HTML 또는 사이트맵의 hreflang — XML 사이트맵은 언어 버전을 발견하는 데 도움이 되며, 사이트맵 방식으로 구현할 경우 xhtml:link hreflang 주석을 포함할 수 있습니다.
  3. JSON-LD url과 표준 URL 일치 — /fr/produit의 표준 URL을 자기 자신으로 지정했다면, 스키마의 url은 /en/product이 아니라 해당 URL을 참조해야 합니다.
  4. JSON-LD 내부의 hreflang으로 대체하지 않기 — Google의 hreflang 가이드는 대체 버전을 선언하는 기본 수단으로 스키마가 아닌 링크 요소, HTTP 헤더 또는 사이트맵을 안내합니다.

플러그인이 이 세 계층을 각각 독립적으로 자동 생성한다면, 로캘을 출시할 때마다 교차 검증을 수행하세요.

조직 및 제품 엔터티의 일관성 유지

로캘마다 조직 이름이나 제품 ID를 새로 만들면 다국어 SEO에 문제가 생깁니다. 실무에 적용할 수 있는 엔터티 전략은 다음과 같습니다.

  • 모든 로케일에서 조직별로 하나의 고정된 @id를 사용하고, 표시 속성은 현지화하세요.
  • 제품 SKU 또는 전역 ID는 동일하게 유지하고, 마케팅용 제목은 현지화하세요.
  • 시장별로 다른 에셋이 필요한 경우가 아니라면 동일한 logo URL을 사용하세요. 다른 에셋을 사용한다면 그 이유를 문서화하세요.
  • 특정 시장에서 별도의 인증 계정을 운영하는 경우가 아니라면 sameAs 소셜 프로필을 일관되게 유지하세요.

Google의 유용한 콘텐츠 가이드에서는 사용자 중심 페이지를 우선시합니다. 내용이 부실하거나 상용구로만 구성된 언어 버전은 SEO에도 불리하고 답변의 출처로서도 가치가 낮습니다. 엔터티의 일관성은 시스템이 현지화된 페이지를 알려진 브랜드와 연결하는 데 도움이 되지만, 품질이 낮은 문구까지 보완해 주지는 못합니다.

여러 로케일을 관리하는 팀에는 페이지에 표시되는 문구와 구조화된 데이터 필드에서 용어집의 용어를 일관되게 유지해 주는 다국어 SEO 플랫폼이 도움이 됩니다.

근거 없는 순위 요소를 만들어 내지 않고 살펴보는 답변 엔진에 대한 시사점

답변 엔진과 AI Overviews는 페이지를 요약하거나 인용할 때 구조화된 데이터를 여러 신호 중 하나로 활용할 수 있습니다. 하지만 JSON-LD만으로 인용, 검색 순위 또는 AI Overviews 노출이 보장된다고 명시한 공개 문서는 없습니다.

구조화된 데이터가 실제로 할 수 있는 일:

  • 페이지 유형(Article, FAQPage, Product)을 명확히 나타냅니다.
  • 설명 대상 URL의 inLanguage를 제공합니다.
  • 로케일 간 ID가 일치할 때 일관된 엔터티 인식을 돕습니다.

구조화된 데이터가 할 수 없는 일:

  • 번역되지 않았거나 내용이 부실한 콘텐츠를 보완하는 것.
  • 크롤링 가능한 로케일별 URL이나 hreflang을 대체하는 것.
  • 모든 시장에서 리치 결과 노출을 보장하는 것.

스키마는 순위를 올리는 편법이 아니라, 사용자 중심 페이지를 정확하게 설명하는 메타데이터로 활용하세요.

다국어 스키마에서 흔히 발생하는 실수

  1. 영어가 아닌 언어의 URL에 영어 JSON-LD 사용 — inLanguage 및 텍스트 속성이 원문 언어로 남아 있습니다.
  2. 공통 스키마 템플릿 조각 사용 — 현지화 연동 지점 없이 하나의 CMS 블록을 모든 로케일에 복사합니다.
  3. canonical과 url의 불일치 — 페이지의 canonical은 프랑스어 버전을 가리키는데 스키마는 영어 버전을 가리킵니다.
  4. 잘못된 언어로 작성된 FAQ 스키마 — 마크업의 언어가 화면에 표시되는 FAQ의 언어와 일치하지 않습니다.
  5. 중복된 엔터티 그래프 — 여러 플러그인이 서로 충돌하는 Organization 블록을 삽입합니다.
  6. 존재하지 않는 제품 속성 추가 — 페이지에 없는 판매 제안이나 리뷰를 마크업합니다.
  7. 스키마를 ‘수정’하면서 hreflang은 방치 — 주석과 JSON-LD는 서로 연계되어 작동해야 합니다.
  8. 내용이 부실한 임시 페이지에 완전한 스키마 적용 — 상용구만 번역한 페이지에 정교한 마크업을 적용합니다.

Bing 웹마스터 가이드라인은 시장별 색인 생성을 위해 크롤링 가능하고 유용한 콘텐츠와 명확한 사이트 구조를 강조합니다. 구조화된 데이터가 가치를 더하려면 먼저 이러한 크롤링 가능성 기준을 충족해야 합니다.

구현 체크리스트

새 로케일의 스키마를 일괄 배포할 때마다 다음 체크리스트를 활용하세요.

기존 검색 엔진과 답변 엔진을 위한 기본 원칙

Google, Bing, 답변 엔진 모두에서 공통된 기본 요건은 여전히 중요합니다. 크롤링 가능한 언어 버전, 명확한 엔터티, 근거가 뒷받침되는 주장, 사실에 부합하는 구조화된 데이터, 그리고 영어만 담긴 껍데기가 아닌 실질적인 현지화가 필요합니다. 아래 가이드는 동일한 다국어 제공 기준을 플랫폼별 관점에서 살펴보는 자료로 활용하세요.

Google 검색에서 페이지가 발견되려면 해당 언어에 맞는 HTML, 정확한 제목과 헤딩을 갖춘 크롤링 가능한 로케일별 URL이 필요하며, 대체 언어 버전이 있다면 hreflang으로 서로 참조해야 합니다. 기술적 기반에는 쿠키에만 의존하는 언어 전환 대신 색인 가능한 콘텐츠 제공, 현지화된 메타데이터, 사이트맵, 언어 버전별 일관된 canonical 관리가 포함됩니다. 콘텐츠 품질의 핵심은 각 언어로 제공되는 사용자 중심의 본문입니다. 신뢰도는 번역 도구의 마케팅 주장이 아니라 명확한 조직 정체성과 이를 뒷받침하는 출처에서 나옵니다. 다국어 운영 시 유의점: 시장별 또는 언어별 URL은 Google이 현지 검색어에 대해 순위를 매길 수 있는 완전한 독립 페이지여야 합니다. 로케일별로 Search Console의 색인 범위와 URL 검사를 통해 측정하세요. 확인된 사항과 불확실한 사항: Google은 다국어 및 hreflang의 작동 방식을 문서화하고 있지만, 특정 CMS나 번역 워크플로가 순위를 보장한다고 명시하지는 않습니다.

플랫폼별 가이드: Bing

Bing은 Google의 URL 및 콘텐츠 명확성 요건과 유사하게, 구조가 명확하고 크롤링 가능한 다국어 페이지를 발견하고 색인합니다. 기술적 기반에는 가져올 수 있는 로케일별 URL, 유용한 콘텐츠, 각 속성 또는 인증된 도메인에 대한 Bing Webmaster Tools 모니터링이 포함됩니다. 탐색 메뉴의 언어만 바뀌고 본문은 그대로인 인터페이스 한정 번역보다는 헤딩, 주장, FAQ까지 현지화하세요. 신뢰도 신호는 여전히 믿을 수 있는 출처와 로케일 간 일관된 엔터티에 달려 있습니다. 다국어 운영 시 유의점: 크롤러가 각 언어 버전을 파악할 수 없도록 클라이언트 측 전용 전환 기능이나 단일 URL의 쿠키 기반 전환 뒤에 언어 버전을 숨기지 마세요. Bing Webmaster Tools에서 색인 현황과 크롤링 통계를 측정하세요. 확인된 사항과 불확실한 사항: Bing 가이드라인은 크롤링 가능하고 유용한 콘텐츠를 강조합니다. 번역 도구와 관련해 Bing만의 순위 요소를 임의로 만들어 내지 마세요.

플랫폼별 가이드: ChatGPT

ChatGPT는 언어 버전이 명확하고 답변에 활용하기 좋은 공개 페이지를 인용하거나 요약할 수 있습니다. 페이지가 발견되는 방식은 일반적인 크롤링 기반 순위 산정과 다릅니다. 여기서 노출이란 순위가 매겨진 검색 결과 페이지에 나타나는 것보다 출처로 선택되거나 답변에서 참조되는 것에 가깝습니다. 기술적 기반은 여전히 접근 가능한 HTML URL에서 시작하며, 콘텐츠 수집기가 문구를 읽지 못하게 하는 위젯 오버레이로는 충분하지 않습니다. 도움이 되는 콘텐츠 특성으로는 직접적인 답변, FAQ, 로케일별로 관리하는 용어집에 기반한 일관된 용어 사용이 있습니다. 신뢰도는 근거와 언어 간 일관된 엔터티에서 나옵니다. 다국어 운영 시 유의점: 사용자가 언어를 전환할 것이라고 가정하지 말고, 각 로케일 페이지를 독립적으로 읽을 수 있게 해야 합니다. 측정은 완벽하지 않습니다. 인용 여부 점검은 KPI가 아니라 정성적으로 검증할 가설로 다루세요. 확인된 사항과 불확실한 사항: 구조화된 데이터, hreflang 또는 어떤 번역 워크플로도 ChatGPT의 인용을 보장한다는 문서화된 근거는 없습니다.

플랫폼별 가이드: Gemini

일관된 엔터티, 정확한 구조화된 데이터, 색인 가능한 현지화 페이지는 Gemini 및 관련 Google AI 서비스에 도움이 됩니다. 노출의 핵심은 참조되거나 인식되는 것이며, Gemini만의 순위 요소를 만들어 내는 것이 아닙니다. 기술적 기반은 각 로케일 URL의 크롤링 가능성과 메타데이터 품질 등 Google 검색의 요건과 겹칩니다. 콘텐츠는 각 언어로 명확한 주장과 정의를 제시하고, 사용자를 중심으로 충분한 깊이를 갖춰야 합니다. 신뢰도는 시장 간 조직 정보의 일관성과 이를 뒷받침하는 근거에 달려 있습니다. 다국어 운영 시 유의점: 용어집으로 제품명을 관리하면 검색과 AI 서비스 모두에서 로케일 간 엔터티 혼동을 줄일 수 있습니다. 기존 방식대로 Search Console을 통해 측정하고, 대상 언어의 AI 답변을 표본으로 살펴 정성적으로 평가하세요. 확인된 사항과 불확실한 사항: Gemini의 동작 양상이 hreflang 및 언어 버전에 관한 공식 Google 검색 가이드를 대신할 수는 없습니다.

플랫폼별 가이드: Google AI Overviews

Google AI Overviews는 답변을 뒷받침하는 페이지로 연결될 수 있습니다. 노출 대상이 되기 위한 기본 요건은 여전히 각 언어로 제공되는 사용자 중심의 색인 가능한 콘텐츠입니다. AI Overviews는 언어 전환 기능이 아니며 대체 언어 버전 간 hreflang 주석을 대체하지도 않습니다. 기술적 기반은 크롤링 가능한 로케일별 HTML과 화면에 표시되는 페이지 콘텐츠에 부합하는 사실 기반의 구조화된 데이터입니다. 콘텐츠 측면에서는 각 언어 버전의 간결한 답변과 명확한 헤딩이 중요합니다. 신뢰도 신호는 스키마 마크업만이 아니라 유용한 콘텐츠에 대한 요건을 따릅니다. 다국어 운영 시 유의점: 영어 버전의 성과와 관계없이 어떤 번역 페이지도 AI Overviews 노출을 보장받을 수 없습니다. Search Console에서 생성형 AI 관련 보고서가 제공되는 경우 이를 통해 측정하고, 기존 색인 지표는 별도로 관리하세요. 확인된 사항과 불확실한 사항: 어떤 번역 워크플로도 AI Overviews 노출을 약속할 수 없습니다.

GlotEO의 역할

대규모 스키마 현지화는 개발 작업인 동시에 콘텐츠 운영의 과제입니다. 용어집, 번역된 필드, SEO 주석이 서로 어긋나면 JSON-LD는 언어 혼용 오류가 마지막까지 숨어 있는 곳이 됩니다. GlotEO는 팀이 다국어 SEO 워크플로의 일관성을 유지하도록 도와 구조화된 데이터, hreflang, 페이지 문구에서 동일한 용어와 로케일별 URL을 사용하게 합니다.

여러 로케일에 걸친 관리 체계가 필요하다면 다국어 SEO 플랫폼을 살펴보세요. GlotEO 요금 및 플랜에서 스키마 품질 보증(QA)과 번역 검수를 위한 워크플로 등급도 비교해 보세요.

참고 자료