多言語サイトで、日本語ページは参照されるのに英語圏では別のページが表示される。米国向けと英国向けで企業情報が混ざる。こうした問題は、翻訳ページを増やすだけでは解決できません。
多言語サイトのAIO（AI検索最適化：生成AIやAI検索が自社情報を見つけ、内容を理解・参照しやすい状態を整える取り組み）では、言語・地域別URL、翻訳・ローカライズ、hreflangとcanonical、企業情報、クロールと公開後の検証の5つを、一つの設計として揃える必要があります。hreflangは、同じ内容の言語・地域別ページの対応関係をGoogleへ伝える指定です。
ただし、hreflangを設定すれば、AI検索での引用先まで直接制御できるわけではありません。この記事で「引用」は、AI回答の中で参照元として示されることを指します。GoogleはAI Overviews（AIによる概要）やAI Modeといった検索のAI機能について、通常のSEOの技術要件が引き続き重要であり、AI専用の特別なマークアップは不要と説明しています。OpenAIもChatGPT検索のクローラーであるOAI-SearchBotのクロール許可を案内していますが、AI検索がhreflangを具体的にどう利用するかまでは公開していません。
そこでこの記事では、監査で見つかった地域・言語差を実際の修正作業へ落とし込む順番を、6つのSTEPと、問題が複数あるときの優先順位、公開時のチェックリストにまとめます。
多言語AIOは「翻訳」ではなく、地域ごとの情報のまとまりを設計する
多言語サイトでは、最初に「どの地域のユーザーへ、どのURLと情報を見せるのか」を固定します。この節では、その前提になる考え方と、日本・米国・英国を例にした整理の仕方を説明します。
全体像は、次の図のとおりです。
多言語AIOは、hreflangだけではなく、地域別URLから公開後の検証までを一つの実装単位として考えます。以降のSTEP1〜4が図の前半4層、STEP5と6が「クロール・検証」の層に対応します。
設計の土台は、言語ごとにURLを分けることです。Googleは、言語ごとに異なるURLを用意し、hreflangなどで言語・地域の対応関係を明示する方法を推奨しています。IPアドレスやブラウザ言語だけで内容を切り替える方式では、Googlebotがすべてのバリエーションを発見できない可能性があります。
たとえば、日本・米国・英国でサービスを展開する場合は、次のように整理します。
| 対象 | URL | 主言語 | 地域固有情報 |
|---|---|---|---|
| 日本 | /jp/service/ | 日本語 | 日本法人、円表示、国内事例、国内窓口 |
| 米国 | /us/service/ | 英語 | 米国拠点、ドル表示、米国向け条件・事例 |
| 英国 | /uk/service/ | 英語 | 英国拠点、ポンド表示、英国向け条件・事例 |
この表のポイントは、米国版と英国版を「同じ英語のコピー」と考えないことです。主言語は同じ英語でも、拠点、通貨、条件、事例といった地域固有情報が異なるためです。
AI検索や通常検索を使う現地ユーザーが確認したいのは、単なる説明文だけではありません。「自国で利用できるのか」「契約条件は何か」「どこが提供主体なのか」「問い合わせ先はどこか」といった情報まで含めて、その地域向けページとして成立させます。
多言語対応を含む技術施策全体の位置づけは、AIOの技術対策8領域で確認できます。
STEP1｜言語・地域URLの対応表を先に固定する
実装を始める前に、サイト全体の言語・地域URLを一覧にした対応表を作ります。この表を作らずにページ単位で修正を始めると、ページ追加時にhreflangの相互参照が抜けたり、古いURLが残ったりしやすくなります。
対応表には、最低限、次の項目を入れてください。
- ページID・ページ種別
- 日本語版URL
- 英語版URL
- 地域別URL
- hreflangの言語・地域コード
- x-defaultの有無
- canonical URL
- index可否
- 公開状況
Googleへローカライズ版を伝える方法には、HTML、HTTPヘッダー、XMLサイトマップの3種類があります。Googleは3方式を同等としており、すべて併用しても検索上の追加メリットはないと説明しています。そのため、管理しやすい方法を一つ決め、サイト全体で統一すると、実装ミスを減らしやすくなります。
STEP2｜翻訳ページを「地域向けコンテンツ」へローカライズする
この節では、翻訳できているかどうかではなく、ページ全体が対象地域のユーザーへ回答できているかを確認します。
同じ英語圏でも、通貨・提供条件・法人・事例などは地域ごとに異なります。そのため、翻訳ではなくローカライズとして設計します。
Googleはページの言語判定について、hreflangやHTMLのlang属性ではなく、主にページ上でユーザーに見えるコンテンツを使用すると説明しています。つまり、タグだけを整えても、本文の言語や内容が不十分なままでは解決しません。
各地域版では、次の内容を確認します。
- 商品・サービス名称
- 価格・通貨
- 提供地域
- 契約・利用条件
- 法人名・運営主体
- 住所・電話番号・問い合わせ先
- 現地の事例
- FAQ
- 業界用語
- 法制度や商習慣に関係する説明
たとえば、日本向けページの「導入まで最短○日」という説明を英訳しても、米国版で同じ提供条件でなければ、正しい情報にはなりません。確認の対象は、文章だけでなく提供条件そのものです。
機械翻訳そのものが問題なわけではありません。Googleのスパムポリシーが問題例として挙げているのは、翻訳を含む自動変換によって、ユーザーへの価値がほとんどないページを大量に生成する行為です。翻訳後に事実確認と地域向けの調整を行い、そのページ単体で価値を持たせてください。
STEP3｜hreflangは自己参照・相互参照・完全URLまでセットで実装する
この節では、hreflangの書き方の例と、実装時に確認する5点を整理します。
たとえば、HTMLで日本、米国、英国、グローバル版を指定する場合は、次のようになります。
<link rel="alternate" hreflang="ja-JP" href="https://example.com/jp/service/" />
<link rel="alternate" hreflang="en-US" href="https://example.com/us/service/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/service/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/global/service/" />
実装時は、少なくとも次の5点を確認します。
- 現在のページ自身もhreflangに含める
- ページAからBを指定したら、BからAも指定する
- 相対URLではなく完全なURLを記載する
- 言語はISO 639-1、地域はISO 3166-1 Alpha-2に沿う
- 必要に応じてx-defaultを設定する
言語コードと地域コードの順序にも注意が必要です。たとえば、日本を示したい場合にJPだけを指定することはできません。jaまたはja-JPのように、言語を先に指定します。また、相互参照が成立していないhreflangは、Googleに無視される可能性があります。
canonicalとhreflangを矛盾させない
hreflangは地域・言語版同士の関係を示し、canonicalは基準となるURLを示します。目的が異なる二つの設定なので、互いに矛盾させないことが重要です。
特に、米国向け英語ページと英国向け英語ページのように本文が非常に似ている地域別ページでは、canonicalとの整合を確認します。
Googleは同一言語の地域別ページについて、canonicalとhreflangの両方を使用し、どの地域URLを検索結果へ出すべきか理解しやすくする方法を案内しています。canonicalはGoogleへの「希望」を伝えるシグナルであり、必ず指定どおり採用される命令ではありません。
「米国ページなのに英国ページをcanonicalへ指定している」など、目的と設定が矛盾していないかを確認してください。
STEP4｜法人名・住所・URLなどの企業情報を地域ごとに揃える
ページ本文を正しくローカライズしても、サイト内の企業情報が場所によって異なれば、ユーザーにも検索システムにも分かりにくい状態になります。そこで、同じ情報が表示される場所を横断して確認します。
次の表は、企業情報ごとに確認する場所をまとめたものです。
| 情報 | 確認する場所 |
|---|---|
| 法人名・ブランド名 | 会社概要、サービスページ、フッター |
| 住所 | 会社概要、拠点ページ、構造化データ |
| 電話番号 | 問い合わせページ、フッター |
| 公式URL | Organization構造化データ、外部公式プロフィール |
| 関連プロフィール | sameAs、公式SNSなど |
| ロゴ | サイト表示、Organization構造化データ |
各行について、地域ごとの表記が、確認する場所のあいだで一致しているかを見ます。
GoogleのOrganization構造化データでは、name、alternateName、url、logo、address、telephoneなど、企業を理解・識別するための情報を設定できます。複数地域に住所がある場合は、複数住所も指定できます。
ただし、構造化データを入れればAI検索で引用されるという意味ではありません。GoogleはAI機能について専用のschema.orgマークアップは不要としており、構造化データは画面上に見える情報と一致させることを求めています。
そのため、企業情報は「AI向けに別の情報を追加する」のではなく、人間が読む情報と機械が読み取る情報を一致させるという考え方で整えます。
STEP5｜AIや検索クローラーが地域別ページへ到達できる状態を作る
内容が正しくても、検索システムがページを取得できなければ参照候補にはなりません。この節では、クローラーが地域別ページへ到達できる状態を確認します。
GoogleのAI機能でサポートリンクとして表示されるには、ページがインデックスされ、通常のGoogle検索でスニペット表示の対象になれることが技術要件です。Googleは、Googlebotをrobots.txtやCDNで遮断しないこと、重要な情報をテキストでも提供すること、内部リンクからページを発見できる状態にすることなどを案内しています。
ChatGPT検索についても、OpenAIはWebサイトを検索結果で発見・表示・引用しやすくするため、OAI-SearchBotをブロックしないよう案内しています。
地域別URLごとに、次を確認してください。
- robots.txtで必要なクローラーを遮断していない
- noindexが付いていない
- HTTP 200で取得できる
- 本文をクローラーが取得できる
- JavaScriptだけに重要情報を依存していない
- サイト内部からリンクされている
- XMLサイトマップへ必要なURLが含まれている
- canonicalが意図したURLを指している
「AI検索へ引用させるURL」を直接指定するというより、対象地域の正しい情報源へ検索システムが到達できる状態を作る、と考える方が実装上は正確です。
STEP6｜公開後は通常検索とAI回答を分けて検証する
修正後は、最初からAI回答だけを確認しないでください。AI回答だけを見ても、変化の原因をたどりにくいためです。まず通常検索の技術状態を確認し、その後に言語・地域別のAI回答と参照URLを比較します。
通常検索側では、次の5点を確認します。
- 対象URLをクロールできるか
- インデックスされているか
- canonicalが意図したURLか
- hreflangの相互参照が成立しているか
- 対象地域・言語で適切なURLが検索結果へ出るか
その後、AI検索で言語・地域別の回答を確認します。質問条件を固定して比較し、回答内容と参照URLを記録します。たとえば、同じサービスについて、次の条件で質問します。
- 日本語・日本条件
- 英語・米国条件
- 英語・英国条件
ここで注意したいのは、AI回答の変化を「hreflangを直したから」と単独要因で判断しないことです。Googleの公開ガイドは、AI機能でも通常の検索基盤やSEOの基本が使われると説明していますが、hreflangがAI回答内の引用URLをどのように選択するかという個別仕様までは公開されていません。
そのため、URL、本文、企業情報、クロール状況、インデックス、外部情報などを一緒に記録し、変更前後を比較します。
複数の問題が見つかったら「見えない→間違う→揺れる→薄い→測れない」の順に直す
複数の問題が見つかったときに、すべてを同時に修正すると、何が改善につながったのか判断しにくくなります。次の表の順番で整理すると、優先順位を付けやすくなります。
| 優先 | 状態 | 主な確認対象 |
|---|---|---|
| 1 | 見えない | robots.txt、noindex、HTTP状態、内部リンク |
| 2 | 間違う | hreflang、canonical、言語コード、地域URL |
| 3 | 揺れる | 法人名、住所、電話番号、商品名、公式プロフィール |
| 4 | 薄い | 直訳のみ、地域固有情報不足、現地FAQ不足 |
| 5 | 測れない | 言語別の検索・AI回答テストが未整備 |
最優先は「クロールもインデックスもできないページ」です。次に、検索システムへ誤ったURL関係を伝えている状態を直します。その後、企業情報とコンテンツを揃え、最後に継続測定できる仕組みを作ります。
各状態の直し方は、見えない＝STEP5、間違う＝STEP1とSTEP3、揺れる＝STEP4、薄い＝STEP2、測れない＝STEP6で説明したとおりです。
公開・改修時は多言語AIO実装チェックリストで1ページずつ確認する
次の項目を、1ページずつ確認してください。
- 言語・地域ごとに固有URLがある
- URLと対象地域の対応表がある
- 本文が対象言語で成立している
- 地域固有の価格・条件・事例が正しい
- hreflangに自己参照がある
- hreflangが双方向になっている
- 言語・地域コードが正しい
- 必要なページにx-defaultがある
- canonicalとhreflangが矛盾していない
- 法人名・住所・電話番号がサイト内で整合している
- Organization構造化データと表示内容が一致している
- Googlebotなど必要なクローラーを遮断していない
- ChatGPT検索を対象にする場合はOAI-SearchBotの状態を確認している
- 各地域URLが内部リンクから到達できる
- 修正前後の検索結果を記録している
- 同条件のAI質問を地域・言語別に記録している
すべてのページを機械的に翻訳してhreflangだけを追加する運用ではなく、「現地ユーザーがそのページだけで比較・判断できるか」を最後の確認基準にしてください。
まとめ｜地域ごとの正しい情報を、検索システムが取得できる形で揃える
多言語サイトのAIO実装では、hreflangだけを単独で直すのではなく、言語・地域URL、翻訳・ローカライズ、hreflangとcanonical、企業情報、クロールと公開後の検証の5つを一つの流れとして設計します。
Google検索については、hreflangの実装方法や言語・地域別URLの扱いが公式に公開されています。一方、GoogleやOpenAIのAI検索でhreflangが引用先の決定にどのように使われるかは、公開情報だけでは断定できません。
そのため、「AIへ効くと推測されるタグ」を増やすのではなく、まず各地域の正しい情報が独立したURLで公開され、検索システムが取得でき、企業情報と本文の内容が一致している状態を作ります。
最初の一歩は、監査で見つかった問題を見えない→間違う→揺れる→薄い→測れないの五つの状態に分け、この順に修正することです。この順番なら、グローバルサイトの複雑な問題を実装単位へ分解し、改善後の検索結果とAI回答を継続的に比較できます。
参考文献・データ元
この記事で参照した情報を確認できます。
- Google Search Central「Tell Google about localized versions of your page」：hreflang、言語・地域コード、相互参照、x-default、3つの実装方法の確認に使用。 URL: Google Search Central
- Google Search Central「Managing Multi-Regional and Multilingual Sites」：言語別URL、クロール、地域別ページ設計の確認に使用。 URL: Google Search Central
- Google Search Central「AI 機能とウェブサイト」：AI Overviews・AI Modeの技術要件、SEOとの関係の確認に使用。 URL: Google Search Central
- Google Search Central「Google検索の生成AI機能向けに最適化するためのGoogleのガイド」：生成AI検索でも検索基盤・技術SEOが重要であることの確認に使用。 URL: Google Search Central
- Google Search Central「Organization structured data」：法人名、住所、電話番号、URL等の企業情報設計の確認に使用。 URL: Google Search Central
- Google Search Central「Spam policies for Google web search」：価値を追加しない大量翻訳ページの扱いの確認に使用。 URL: Google Search Central
- OpenAI「パブリッシャーと開発者 – FAQ」：ChatGPT検索とOAI-SearchBotのクロール設定の確認に使用。 URL: OpenAI Help Center
‹ 親記事: AIOの技術対策とは？企業担当者が押さえるべき8領域の実務チェックリスト
