多言語サイトで日本語ページは参照されるのに、英語圏では別のページが表示される。米国向けと英国向けで企業情報が混ざる。このような問題は、翻訳ページを増やすだけでは解決できません。
多言語サイトのAIO（AI検索最適化：生成AIやAI検索が自社情報を見つけ、内容を理解・参照しやすい状態を整える取り組み）では、言語・地域別URL、翻訳内容、hreflang、canonical、企業情報、クロール可能性を一つの設計として揃える必要があります。
重要なのは、hreflangを設定すればAI検索での引用先まで直接制御できる、と考えないことです。GoogleはAI OverviewsやAI Modeについて、通常のSEOの技術要件が引き続き重要であり、AI専用の特別なマークアップは不要と説明しています。OpenAIもChatGPT検索についてOAI-SearchBotのクロール許可を案内していますが、AI検索がhreflangを具体的にどう利用するかまでは公開していません。
この記事では、監査で見つかった地域・言語差を、実際の修正作業へ落とし込む順番を整理します。
多言語AIOは「翻訳」ではなく、地域ごとの情報のまとまりを設計する
多言語サイトでは、最初に「どの地域のユーザーへ、どのURLと情報を見せるのか」を固定します。
多言語対応を含む技術施策の位置づけは、AIOの技術対策8領域で全体像を確認できます。
多言語AIOは、hreflangだけではなく、地域別URLから公開後の検証までを一つの実装単位として考えます。
Googleは、言語ごとに異なるURLを用意し、hreflangなどで言語・地域の対応関係を明示する方法を推奨しています。IPアドレスやブラウザ言語だけで内容を切り替える方式では、Googlebotがすべてのバリエーションを発見できない可能性があります。
たとえば、日本・米国・英国でサービスを展開する場合は、次のように整理します。
| 対象 | URL | 主言語 | 地域固有情報 |
|---|---|---|---|
| 日本 | /jp/service/ | 日本語 | 日本法人、円表示、国内事例、国内窓口 |
| 米国 | /us/service/ | 英語 | 米国拠点、ドル表示、米国向け条件・事例 |
| 英国 | /uk/service/ | 英語 | 英国拠点、ポンド表示、英国向け条件・事例 |
ポイントは、米国版と英国版を「同じ英語のコピー」と考えないことです。
AI検索や通常検索を使う現地ユーザーが確認したいのは、単なる説明文だけではありません。「自国で利用できるのか」「契約条件は何か」「どこが提供主体なのか」「問い合わせ先はどこか」といった情報まで含めて、その地域向けページを成立させます。
STEP1｜言語・地域URLの対応表を先に固定する
実装を始める前に、サイト全体の言語・地域URLを一覧化します。
最低限、次の項目を管理してください。
- ページID・ページ種別
- 日本語版URL
- 英語版URL
- 地域別URL
- hreflangの言語・地域コード
- x-defaultの有無
- canonical URL
- index可否
- 公開状況
Googleへローカライズ版を伝える方法には、HTML、HTTPヘッダー、XMLサイトマップの3種類があります。Googleは3方式を同等としており、すべて併用しても検索上の追加メリットはないと説明しています。管理しやすい方法を一つ決め、サイト全体で統一する方が実装ミスを減らしやすくなります。
URL対応表を作らずページ単位で修正を始めると、ページ追加時にhreflangの相互参照が抜けたり、古いURLが残ったりしやすくなります。
STEP2｜翻訳ページを「地域向けコンテンツ」へローカライズする
多言語AIOでは、文章を翻訳できているかだけではなく、ページ全体が対象地域のユーザーへ回答できているかを確認します。
同じ英語圏でも、通貨・提供条件・法人・事例などは地域ごとに異なります。翻訳ではなくローカライズとして設計します。
Googleはページの言語判定について、hreflangやHTMLのlang属性ではなく、主にページ上でユーザーに見えるコンテンツを使用すると説明しています。つまり、タグだけを整えて本文の言語や内容が不十分な状態では解決しません。
各地域版で、次の内容を確認します。
- 商品・サービス名称
- 価格・通貨
- 提供地域
- 契約・利用条件
- 法人名・運営主体
- 住所・電話番号・問い合わせ先
- 現地の事例
- FAQ
- 業界用語
- 法制度や商習慣に関係する説明
たとえば、日本向けページの「導入まで最短○日」という説明を英訳しても、米国版で同じ提供条件でなければ正しい情報にはなりません。
また、機械翻訳自体が問題なのではありません。Googleのスパムポリシーでは、翻訳を含む自動変換によって、ユーザーへの価値がほとんどないページを大量生成する行為が問題例として挙げられています。翻訳後に事実確認と地域向けの調整を行い、そのページ単体で価値を持たせることが重要です。
STEP3｜hreflangは自己参照・相互参照・完全URLまでセットで実装する
hreflangは、同じ内容の言語・地域別ページの関係をGoogleへ伝える仕組みです。
たとえば、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 OverviewsやAI Modeについて、専用の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を比較します。
まず通常検索側で技術実装を確認します。
- 対象URLをクロールできるか
- インデックスされているか
- canonicalが意図したURLか
- hreflangの相互参照が成立しているか
- 対象地域・言語で適切なURLが検索結果へ出るか
その後、AI検索で言語・地域別の回答を確認します。
たとえば、同じサービスについて、
- 日本語・日本条件
- 英語・米国条件
- 英語・英国条件
のように質問条件を固定して比較し、回答内容と参照URLを記録します。
ここで重要なのは、AI回答の変化を「hreflangを直したから」と単独要因で判断しないことです。Googleの公開ガイドではAI機能でも通常の検索基盤やSEOの基本が使われていますが、hreflangがAI回答内の引用URLをどのように選択するかという個別仕様までは公開されていません。
URL、本文、企業情報、クロール状況、インデックス、外部情報などを一緒に記録し、変更前後を比較します。
多言語AIOの修正は「見えない→間違う→揺れる→薄い→測れない」の順で進める
複数の問題が見つかった場合、すべてを同時に修正すると何が効いたのか判断しにくくなります。
次の順番で整理すると、優先順位を付けやすくなります。
| 優先 | 状態 | 主な確認対象 |
|---|---|---|
| 1 | 見えない | robots.txt、noindex、HTTP状態、内部リンク |
| 2 | 間違う | hreflang、canonical、言語コード、地域URL |
| 3 | 揺れる | 法人名、住所、電話番号、商品名、公式プロフィール |
| 4 | 薄い | 直訳のみ、地域固有情報不足、現地FAQ不足 |
| 5 | 測れない | 言語別の検索・AI回答テストが未整備 |
最優先は「クロールもインデックスもできないページ」です。
次に、検索システムへ誤ったURL関係を伝えている状態を直します。その後、企業情報とコンテンツを揃え、最後に継続測定できる仕組みを作ります。
多言語AIO実装チェックリスト
公開・改修時は、次の項目を1ページずつ確認してください。
- 言語・地域ごとに固有URLがある
- URLと対象地域の対応表がある
- 本文が対象言語で成立している
- 地域固有の価格・条件・事例が正しい
- hreflangに自己参照がある
- hreflangが双方向になっている
- 言語・地域コードが正しい
- 必要なページにx-defaultがある
- canonicalとhreflangが矛盾していない
- 法人名・住所・電話番号がサイト内で整合している
- Organization構造化データと表示内容が一致している
- Googlebotなど必要なクローラーを遮断していない
- ChatGPT検索を対象にする場合はOAI-SearchBotの状態を確認している
- 各地域URLが内部リンクから到達できる
- 修正前後の検索結果を記録している
- 同条件のAI質問を地域・言語別に記録している
すべての記事を機械的に翻訳し、hreflangだけを追加する運用ではなく、「現地ユーザーがそのページだけで比較・判断できるか」を最後の確認基準にしてください。
まとめ
多言語サイトのAIO実装では、hreflangだけを単独で直すのではなく、言語・地域URL、翻訳・ローカライズ、hreflangとcanonical、企業情報、クロール可能性、公開後の検証を一つの流れとして設計することが重要です。
Google検索については、hreflangの実装方法や言語・地域別URLの扱いが公式に公開されています。一方、GoogleやOpenAIのAI検索でhreflangが引用先の決定にどのように使われるかは、公開情報だけでは断定できません。
そのため、多言語AIOでは「AIへ効くと推測されるタグを増やす」のではなく、まず各地域の正しい情報が独立したURLで公開され、検索システムが取得でき、企業情報と本文の内容が一致している状態を作ります。
監査で問題を見つけた後は、見えない→間違う→揺れる→薄い→測れないの順に修正してください。この順番なら、グローバルサイトの複雑な問題を実装単位へ分解し、改善後の検索結果とAI回答を継続的に比較できます。
参考文献・データ元
この記事で参照した情報を確認できます。
- Google Search Central「Tell Google about localized versions of your page」：hreflang、言語・地域コード、相互参照、x-default、3つの実装方法の確認に使用。 URL: https://developers.google.com/search/docs/specialty/international/localized-versions
- Google Search Central「Managing Multi-Regional and Multilingual Sites」：言語別URL、クロール、地域別ページ設計の確認に使用。 URL: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites
- Google Search Central「AI 機能とウェブサイト」：AI Overviews・AI Modeの技術要件、SEOとの関係の確認に使用。 URL: https://developers.google.com/search/docs/appearance/ai-features?hl=ja
- Google Search Central「Google検索の生成AI機能向けに最適化するためのGoogleのガイド」：生成AI検索でも検索基盤・技術SEOが重要であることの確認に使用。 URL: https://developers.google.com/search/docs/fundamentals/ai-optimization-guide?hl=ja
- Google Search Central「Organization structured data」：法人名、住所、電話番号、URL等の企業情報設計の確認に使用。 URL: https://developers.google.com/search/docs/appearance/structured-data/organization
- Google Search Central「Spam policies for Google web search」：価値を追加しない大量翻訳ページの扱いの確認に使用。 URL: https://developers.google.com/search/docs/essentials/spam-policies?rd=1&visit_id=639203431299490584-2014722169
- OpenAI「パブリッシャーと開発者 – FAQ」：ChatGPT検索とOAI-SearchBotのクロール設定の確認に使用。 URL: https://help.openai.com/ja-jp/articles/12627856-%E3%83%91%E3%83%96%E3%83%AA%E3%83%83%E3%82%B7%E3%83%A3%E3%83%BC%E3%81%A8%E9%96%8B%E7%99%BA%E8%80%85-faq
‹ 親記事: AIOの技術対策とは？企業担当者が押さえるべき8領域の実務チェックリスト
