多言語サイトSEOの基本：hreflangと地域別ページ設計を解説

多言語サイトのSEO対策は、日本語サイトを英語や中国語に翻訳するだけではうまくいきません。

翻訳したページを公開すれば海外からの検索流入が増える、と思われることがあります。もちろん翻訳は必要です。しかし、実務ではそれだけでは足りません。どの国・地域のユーザーに届けるのか、どの検索語で探されるのか、どのURLで管理するのか、どのページ同士をhreflangで対応させるのか、問い合わせや資料請求の導線をどう置くのかまで設計する必要があります。

結論から言うと、多言語サイトSEOで重要なのは、翻訳ではなく、市場別の検索意図と問い合わせ導線を設計することです。hreflangは大切ですが、hreflangだけで海外SEOが成功するわけではありません。言語、国、URL、canonical、翻訳品質、現地の商習慣、CTA、計測までつながって初めて、海外向けサイトのSEO施策として機能します。

特にBtoB企業の場合、海外からの流入を増やすだけでは意味がありません。==多言語サイトSEOは「海外から見られるページ」を作る施策ではなく「海外の見込み顧客が理解し、比較し、問い合わせできる状態を作る施策」==として考える必要があります。

Google検索セントラルのページのローカライズ版では、複数の言語・地域向けページがある場合に、Googleへその対応関係を伝える方法としてhreflangが説明されています。また、多地域・多言語サイトの管理でも、異なる言語や地域向けに異なるコンテンツを出すサイトの扱いが整理されています。

一般的なSEO基礎だけでは、海外向けサイトの判断材料は足りません。ここでは、海外向けサイトや多言語サイトを持つ企業が、検索流入から問い合わせ・商談までをつなげるために確認すべき順番を整理します。

AI検索で多言語サイトSEOを調べる読者は、「何から決めるべきか」「hreflangとcanonicalをどう併用するか」「英語ページと国別ページはどう分けるか」を短時間で知りたい状態にあります。まずは、翻訳前に対象市場、URL方式、対応ページ、現地CTA、計測単位を決め、hreflangは対応関係を伝えるもので順位改善の単独施策ではないと押さえてください。

本記事は、一般的な生成AI活用やGEO対策そのものを説明する記事ではありません。生成AI研修とAIコンサルの違い、GEO対策の基本とは役割を分け、ここでは多言語サイトSEOの国別ページ設計とhreflang実務に絞ります。

多言語SEOは翻訳ではなく市場別の検索意図設計で考える

多言語SEOで最初に整理したいのは、翻訳対象のページではなく、対象市場の検索意図です。

日本語ページを英語に翻訳して公開すると、見た目としては多言語サイトになります。しかし、海外の検索ユーザーが同じ言葉、同じ比較基準、同じ導線で判断するとは限りません。日本語では自然な表現でも、英語圏では別の言い方で検索されることがあります。国内向けの料金表や導入事例が、海外のBtoB担当者には判断材料にならないこともあります。

多言語サイトSEOでは、次のように市場別に分けて考えます。

多言語SEOは、日本語コンテンツを別言語に置き換える作業ではなく、対象市場の検索行動に合わせてページの役割を作り直す作業です。 ここを飛ばすと、ページは読めるのに問い合わせにつながらない状態になりやすいです。

たとえば、国内向けの「SEO対策」という言葉をそのまま英語にすると「SEO measures」になりがちですが、英語圏の実務では「SEO strategy」「SEO services」「technical SEO」「international SEO」など、文脈によって使われる表現が変わります。

製造業向けの製品ページであれば、国内では「導入事例」が重要でも、海外では「distributor」「compliance」「shipping」「support」「case study」などが判断材料になる場合があります。

ワンポイントアドバイス: 最初に確認するのは「何語に翻訳するか」ではなく「どの市場で、誰に、何を問い合わせてもらうか」です。言語数を増やす前に、商談導線まで決めてください。

==海外向けBtoBサイトでは、翻訳範囲より先に、対象市場、検索意図、問い合わせ導線、営業対応範囲を決める==ことが重要です。

この記事もおすすめ｜生成AI研修とAIコンサルの違い：研修だけで終わらせない導入設計｜本記事では多言語SEOに範囲を絞るため、生成AI活用の教育・導入設計は別記事で確認できます。｜

多言語サイトで最初に決める言語・国・導線

多言語サイトSEOでは、「英語ページを作る」と「米国向けページを作る」は同じではありません。

英語は言語です。米国、英国、シンガポール、インド、オーストラリアは国や地域です。同じ英語でも、商習慣、表記、法務、価格、通貨、問い合わせ導線、競合、検索語が変わることがあります。hreflangでも、言語だけを指定する場合と、言語と地域を組み合わせて指定する場合があります。

アズくんワンポイント: え、英語ページと米国向けページって同じじゃないの？ぼく、最初そこがいちばん混乱しました…！

最初に決めるべき項目は次の通りです。

多言語SEOでは、言語、国、URL、問い合わせ導線を先に決めないと、後からhreflangやcanonicalの整合性が崩れやすくなります。 特に途中で国別ページを増やす場合、最初のURL設計が弱いと移行コストが高くなります。

たとえば、最初は英語ページだけを作る場合でも、将来的に米国向け、英国向け、シンガポール向けなどを分ける可能性があるなら、URLやページ設計に余地を残しておきます。/en/ だけで十分なのか、/us/ や /sg/ を作るべきなのか、言語軸と地域軸をどう扱うのかを決めます。

Googleのローカライズ版ページのドキュメントでは、英語でも en-gb、en-us、en のように、言語と地域を組み合わせた例が示されています。これを記事本文で機械的に真似るのではなく、自社の市場展開に合わせて、どの粒度で分けるべきかを考える必要があります。

ターゲット国の選定と優先順位付けでは、検索ボリュームだけでなく、営業対応範囲、現地法務、代理店有無、問い合わせ後の商談化率まで確認します。ここを決めずに多地域SEOの基本概念だけを追うと、ページ数は増えても更新責任者が曖昧になります。国別ページと本社グローバルページをどう役割分担するかの判断が薄い状態では、海外向けサイトを持つBtoB企業がどの市場から多言語SEOへ投資すべきかも決まりません。

海外BtoBでは、営業対応範囲も重要です。ページを作っても、英語問い合わせに対応できない、時差対応ができない、現地通貨や契約条件を説明できない場合、CVしても商談化しにくくなります。SEOだけでなく、営業・サポート・法務・物流の受け皿まで確認します。

URL設計は将来の運用体制まで見て決める

多言語サイトのURL設計には、いくつかの方法があります。

代表的なのは、サブディレクトリ、サブドメイン、国別ドメインです。それぞれに良し悪しがあり、SEOだけでなく、CMS、翻訳管理、現地法人の運用、計測、広告、法務、ドメイン管理まで影響します。

URL設計は、今の翻訳しやすさだけでなく、将来の市場追加、現地更新、計測、広告連携まで見て決めるべきです。 小さく始めるならサブディレクトリが扱いやすいことが多いですが、現地法人が独立して運用する場合は別の設計が必要になることもあります。

Googleの多地域・多言語サイトの管理では、異なる国や地域のユーザーに合わせたサイト構造の考え方が整理されています。重要なのは、検索エンジンに対象市場を伝えることだけでなく、ユーザーが自分に合ったページを見つけやすい状態を作ることです。

実務上は、次のような判断をします。

• 海外展開がまだ限定的なら、まずは /en/ で主要ページを整える
• 国別に価格、法務、事例、営業担当が変わるなら、国別ページを検討する
• 現地法人が独自にサイトを運用するなら、サブドメインやccTLDも検討する
• CMSや翻訳管理が弱い場合は、複雑なURL構造を先に作らない
• Search Console、GA4、広告の計測単位をURL構造と合わせる

CMSやMA連携があるサイトでは、言語別フォーム、資料請求、メール配信、CRM連携までURL方式に影響します。SEO担当だけで決めると、公開後に「計測できない」「担当部署が更新できない」という問題が出やすくなります。

!!後から全言語ページのURLを大きく変える作業は、リダイレクト、canonical、hreflang、内部リンク、サイトマップ、広告LP、計測設定まで影響します。!! 多言語化の初期段階でも、将来の運用体制を見てURLを決めることが大切です。

hreflangは言語・地域ページの対応関係を伝える

hreflangは、多言語サイトSEOでよく出てくる技術要素です。

簡単に言うと、hreflangは「このページには別言語・別地域向けの対応ページがあります」とGoogleに伝えるための指定です。日本語ページ、英語ページ、米国向け英語ページ、シンガポール向け英語ページなどがある場合、それぞれが対応関係を示すことで、検索ユーザーに適したページを表示しやすくします。

Googleのローカライズ版ページのドキュメントでは、hreflangの指定方法としてHTML、HTTPヘッダー、サイトマップの3つが示されています。実務では、HTMLのhead内、またはXMLサイトマップで管理するケースが多いです。

hreflang属性の基本と役割の解説で重要なのは、指定方法そのものよりも、対応ページの組み合わせを崩さないことです。hreflangの実装方法には、headタグ、XMLサイトマップ、PDFなどHTML以外で使うHTTPヘッダーがあります。

CMSでページ単位に管理するのか、サイトマップで一括管理するのか、HTTPヘッダーの実装比較まで見て、更新時に破綻しない方法を選びます。

hreflangの確認は、現在のSearch Consoleでは専用の旧International Targetingレポートだけに依存できません。Search Consoleでのインデックス状況、ページ検査、サイトマップ、検索パフォーマンス、クロールログを組み合わせて確認します。

「設定したから終わり」ではなく、Googleが対象ページを認識し、対象国・言語からの表示とクリックが出ているかまで見ることが重要です。

hreflangで確認したい基本は次の通りです。

==hreflangはランキングを直接上げる魔法ではなく、言語・地域別ページの対応関係を伝えるためのシグナル==です。設定していないから必ず検索に出ないわけではありませんが、ページが複数言語・複数地域に分かれるほど、明示しておいた方が管理しやすくなります。

また、言語タグは適当に書いてよいものではありません。IETFのRFC 5646では、言語タグの仕様が定義されています。記事内で細かい仕様をすべて覚える必要はありませんが、en-US、en-GB、ja のような表記はルールに沿って扱う必要があります。

Googleは、hreflangやHTMLのlang属性だけでページの言語を検出するわけではなく、アルゴリズムで判断します。だからこそ、hreflangを入れるだけでなく、ページ本文、タイトル、見出し、内部リンク、CTA、フォーム、問い合わせ導線まで、その言語・地域向けに自然な状態にしておくことが大切です。

canonicalとhreflangを矛盾させない

多言語サイトでよくある技術的な失敗が、canonicalとhreflangの矛盾です。

canonicalは正規URLを伝える指定です。重複または類似したURLの中で、どのURLを正規のURLとして扱ってほしいかを示します。一方で、hreflangは、言語や地域が異なる対応ページの関係を伝えるための指定です。この2つの役割を混同すると、英語ページなのに日本語ページへcanonicalしてしまう、hreflangで指定したページがcanonical先ではない、という問題が起きます。

基本的には、各言語・地域ページは自分自身をcanonicalにし、そのうえでhreflangで対応ページを示します。

canonicalは正規URLを伝えるための指定であり、hreflangは言語・地域別の対応関係を伝えるための指定です。 この役割を分けて考えると、矛盾を避けやすくなります。

Googleのcanonical URLの指定方法では、canonicalの考え方や、代替バージョンの指定には適切なlink annotationを使うことが説明されています。多言語サイトでは、canonicalとhreflangを別の役割として扱うことが重要です。

よくある危険な設定は次の通りです。

• 英語ページのcanonicalが日本語ページを向いている
• hreflangで指定しているページがnoindexになっている
• AページからBページを指定しているが、BページからAページへ戻っていない
• サイトマップのhreflangとHTML内のhreflangが異なる
• リダイレクト先や404ページをhreflangに入れている

!!英語ページを日本語ページへcanonicalする設定は、英語ページを検索結果に出したい場合には避けるべきです。!! これをやると、Googleに対して「英語ページではなく日本語ページが正規です」と伝える形になり、多言語ページの目的と矛盾することがあります。

翻訳品質は検索意図・CTA・専門用語まで合わせる

多言語サイトSEOでは、翻訳品質もSEOの一部です。

ここでいう翻訳品質は、文法が正しいかだけではありません。検索ユーザーが使う言葉になっているか、業界用語が自然か、比較検討に必要な情報があるか、CTAが現地の行動に合っているか、フォームや問い合わせ導線が使いやすいかまで含みます。

確認したい項目は次の通りです。

翻訳された文章が読めても、検索意図やCTAがずれていれば、多言語SEOとしては弱くなります。 海外向けBtoBサイトでは、商品説明、導入事例、FAQ、資料請求、問い合わせフォームまで、現地ユーザーが判断できる状態にする必要があります。

たとえば、日本語サイトでは「無料相談」というCTAが自然でも、海外向けページでは「Request a consultation」「Contact sales」「Book a demo」「Download brochure」など、サービス内容や商談プロセスに合わせた表現が必要になります。

日本語では「導入事例」で通じても、英語では「Case studies」「Customer stories」などが自然な場合があります。

ワンポイントアドバイス: BtoBの多言語SEOでは「翻訳チェック」よりも「問い合わせ前の判断材料チェック」を優先してください。読者が社内で比較できる情報があるかを見ると、修正範囲を絞れます。

翻訳フローと更新責任者も先に決めます。翻訳者、現地監修者、SEOレビュー担当、CMS更新担当が分かれている場合、誰がタイトル、CTA、FAQ、事例、フォーム文言を最終確認するのかを表にしておくと、公開後の修正が止まりにくくなります。

==機械翻訳は初期制作の補助にはなりますが、検索意図、専門用語、CTA、現地の比較基準まで整える作業は別工程として設計する==方が安全です。

地域別ページは現地の商習慣と問い合わせ導線を反映する

国別・地域別ページを作る場合は、言語だけでなく現地の商習慣も反映します。

米国向け、シンガポール向け、タイ向け、欧州向けなど、対象市場が変わると、価格表示、資料請求、問い合わせ方法、導入事例、法務表記、サポート時間、販売代理店、配送・提供範囲が変わることがあります。これらを日本語サイトの直訳で済ませると、海外の見込み顧客が判断できません。

地域別ページで確認したい情報は次の通りです。

地域別ページは、国名を差し替えるページではなく、その市場の読者が問い合わせ前に確認したい情報を整理するページです。 同じ英語ページでも、米国向けとシンガポール向けで訴求や導線が変わることがあります。

たとえば、SaaSであれば、データ保管場所、セキュリティ、サポート時間、英語対応、導入プロセスが重要になります。製造業であれば、代理店、輸出、規格、納期、保守、現地パートナーが重要になることがあります。コンサルティングサービスであれば、オンライン対応、契約単位、英語でのレポート、現地法人との連携が判断材料になります。

海外向けページを作るときは、国内向けページの翻訳から始めても構いません。ただし最終的には、対象市場の読者が「自社でも依頼できるか」「問い合わせしてよいか」を判断できる情報へ変える必要があります。

この記事もおすすめ｜GEO対策とは？生成AI検索に引用されやすい情報設計の基本｜AI検索で引用されやすい情報設計そのものは、GEO対策の記事へ役割を分けています。｜

多言語サイトの内部リンクと切り替えUIを整える

多言語サイトでは、内部リンクと言語切り替えUIも重要です。

hreflangは検索エンジンに対応関係を伝える仕組みですが、ユーザーがページ上で言語を切り替えられなければ不便です。また、英語ページから日本語ページへ戻れない、言語切り替えがトップページにしか向かない、対応ページではなく別ページへ飛ぶ、といった状態はユーザー体験を悪くします。

確認したい導線は次の通りです。

多言語サイトの言語切り替えは、トップページへ戻すだけではなく、可能な限り対応するページへ移動できるように設計します。 日本語のサービスページを見ている人が英語に切り替えたら、英語のサービスページへ移動する方が自然です。

Googleのローカライズ版ページのドキュメントでも、言語・地域別ページの対応関係を明示する考え方が示されています。ユーザー向けの導線と検索エンジン向けのhreflangが同じ対応関係を示していると、管理もしやすくなります。

多言語サイトでは、内部リンクも注意が必要です。英語ページの本文から日本語ページばかりへリンクしていると、英語ユーザーは迷います。英語ページには英語の関連ページ、米国向けページには米国向けの資料・事例・問い合わせ導線を置く方が自然です。

Search ConsoleとGA4で国別・言語別に成果を見る

多言語サイトSEOでは、成果を全体流入だけで見ない方がよいです。

日本語サイトと英語サイトの流入が合算されていると、海外向けページが伸びているのか、国内流入が増えただけなのか分かりません。国別、言語別、ページ別、クエリ別、CV別に分けて見る必要があります。

確認したいデータは次の通りです。

GoogleのSearch Consoleパフォーマンスレポートでは、クリック、表示回数、CTR、掲載順位を確認できます。多言語サイトでは、ページフィルタや国フィルタを使い、対象言語・対象市場のページがどの検索語で見られているかを確認します。

国別CV計測では、Search Consoleの国別・ページ別データ、GA4の言語・国・CVデータ、CRM/SFAの商談化率を分けて見ます。自然検索流入とCVを見る具体的な確認手順は、次の記事で補足できます。

Search Consoleは検索入口、GA4はサイト内行動、CRM/SFAは商談・受注を確認するために使い分けます。 海外向けSEOでは、流入だけでなく、問い合わせ内容、商談化率、受注単価まで見ることが重要です。

たとえば、英語ページの表示回数は増えているのにクリック率が低い場合、titleやmeta descriptionが検索意図に合っていない可能性があります。英語ページへの流入はあるのに問い合わせが少ない場合、CTA、フォーム、価格、導入事例、問い合わせ後の対応言語が不十分かもしれません。

問い合わせはあるのに商談化しない場合、対象国や対象業界がずれている可能性があります。

==多言語SEOの改善は、国別・言語別・ページ別・導線別に分けて見ないと、どの市場を伸ばすべきか判断できません。== 全体平均だけで見ると、国内流入に海外向けページの課題が埋もれます。

多言語SEOでよくある失敗と改善方向

多言語サイトSEOで成果が出ない場合、原因はhreflangの有無だけではありません。

機械翻訳だけで公開している、URL設計が曖昧、canonicalとhreflangが矛盾している、言語切り替えが対応ページへ向かない、海外向けの問い合わせ導線がない、フォームが国内仕様のまま、Search ConsoleやGA4で国別に見ていない。

こうした問題が重なると、海外向けページはあるのに成果が見えにくくなります。

よくある失敗と改善方向は次の通りです。

多言語SEOの失敗は、技術設定だけでなく、翻訳、導線、営業対応、計測がつながっていないことで起きます。 hreflangを正しく入れても、ページ内容やCTAが現地ユーザーに合っていなければ問い合わせにはつながりません。

注意したいのは、国内ページをそのまま翻訳して「海外向けページ」と呼んでしまうことです。国内の導入事例、国内法務、国内価格、国内サポート前提の情報だけでは、海外の見込み顧客は判断しにくいです。

Google検索セントラルのx-defaultに関するブログでは、サイトがユーザーの言語や地域に対応していない場合の既定ページとしてx-defaultが役立つことが説明されています。多言語サイトでは、対応していない市場のユーザーをどこへ案内するかも設計対象です。

多言語SEOの投資判断は市場別のCV価値で見る

多言語サイトSEOは、翻訳費だけで判断すると失敗しやすいです。

必要なのは、翻訳費、ページ制作費、hreflangやcanonicalなどの技術実装費、現地向けコンテンツ調整、計測設定、問い合わせ対応、営業体制まで含めた投資判断です。特にBtoB企業では、1件の問い合わせから商談化・受注までの価値が大きい場合があるため、市場別にCV価値を見ます。

ここでは試算例として、月50万円を6か月、多言語SEOの設計、主要ページ翻訳、hreflang実装、英語CTA改善、Search Console/GA4計測、海外向けコンテンツ改善に投資するケースを考えます。合計投資額は300万円です。

この試算では、月0.5件の受注、受注価値100万円と仮定すると、月50万円相当の受注期待値になります。6か月で300万円相当になり、投資額と同等です。もちろんこれは実績ではなく試算例です。実際には商談単価、契約期間、粗利、サポートコスト、現地対応コストによって変わります。

ただし、このように市場別に試算すると、多言語SEOへ投資するべき市場と、まだ投資しない市場を分けやすくなります。検索需要が少ない市場、営業対応できない市場、問い合わせ単価が低い市場では、先に広告や代理店開拓で需要確認する方がよい場合もあります。

ワンポイントアドバイス: 多言語SEOは「翻訳するページ数」ではなく「市場ごとの事業インパクト」で優先順位を決めてください。==海外向けSEOの投資判断は、流入数ではなく、市場別の問い合わせ価値、商談化率、受注単価、営業対応範囲で見る==と現実に近づきます。

自社で進める範囲と外部に相談する範囲

多言語サイトSEOでは、自社で持つべき情報と、外部に相談した方がよい範囲を分けると進めやすくなります。

自社にしか分からないのは、対象市場、商品・サービスの強み、現地営業体制、価格、契約条件、導入事例、問い合わせ対応、法務・サポート体制です。一方で、SEO観点での検索意図整理、URL設計、hreflang、canonical、サイトマップ、Search Console/GA4の分析、ページ改善優先順位は、外部支援を使った方が早い場合があります。

翻訳・現地監修・SEOレビューの役割分担を外注前に整理したい場合は、次の記事も参考になります。

外部に相談するかどうかは、翻訳ができるかではなく、海外向けページを検索流入から問い合わせ・商談までつなげて設計できるかで判断します。 多言語SEOは、翻訳、技術SEO、コンテンツ、営業導線、計測が重なる領域です。

相談前に用意しておくとよいものは、対象市場、既存ページ一覧、翻訳済みページ、Search Console、GA4、問い合わせデータ、海外売上、商談化率、国別広告データ、英語対応体制、現地パートナー情報です。これらがあると、一般論ではなく、どの市場・どのページから改善すべきかを判断しやすくなります。

よくある質問

Q. 多言語サイトSEOで最初に確認することは何ですか？

最初に確認することは、対象市場、対象言語、URL設計、問い合わせ導線です。翻訳するページを決める前に、どの国・地域の誰に届けるのか、問い合わせや資料請求にどうつなげるのかを整理します。

Q. hreflangを設定すれば海外SEOは成功しますか？

hreflangは重要ですが、それだけで海外SEOが成功するわけではありません。hreflangは言語・地域別ページの対応関係を伝えるためのものです。ページ内容、検索意図、翻訳品質、CTA、計測、営業対応まで整える必要があります。

Q. 英語ページだけでもhreflangは必要ですか？

日本語ページと英語ページのように対応するページがある場合は、hreflangを検討します。英語ページが1つだけで、他言語・他地域の対応ページがない場合は、まずURL設計やページ内容、index状態を確認します。

Q. canonicalとhreflangはどちらを優先すべきですか？

役割が違います。canonicalは正規URLを示す指定で、hreflangは言語・地域別の対応関係を示す指定です。多言語ページでは、各言語ページが自分自身をcanonicalにし、hreflangで対応ページを相互指定する形が基本です。

Q. 機械翻訳で多言語SEOを始めてもよいですか？

初期翻訳の補助として使うことはできます。ただし、検索意図、専門用語、タイトル、CTA、問い合わせ導線、現地商習慣まで確認する必要があります。公開前には、人間の確認とSEO観点のチェックを入れる方が安全です。

Q. 多言語SEOの成果は何で見ればよいですか？

Search Consoleで国別・ページ別・クエリ別の表示回数、クリック、CTR、掲載順位を確認し、GA4で国別・言語別の行動とCVを見ます。BtoBでは、問い合わせ数だけでなく、商談化率、受注単価、営業対応範囲まで含めて判断します。

まとめ：多言語サイトSEOはhreflangだけでなく市場別の導線設計まで見る

多言語サイトのSEO対策では、hreflangは重要です。しかし、hreflangだけでは海外からの問い合わせや商談は増えません。

まず確認すべきことは次の通りです。

• 対象市場、対象言語、対象読者が明確か
• 翻訳するページではなく、海外向けに必要なページを設計しているか
• URL設計が将来の言語追加、国追加、計測に耐えられるか
• hreflangが自己参照・相互参照・絶対URLで正しく管理されているか
• canonicalとhreflangが矛盾していないか
• 翻訳品質が検索意図、専門用語、CTAまで対応しているか
• 地域別ページが現地の商習慣、事例、問い合わせ導線を持っているか
• Search Console、GA4、CRM/SFAで国別・言語別に成果を見ているか
• 投資判断を流入数ではなく、市場別の問い合わせ価値と商談価値で見ているか

多言語サイトSEOは、国内サイトを別言語に変換する作業ではありません。対象市場の読者が検索し、理解し、比較し、問い合わせできる状態を作るための情報設計です。

この記事もおすすめ｜GA4でSEO流入を見る4手順、問い合わせにつながるか確認できる｜多言語SEOの国別・言語別流入を、問い合わせまで追う実装確認に進めます。｜

参考にした公式情報

• Google 検索セントラル: ページのローカライズ版
• Google 検索セントラル: Managing Multi-Regional and Multilingual Sites
• Google 検索セントラル: canonical URLの指定方法
• Google Search Central Blog: How x-default can help you
• Search Console ヘルプ: International Targeting report is deprecated
• Search Console ヘルプ: パフォーマンス レポート
• IETF RFC 5646: Tags for Identifying Languages