6-3.多言語サイトの構造化データ設定と検証ポイント

海外SEOにおける多言語サイトの構造化データ対応で最初に押さえるべき点は、各言語ページの表示内容に合わせて個別に設定する必要があるということです。会社の住所や連絡先、商品情報の価格や通貨は、対策する国・言語ごとに異なるためです。海外SEO(多言語SEO)とは？必要な対策とAIO時代の視点を解説の6-3で触れた組織情報や商品情報の構造化データの実装を、言語ごとのページにどう反映するかが実務上の課題になります。

構造化データが海外SEOで果たす役割

構造化データは、通常の検索結果でリッチリザルトの表示対象になるための仕組みです。Googleの一般ガイドラインでは、住所や連絡先、価格や在庫状況といった情報を正しくマークアップすることで、検索結果に商品情報や企業情報を詳しく表示できるようになると案内されています。多言語サイトの場合、この仕組みを対策国ごとに機能させることが、現地の検索結果での見え方を左右します。日本語ページで正しく機能していても、英語ページやタイ語ページで同じ水準の実装ができていなければ、その国の検索結果では恩恵を受けられません。

組織情報の構造化データの多言語展開

組織情報の構造化データ(schema.orgのOrganization)は、各言語ページの会社概要ページに個別に設置し、その言語ページの記載内容と一致させる必要があります。Googleの技術ガイドラインでは、組織情報は法人のホームページや会社概要ページに設置することが推奨されています。多言語サイトの場合、この会社概要ページが言語ごとに存在するため、住所や連絡先を各ページの記載内容に一致させる作業が発生します。

たとえば、日本本社とベトナム現地法人を持つ企業が、日本語ページと英語ページのそれぞれに会社概要を掲載しているとします。この場合、住所情報(addressプロパティ)を配列にして日本とベトナムの両住所を記載し、問い合わせ先情報(contactPointプロパティ)には言語ごとの問い合わせ窓口を分けて設定します。日本語ページの問い合わせ先には日本語対応の電話番号を、英語ページの問い合わせ先には英語対応の窓口を紐づける形です。

ECサイトの場合は、配送設定(hasShippingServiceプロパティ)や返品ポリシー(hasMerchantReturnPolicyプロパティ)もあわせて検討します。たとえば日本国内向けは送料無料、ベトナム向けは注文金額の3%を送料として設定しているとします。この場合、配送条件のなかで配送先の国コードを指定すれば、国ごとに異なる送料設定を一つの組織情報の構造化データのなかで明示できます。返品ポリシーについても、対象国をプロパティ(returnPolicyCountry、applicableCountry)で分けて設定することで、言語ページごとの実際の条件と食い違わない形にできます。

商品情報の構造化データと言語ごとの表記

商品情報の構造化データ(schema.orgのProduct)にも、ページに表示されている内容とマークアップを一致させるという同じ原則が適用されます。Googleは、購入不可のレビューページ向けには商品スニペット(Product snippet)、購入可能なページ向けにはマーチャントリスティング(Merchant listing)という2種類のマークアップの使い分けを案内しています。多言語ECサイトでは、この使い分けに加えて、価格・通貨・在庫状況をページごとの実際の表示内容に合わせる作業が必要になります。

たとえば同じ商品を日本円ページと米ドルページで販売しているとします。それぞれの構造化データに記載する価格情報(priceプロパティ)と通貨コード(priceCurrencyプロパティ)は、そのページで実際に表示されている金額と通貨に一致させる必要があります。日本語ページの構造化データに米ドル建ての価格が残ったまま公開されると、ページの表示内容と構造化データが食い違い、Googleのガイドラインが禁止する「ページに表示されていない内容のマークアップ」に該当するおそれがあります。

対象国の検索エンジンシェアを踏まえた対応も欠かせません。対象国によってはGoogle以外の検索エンジンが一定のシェアを持つ場合があります。商品情報の構造化データはschema.orgの仕様に基づく汎用的な仕組みであるため、Google以外の検索エンジンやAIサービスが対象国で情報を参照する際にも活用される可能性があります。対策国を検討する段階で、現地の主要な検索サービスが構造化データをどう扱っているかも合わせて確認しておくと安心です。

各言語ページへの反映手順

構造化データを複数言語に展開する際は、次の手順で進めると抜け漏れを防ぎやすくなります。

・テキスト値だけを対象言語に翻訳する
JSON-LDの構造自体は言語間で共通のまま、名称(name)や説明文(description)、住所情報(address)などのテキスト値だけを対象言語に翻訳します。自動翻訳をそのまま流し込むのではなく、キーワード・コンテンツ設計の章で触れたネイティブスタッフによる確認を、構造化データのテキストにも適用します。

・hreflangとURLを一致させる
hreflangで指定したURLと、構造化データ内に記載するURLを一致させます。hreflangの実装とJSON-LDの実装を別々の担当者が進めると、リンク先が食い違うケースが起こりやすいため、公開前の突き合わせが欠かせません。

・リッチリザルト テストを言語ごとに実行する
リッチリザルト テスト(Rich Results Test)を言語ごとのURLで個別に実行します。日本語ページで検証が通っていても、英語ページのJSON-LDにコピー漏れがあれば、そのページ単体では検証エラーになります。

・Search Consoleを国・言語別に確認する
Search Consoleの拡張機能レポートを国・言語別に確認します。効果測定体制の章で触れた考え方と同様に、構造化データのエラーも言語ごとに追わないと、特定の言語ページだけエラーが埋もれてしまいます。
なお、schema.orgには言語コードを明示するinLanguageというプロパティがあり、コンテンツの言語をコードで指定できます。ただしこのプロパティは、Googleの組織情報や商品情報の公式ガイドラインには記載がなく、リッチリザルトの表示可否に直接影響するものではありません。設定しても損はありませんが、優先すべきは前述のテキスト翻訳とURLの整合性です。

見落としやすい注意点

多言語サイトの構造化データで起こりやすい問題は、言語ページを追加する際に、既存言語のJSON-LDをそのままコピーして公開してしまうことです。テキスト値が翻訳されていないコピーは、ページの表示内容と一致しないマークアップとして、Googleのガイドライン違反にあたる可能性があります。

もう一つの見落としが、価格改定やセール情報を更新した際に、一部の言語ページのJSON-LDだけ更新が漏れるケースです。表示価格とマークアップ上の価格が食い違った状態が続くと、リッチリザルトの対象から外れるリスクがあるため、価格変更時のチェック項目に構造化データの更新をあらかじめ組み込んでおくことをおすすめします。

まとめ

多言語サイトにおける構造化データ対応は、言語ごとのページで表示内容とマークアップを一致させる地道な運用が中心になります。組織情報と商品情報のいずれも、住所・連絡先・価格・返品条件といった要素を言語ごとの実態に合わせて設定し、hreflangとの整合性を保ちながら言語ごとに検証することが、海外SEOの土台を固めるうえで確実な進め方です。

自社サイトの海外SEO対策はできていますか？
KollegaのSEO診断は、わずか1分で多言語SEO対応現状を確認することができます。
ご興味のある方はお気軽にお試しください。

• Tweet
• 
•