多言語の構造化データ：ロケール別URLごとにJSON-LDをローカライズ

クロール可能なロケール別URLごとにschema.orgのJSON-LDをローカライズし、inLanguageやエンティティをhreflangと整合させる方法を解説。根拠のない検索順位向上をうたうことなく、多言語の構造化データの品質を検証します。

Grant Davies更新日

多言語の構造化データ：白いグリッド上に配置されたJSON-LDのノードグラフ。各エンティティにinLanguageのラベルが付いている

JSON-LDを、すべてのロケールURLに貼り付けるサイト共通の英語スニペットとして扱うと、多言語の構造化データで誤りが生じやすくなります。検索エンジンや回答エンジンは、構造化データを特定のURLにあるページの説明として読み取ります。フランス語の商品ページに、依然としてinLanguage: en、英語のname値、米国サイトからコピーした正規のエンティティグラフが記述されていると、矛盾するシグナルを送ることになり、従来のインデックス登録にも、回答エンジンによる明確な理解にも悪影響を及ぼします。

このガイドでは、Googleの多言語サイトに関するドキュメントと、実態に即したスキーマの実装方針に基づき、クロール可能な各ロケールURLでschema.orgマークアップをローカライズする方法、JSON-LDをhreflangやcanonicalと整合させる方法、組織や商品のエンティティの一貫性を保つ方法、多言語スキーマの公開時に品質を確認する方法を解説します。根拠のない順位向上はうたいません。構造化データはシステムによるコンテンツの理解を助けますが、内容の乏しい翻訳を補うものではありません。

このガイドでわかること

  • 言語別URLごとに構造化データをローカライズする必要があるのはなぜですか？
  • inLanguageと他言語版のページはどのように表現すべきですか？
  • 多言語サイトで特に重要なスキーマタイプは何ですか？
  • hreflangやcanonicalは構造化データとどのように関係しますか？
  • どのようなミスが、言語の混在やエンティティの重複マークアップを引き起こしますか？
  • ロケール間で組織や商品のエンティティの一貫性を保つにはどうすればよいですか？
  • 根拠のないランキング要因を持ち出さずに、構造化データは回答エンジンをどう支援できるのでしょうか？
  • 多言語スキーマの公開時には、どのような品質チェックが必要ですか？

要点：クロール可能な各ロケールURLでスキーマをローカライズする

端的に言うと：クロール可能なすべてのロケールURLで、その言語で表示されるページの内容を正確に記述したJSON-LDを出力します。正しいinLanguage、ローカライズされたテキストプロパティ、正確なurl、市場間で一貫したエンティティ識別子が必要です。

Googleは、Cookieやブラウザの言語設定だけに頼るのではなく、言語版や地域版ごとに異なるクロール可能なURLを用意することを推奨しています。構造化データは、サイト全体に挿入される共通の英語テンプレートではなく、そのURLでユーザーやクローラーが実際に見るページを記述する必要があります。

各ブロックには、画面に表示される主要コンテンツと同じ言語を反映させる必要があります。Googleは主に表示コンテンツからページの言語を判断するため、本文と矛盾するスキーマは、クローラーに不要な整合性確認の負担をかけます。

構造化データを言語版の設計に合わせる理由

構造化データは、URL設計から独立した国際SEOのレイヤーではありません。URL設計を反映するものです。/de/produkt/widgetを公開するなら、そのURLのJSON-LDはドイツ語のページを記述する必要があります。タイトルや説明、該当する場合はオファーをドイツ語にし、inLanguageにはdeやde-DEなどの有効なBCP 47タグを設定します。

言語版ごとに、個別のクロール可能なURLが必要です。構造化データは、共通の英語テンプレートではなく、そのURLでユーザーやクローラーが見るページを記述する必要があります。CMSがサイト全体で共通のスキーマパーツを出力していると、すべてのロケールに英語のエンティティ名が引き継がれます。これは、言語の混在によるリッチリザルトの表示資格の問題や、回答エンジンの要約の質が低下する原因としてよく見られます。

hreflangは別の言語版や地域版の存在を検索エンジンに伝え、構造化データは現在のページの内容を伝えます。どちらも、各URLが別言語を装った重複ページではなく、完全な言語版であることを一貫して示す必要があります。

言語ターゲティングと国別ターゲティングの戦略上の違いについては、国際SEOと多言語SEOの違いをご覧ください。

主要なプロパティ：inLanguage、url、エンティティの識別情報

各ロケールのテンプレートでは、まず次の3つのプロパティを重点的に確認しましょう。

inLanguage — ページに合った有効な言語コードまたはロケールコードを使用します。ローカライズ済みのURLに英語の設定を残さないでください。地域別の言語バリエーション（en-GBとen-USなど）を対象とする場合は、hreflangのコードと一致させます。

url — 記述対象のページの正規URLに解決される必要があります。通常は、そのロケールでブラウザのアドレスバーに表示されるURLであり、英語版のトップページではありません。

エンティティの@idまたは固定の識別子 — 組織や商品のエンティティでは、人が読むプロパティをローカライズしつつ、ロケール間で一貫したID（https://example.com/#organization）を使用する必要がある場合が多くあります。一貫したIDは、言語が異なっても同じブランドやSKUであることをシステムが認識する助けになります。ローカライズされたnameやdescriptionのフィールドには、各市場の言語を反映させます。

1つのURLに、矛盾するエンティティ定義を重複して記述しないようにしましょう。異なるプラグインが挿入する3つの競合するブロックより、ページごとに整合性の取れた1つのOrganizationグラフを用意する方が明快です。

ローカライズが必要になりやすいスキーマタイプ

すべてのスキーマタイプに翻訳が必要なわけではありませんが、多言語サイトでは次のタイプで必要になることがよくあります。

  • WebPage / Article / BlogPosting — headline、description、inLanguage、url。
  • Product — name、description、offers。通貨や在庫状況のテキストも適切に設定します。
  • FAQPage — 質問と回答は、そのページの言語で実際に表示されるFAQの内容と一致している必要があります。
  • Organization — 市場によって法人名や商号が異なる場合はnameをローカライズし、@idは一貫させます。
  • BreadcrumbList — ナビゲーションと一致する、ローカライズされたパンくずリストのラベル。
  • LocalBusiness — 該当する場合は、ロケールに適した住所とareaServed。

基盤となるのは、あくまでユーザーを第一に考えた有用なコンテンツです。構造化データは、内容の乏しい翻訳を補うのではなく、ローカライズされたコンテンツを正確に反映する必要があります。中身のない仮ページをマークアップしても、有用なページにはなりません。

hreflang、canonical、JSON-LDの整合性

hreflangアノテーションは、別の言語版や地域版のURLをGoogleに伝えるもので、対象となるページ群の間で相互に指定する必要があります。canonicalは、同じ言語の重複ページの中で、どのURLを優先すべきかをGoogleに伝えます。JSON-LDは、どちらのシグナルとも矛盾しないようにする必要があります。

整合性を保つための実践的なルール：

  1. 同じ言語のcanonical — 各言語・ロケールのURLには、明確なcanonicalを設定する必要があります。重複ページがある場合は、同じ言語の優先URLを指定します。完全にローカライズされたページを公開しているのに、すべてのロケールのcanonicalを英語版に向けないでください。
  2. HTMLまたはサイトマップでのhreflang — XMLサイトマップは各言語版の発見を助けます。実装方法としてサイトマップを使用する場合は、xhtml:linkのhreflangアノテーションを含めることができます。
  3. JSON-LDのurlをcanonicalと一致させる — /fr/produitに自己参照canonicalを設定する場合、スキーマのurlもそのURLを参照し、/en/productを参照しないようにします。
  4. JSON-LD内のhreflangで代用しない — Googleのhreflangガイダンスでは、代替ページを宣言する主な手段として、スキーマではなくlink要素、HTTPヘッダー、サイトマップを取り上げています。

プラグインがこれら3つのレイヤーをそれぞれ独立して自動生成する場合は、各ロケールの公開後に相互の整合性を確認しましょう。

組織と商品のエンティティの一貫性を保つ

各ロケールで別々の組織名や商品IDを新たに作ってしまうと、多言語SEOはうまく機能しません。実践的なエンティティ戦略は次のとおりです。

  • ロケールをまたいで組織ごとに1つの固定の@idを使用し、表示用のプロパティをローカライズします。
  • 商品のSKUやグローバルIDは変更せず、マーケティング用の商品名をローカライズします。
  • 市場ごとに異なる素材が必要な場合を除き、同じlogoのURLを使用します。異なる素材を使う場合は、その理由を記録します。
  • 市場ごとに個別の認証済みアカウントを運用している場合を除き、sameAsに指定するSNSプロフィールを統一します。

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 Webmaster Guidelinesでは、各市場でのインデックス登録において、クロール可能で有用なコンテンツと明確なサイト構造が重視されています。構造化データが価値を発揮するには、まずこのクロール可能性の基準を満たす必要があります。

実装チェックリスト

新しいロケール向けのスキーマをまとめて公開する際は、毎回このチェックリストを活用してください。

従来の検索と回答エンジンに共通する基盤

Google、Bing、回答エンジンのいずれでも、共通の基盤は引き続き重要です。クロール可能な各言語版、明確なエンティティ、根拠のある主張、実態に即した構造化データ、そして英語のままの外枠ではなく、実質的なローカライズが求められます。以下のガイドは、同じ多言語配信の基準をプラットフォーム別の視点から捉えたものとして活用してください。

Google Searchでページが検出されるには、対象言語に適したHTMLを持つクロール可能なロケール別URL、正確なタイトルと見出し、そして別言語版がある場合は相互参照するhreflangが必要です。技術面の基盤となるのは、Cookieだけに依存した切り替えではなくインデックス可能なコンテンツ、ローカライズされたメタデータ、サイトマップ、各言語版での適切なcanonical管理です。コンテンツ品質の要は、各言語でユーザーを第一に考えた本文を用意することです。権威性は、組織の実体が明確であることや裏付けとなる情報源から生まれるものであり、翻訳ツールの宣伝文句で得られるものではありません。多言語対応では、各市場・言語のURLが、それぞれ単独で完全なページとして成立し、Googleが現地の検索クエリに対して順位を付けられる必要があります。測定には、ロケールごとにSearch ConsoleのカバレッジとURL検査を使用します。確かなことと不確かなことを区別しましょう。Googleは多言語対応やhreflangの動作を文書化していますが、特定のCMSや翻訳ワークフローによる検索順位を保証してはいません。

プラットフォーム別ガイド：Bing

Bing は、Google が URL とコンテンツの明確さを求めるのと同様に、クロール可能で構造が明確な多言語ページを検出し、インデックスに登録します。技術面の基盤となるのは、取得可能なロケール別 URL、有用なコンテンツ、そしてプロパティまたは確認済みドメインごとに Bing Webmaster Tools で監視することです。ナビゲーションだけが別の言語に切り替わり、本文は変わらないといったインターフェースのみの翻訳ではなく、見出し、訴求内容、よくある質問もローカライズしましょう。権威性のシグナルは、引き続き信頼できる情報源と、ロケール間でのエンティティの一貫性に左右されます。多言語展開では、クローラーが各言語版を把握できない、クライアント側のみの切り替えや単一 URL での Cookie による切り替えに言語版を隠さないようにしてください。Bing Webmaster Tools で、インデックス登録状況とクロール統計を確認しましょう。確実な点と不確実な点を区別することも重要です。Bing のガイドラインは、クロール可能で有用なコンテンツを重視しています。翻訳ツールについて、Bing 独自のランキング要因を根拠なく作り上げてはいけません。

プラットフォーム別ガイド：ChatGPT

ChatGPTは、言語版が明確で、回答に使いやすく整理された公開ページを引用・要約する場合があります。ページの発見は、従来のクロールに基づく順位付けとは異なります。露出とは、検索結果ページで順位付きで表示されることではなく、情報源として選ばれたり、回答内で参照されたりすることです。技術面の出発点は、引き続きアクセス可能なHTMLのURLであり、取得側からテキストを隠してしまうウィジェット型のオーバーレイではありません。有用なコンテンツの特徴には、端的な回答、FAQ、ロケールごとに管理された用語集による一貫した用語の使用があります。権威性は、根拠と、言語をまたいで一貫したエンティティ情報から生まれます。多言語対応では、ユーザーが言語を切り替えることを前提にせず、各ロケールのページが単独で理解できる必要があります。測定は完全ではありません。引用の確認はKPIではなく、定性的な仮説の検証として扱いましょう。確かなことと不確かなことを区別する必要があります。構造化データ、hreflang、または特定の翻訳ワークフローによってChatGPTでの引用が得られるという、文書化された保証はありません。

プラットフォーム別ガイド：Gemini

Geminiや関連するGoogleのAI機能では、一貫したエンティティ情報、正確な構造化データ、インデックス可能なローカライズ済みページが役立ちます。露出とは、参照されたり認識されたりすることであり、Gemini専用のランキング要因を作り上げることではありません。技術面の基盤は、各ロケール別URLにおけるGoogle Searchのクロール可能性やメタデータの品質と共通しています。コンテンツでは、各言語で主張や定義を明確に示し、ユーザーを第一に考えた十分な内容を提供する必要があります。権威性は、市場をまたいで組織情報が一貫していることと、裏付けに依存します。多言語対応では、用語集で管理された製品名を使うことで、検索でもAI機能でも、ロケール間のエンティティの混同を減らせます。従来どおりSearch Consoleで測定するとともに、対象言語のAI回答を抽出して定性的に確認しましょう。確かなことと不確かなことを区別する必要があります。Geminiの挙動は、hreflangや言語版について文書化されたGoogle Searchのガイダンスに代わるものではありません。

プラットフォーム別ガイド：Google AI Overviews

Google AI Overviewsは、回答を裏付けるページへのリンクを表示する場合があります。掲載対象となるための基本は、引き続き各言語でユーザーを第一に考えた、インデックス可能なコンテンツです。言語切り替えの機能ではなく、別言語版間のhreflangアノテーションに代わるものでもありません。技術面の基盤となるのは、引き続きクロール可能なロケール別HTMLと、ページ上に表示される内容に合致した正確な構造化データです。コンテンツの重要な要素には、各言語版の簡潔な回答と明確な見出しがあります。権威性を示す要素は、スキーママークアップだけではなく、有用なコンテンツに求められる基準に沿ったものです。多言語対応では、英語版の成果にかかわらず、翻訳ページがAI Overviewsに掲載される保証はありません。Search Consoleで生成AI関連のレポートが利用できる場合はそれを使って測定し、従来のインデックス指標とは分けて管理しましょう。確かなことと不確かなことを区別する必要があります。どのような翻訳ワークフローでも、AI Overviewsへの掲載を約束することはできません。

GlotEOが担う役割

大規模なスキーマのローカライズは、開発者の作業であると同時に、コンテンツ運用の課題でもあります。用語集、翻訳済みフィールド、SEOアノテーションの間にずれが生じると、JSON-LDは言語混在の不具合が最後まで潜む場所になりがちです。GlotEOは、チームの多言語SEOワークフローの整合性を保ち、構造化データ、hreflang、ページ上のテキストで用語とロケール別URLを統一できるよう支援します。

多数のロケールを横断して管理体制を整える必要がある場合は、多言語SEOプラットフォームをご覧ください。また、GlotEOの料金とプランで、スキーマの品質確認や翻訳レビューに対応するワークフローのプラン別機能を比較できます。

参考文献