多言語サイトのAI検索対策｜URL設計・hreflang・機械翻訳の扱いを解説

「英語版のサイトも作ったのに、海外の人が検索すると日本語のページばかり出てくる」。日本語と英語など、複数の言語でサイトを運営している会社から、こうした悩みを聞くことがあります。

AI検索も、多くの場合は、ウェブ上のページを読んで回答を組み立てます。そのため、どの言語の利用者にどのページを見せるかを正しく伝えることが、対策の土台になります。

AI検索とは、GoogleのAI OverviewsやAI Mode、ChatGPTやPerplexityの検索機能のように、AIが検索結果をもとに回答を作る仕組みです。この記事は、複数の言語でサイトを持つ中小企業の担当者に向けて、言語ごとのURLの分け方、hreflangの書き方、機械翻訳の扱いを説明します。

内容は、2026年10月18日にGoogleの公式文書とW3Cの文書を開いて確かめました。社名や設定例はすべて説明のために作った架空のものです。

先に結論 言語ごとにURLを分け、hreflangで結び、翻訳は確認してから公開する

結論を、確認できたことと筆者の判断に分けて並べます。

論点	確認できたこと	筆者の判断
URLの分け方	Googleは、言語ごとに別のURLを使うよう勧め、Cookieやブラウザ設定で内容を切り替える方法を勧めていない	日英2言語なら、サブディレクトリが運用しやすい
hreflang	各言語版は、自分自身を含む全言語版を列挙する。互いに指し合っていない組み合わせは無視される	指定方法は1つにそろえる
言語の判定	Googleは、ページの見えている内容から言語を判断し、lang属性やhreflangでは判断しない	lang属性は、読み上げ機能のために正しく付ける
機械翻訳	問題とされるのは、読者に価値のないページを大量に作る行為	公開前に、その言語が分かる人が確認する

公式が言っていること

Googleは、AI Overviewsなどの補足リンクになる条件を、通常の検索の技術要件を満たすことと説明しています。多言語サイトのための特別なAI向け設定は、公式の文書に見当たりませんでした。

そのため、この記事の中心は、Googleが多言語サイトについて公開している基本の設定です。

この記事の立場

AI検索サービスが、別の言語のページをどう扱うのかは、公式資料から確かめられませんでした。確かめられない部分は、そのように書き分けます。

確かなのは、各言語版が独立したページとして正しくインデックスされることが前提だという点です。

作業の全体像

作業の流れを、図にまとめます。

AI検索の対策は、通常の検索の土台の上にある

AI機能の補足リンクになる条件

Googleの文書によると、AI Overviews や AI Mode で補足リンクとして表示されるには、ページがインデックスされ、スニペット付きで表示できる必要があります。そのほかに、追加の技術要件はないとされています。

英語版のページがインデックスされていない、あるいは日本語版と区別されていない状態では、英語版が参照される機会は生まれにくいと考えられます。

Googleはページの言語をどう判断するか

Googleは、ページの言語を、表示されている内容から判断すると説明しています。lang属性やURLのような、コードの中の言語情報は使わないとされています。

別の文書でも、Googleは、hreflangやHTMLのlang属性を使わず、独自のアルゴリズムで言語を判断すると書いています。

言語を判断しやすいページにする

言語の判断を助けるために、Googleは、各ページで本文とナビゲーションを同じ言語にそろえることを勧めています。日本語と英語を左右に並べる対訳形式は避けます。

本文だけが日本語で、メニューだけが英語のページも、読者に使いにくいページです。1ページは1つの言語で完結させます。

手順1 言語ごとにURLを分ける

多言語サイトと多地域サイトの違い

Googleは、2つの言葉を区別しています。多言語サイトは、複数の言語で内容を提供するサイトです。

多地域サイトは、複数の国の利用者を明確に対象にするサイトです。

種類	例	Googleの説明
多言語	英語版とフランス語版を持つカナダの会社	検索した人の言語に合うページを探そうとする
多地域	カナダとアメリカの両方に出荷する製造業	検索した人に合う地域のページを探そうとする
両方	米国向けとカナダ向けがあり、カナダにはフランス語版もある	言語と地域の両方で版を分ける

日本語と英語だけを出し分ける中小企業の多くは、多言語サイトに当たります。この記事も、多言語を中心に説明します。

URLの構造を選ぶ

Googleの多言語・多地域サイトの文書は、言語や地域ごとにページを分ける構造を、次のように比較しています。

方式	例	長所	短所
国別ドメイン	example.de	対象の国がはっきりする。サーバーの場所は関係ない	費用が高くなる場合や、取得条件が厳しい場合がある。1か国しか対象にできない
サブドメイン	de.example.com	設定が簡単。サーバーを分けられる	URLだけでは国か言語か伝わりにくい
サブディレクトリ	example.com/de/	設定が簡単で、同じホストなので保守の手間が小さい	サーバーの場所は1つ。サイトの分離がやや難しい
URLパラメータ	site.com?loc=de	推奨されていない	分類が難しく、URLから対象が伝わりにくい

日英2言語の中小企業では、サブディレクトリ方式が、保守の手間が小さく、選びやすい方式です。たとえば、日本語を https://example.com/、英語を https://example.com/en/ に置きます。

どの方式でも、1つのURLには1つの言語の内容だけを置く、という原則を守ります。

対象の国や言語を示す手がかり

Googleは、対象の利用者を判断する手がかりとして、国別ドメイン、hreflang、サーバーの場所を挙げています。ほかにも、ページ上の住所や電話番号、言語と通貨、地元のサイトからのリンクなどがあります。

一方で、位置情報に関するメタタグや、地域を指定するHTMLの属性は、Googleには無視されると説明されています。

Cookieやブラウザの言語で切り替えない

同じURLのまま、訪問者のブラウザの言語やCookieを見て、日本語と英語を出し分ける作りがあります。Googleは、この方法よりも、言語ごとに別のURLを使うことを勧めています。

理由は、Googleのクロールの仕組みにあります。Googleの文書によると、Googlebotは多くの場合、米国から来るように見え、ブラウザの言語を伝えるAccept-Languageというヘッダーを付けずにリクエストを送ります。

そのため、言語によって内容が変わるページは、すべての言語版がクロールやインデックスの対象にならない可能性があります。

米国以外の拠点からのクロール

別の文書には、Googlebotが米国以外のIPアドレスからもクロールするという説明があります。ある国から来たように見えるGooglebotには、その国の利用者と同じように対応するよう、同じ文書は述べています。

この説明があっても、出し分けを前提にした作りは、取りこぼしの原因になります。確実なのは、言語ごとにURLを分けることです。

自動リダイレクトの代わりに切り替えリンクを置く

「英語圏からのアクセスは、自動で英語版に移す」という設定も、避けたほうがよい方法です。Googleは、利用者の言語を推測して別の言語版へ移すリダイレクトを避けるよう、案内しています。

利用者も検索エンジンも、すべての言語版を見られなくなるおそれがあるためです。

代わりに、ヘッダーなど目立つ場所に「日本語 / English」のような切り替えのリンクを置き、利用者が自分で選べるようにします。

IPアドレスによる出し分けも避ける

Googleは、IPアドレスから場所を判断して内容を変える方法についても、難しく、一般に信頼できないと述べています。Googleのクロールの大半は米国から来るため、変化をたどれない場合があるともされています。

出し分けに頼らず、hreflang、別のURL、明示的なリンクを使うよう、Googleは案内しています。

切り替えリンクの置き方

切り替えのリンクは、全ページの同じ位置に置くと、利用者が迷いません。ヘッダーの右上や、フッターが定番です。

リンク先は、そのページに対応する別言語のページにします。どのページからでも英語のトップページへ移すと、利用者は読んでいたページを探し直すことになります。

リンクの文言は、それぞれの言語で自分の名前を書きます。日本語なら「日本語」、英語なら「English」と書くと、その言語が読めない人にも見つけてもらえます。

この置き方は筆者の考えで、公式の指定ではありません。

手順2 hreflangで言語版どうしを結ぶ

hreflangとは

hreflang（エイチレフラング）は、このページには別の言語版もあり、そのURLはこれだ、と検索エンジンに伝える指定です。Googleはこれを使って、検索した人の言語や地域に合う版を、検索結果に出そうとします。

なお、Googleは、hreflangを言語の判断には使わないと説明しています。hreflangの役割は、同じ内容の言語違いの版を結びつけることです。

指定の方法は3つ

Googleの文書によると、hreflangは次の3つの方法で指定できます。

方法	向いているケース
HTMLのhead内のlink要素	ページ数が少なく、テンプレートを編集できる
HTTPヘッダー	PDFなど、HTML以外のファイル
XMLサイトマップ	ページ数が多い、またはHTMLを編集しにくい

3つの方法は、Googleにとって同等です。同時に使うこともできますが、検索では利点がなく、管理が難しくなると書かれています。

1つにそろえるのが安全です。

守るべき3つのルール

守るべきルールを、先に並べます。

1. 各言語版は、自分自身を含む全言語版を列挙する
2. 互いに指し合う。片方だけの指定は無視される
3. URLは、httpsから始まる完全な形で書く

2つ目のルールの理由も、Googleの文書に書かれています。第三者が、勝手に自分のページをあなたのページの別言語版だと主張できないようにするためです。

言語を一部のページにしか用意できない場合

すべての言語で、完全に双方向のリンクを維持するのが難しいこともあります。その場合、Googleは、一部のページで一部の言語を省くことを認めています。

互いに指し合っているものは、そのまま処理されます。

ただし、新しく加えた言語のページは、元になった言語のページと双方向に結ぶ必要があります。英語版がないページには、英語版の行を書きません。

言語コードの書き方

hreflangの値は、言語コードと、必要に応じて地域コードをハイフンでつないだ形です。言語はISO 639-1、地域はISO 3166-1 Alpha 2の形式で書きます。

書き方	意味	判定
ja	日本語。地域は問わない	正しい
en	英語。地域は問わない	正しい
en-GB	英国の利用者向けの英語	正しい
zh-Hans	簡体字の中国語	正しい
jp	国コードを言語として書いている	誤り。日本語はjaを使う
GB	地域コードだけの指定	誤り。単独では指定できない
es-419	ISO 3166-1に載っていないコード	対応していない

Googleは、国コードだけを指定できないこと、最初のコードは言語を表すことを説明しています。例として、be はベラルーシ語の言語コードなので、ベルギーの意味にはならないと書かれています。

日本語と英語を出し分けるだけなら、地域コードは付けず、jaとenだけで十分です。大文字と小文字は区別されませんが、地域コードは大文字で書く慣習があります。

x-defaultで行き先のない人の受け皿を決める

x-defaultは、どの言語版にも当てはまらない利用者に見せるページを指定する、特別な値です。日本語版と英語版しかないサイトに、フランス語を使う人が来たときの行き先になります。

2023年5月のGoogleの公式ブログは、x-defaultのページについて、3つの形を挙げています。言語や国を選ぶページ、対応する内容がない人を移す先のページ、既定とみなす版のいずれでもよいとされています。

文書には、x-defaultは言語の選択ページのために作られた値だとも書かれています。選択ページがない日英2言語のサイトでは、既定とみなす英語版を指定する方法が分かりやすいと、筆者は考えます。

x-defaultの意外な使い道

同じブログは、x-defaultに指定したURLも、hreflangのほかのURLと同様に、新しいURLの発見に使われることがあると説明しています。サイトの構造が複雑で、すべての言語版へのリンクを張りにくい場合に役立つとされています。

設定を始める前に決めておくこと

hreflangを書き始める前に、次の4つを決めておくと、書き間違いが減ります。

1. 対象にする言語の一覧と、それぞれのコード
2. 各言語版のURLの規則（例：英語版は /en/ で始める）
3. 指定の方法（head、HTTPヘッダー、サイトマップのどれか1つ）
4. x-defaultに指定するページ

決めた内容は、社内の資料に書き残します。担当者が替わっても、同じ形で保てます。

設定例1 HTMLのheadに書く

日本語版 https://example.com/service/ と、英語版 https://example.com/en/service/ がある場合の例です。両方のページに、まったく同じ3行を書きます。

<link rel="alternate" hreflang="ja" href="https://example.com/service/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/service/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/service/" />

URLは、httpsから始まる完全な形で書きます。ページごとに、対応する言語版を指定します。

すべての英語版を英語のトップページにするのは、よくある間違いです。

Googleの文書は、link要素が、正しく書かれたhead要素の中に入っていることを確かめるよう勧めています。疑わしいときは、HTMLの検証ツールで確かめます。

設定例2 XMLサイトマップに書く

ページ数が多い場合は、サイトマップでまとめて指定すると管理しやすくなります。サイトマップでは、言語版ごとにurl要素を作り、その中に、自分自身を含む全言語版を並べます。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/service/</loc>
    <xhtml:link rel="alternate" hreflang="ja" href="https://example.com/service/" />
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/service/" />
  </url>
  <url>
    <loc>https://example.com/en/service/</loc>
    <xhtml:link rel="alternate" hreflang="ja" href="https://example.com/service/" />
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/service/" />
  </url>
</urlset>

日本語版のurl要素と英語版のurl要素の両方を書き、中のxhtml:link要素は同じにします。片方しか書かないと、互いに指し合う形が成り立ちません。

Googleの文書によると、この子要素は、サイトマップのURL数の上限には数えられません。また、サイトマップは、置かれたディレクトリより下のURLだけを含められます。

設定例3 HTTPヘッダーに書く

PDFなど、HTMLを持たないファイルには、HTTPヘッダーで指定します。日本語版と英語版の2つのPDFがある場合の書き方です。

Link: <https://example.com/file-ja.pdf>; rel="alternate"; hreflang="ja",
      <https://example.com/file-en.pdf>; rel="alternate"; hreflang="en"

どちらのPDFにも、同じ内容のヘッダーを返します。

canonicalとhreflangの関係

canonical（正規URL）は、内容が重複するページのうち、代表となるURLを伝える指定です。多言語サイトでは、次の2点に注意します。

各言語版のcanonicalは、その言語版自身を指す

英語版のcanonicalを日本語版に向けると、英語版は日本語版の重複だと伝えることになります。英語版が検索結果に出にくくなるおそれがあります。

Googleは、言語版どうしが重複とみなされるのは、主要な内容が同じ言語のままの場合だけだと説明しています。きちんと翻訳した日本語版と英語版は、重複に当たりません。

canonicalにhreflangの属性は付けない

Googleの正規化の文書は、rel=”canonical”にhreflangやlangなどの属性を付けた書き方は、正規化に使われないと説明しています。言語版の指定は、rel=”alternate”とhreflangの組み合わせで行います。

hreflangのまとまりがある版が好まれる

同じ文書には、Googleは、正規URLを選ぶ際に、hreflangで互いに指し合うまとまりに入っているURLを好む、という説明もあります。

たとえば、同じ言語の地域違いの版が3つあり、そのうち2つだけが互いに指し合っているとします。この場合、2つが正規として選ばれ、まとまりに入っていない版は選ばれにくくなります。

正規化の仕組みは、正規化とはでも説明しています。

手順3 htmlのlang属性を正しく付ける

Googleはlang属性で言語を判定しない

ページの先頭にある html lang=”ja” のlang属性は、そのページの言語を示すものです。ただし、Googleは、言語の判断にこの属性を使わないと明記しています。

そのため、Googleに対しては、lang属性を整えるよりも、1ページを1つの言語で書くことが大切です。

それでもlang属性を付ける理由

W3Cは、html要素にlang属性を付けて、ページの既定の言語を宣言するよう勧めています。ページの一部が別の言語なら、その部分を囲む要素にも付けます。

アクセシビリティの基準であるWCAGにも、ページの既定の言語を機械が判別できることを求める項目があります。解説文書には、画面読み上げのソフトが正しい発音の規則を読み込めるようになる、と書かれています。

よくある間違い

英語版のテンプレートを流用したまま、lang=”ja”のままになっているケースがあります。CMSの多言語機能を使っている場合も、英語版のHTMLを開いて、実際の値を確かめます。

W3Cは、meta要素のhttp-equiv属性でContent-Languageを指定して、ページの言語を示す方法は使わないよう述べています。ページの言語は、html要素のlang属性で示します。

手順4 機械翻訳したページの扱いを決める

スパムポリシーとの関係

機械翻訳で一気に英語版を作ってよいのかは、よくある疑問です。公式に確認できる範囲で整理します。

Googleのスパムポリシーには、「大量生成コンテンツの不正使用（scaled content abuse）」という項目があります。主に検索順位を操作する目的で、読者にほとんど価値のないページを大量に作ることを指します。

ポリシーの例には、ほかのサイトの内容を、同義語への置き換えや翻訳などの自動変換で加工して、価値の少ないページを大量に作ることが含まれます。作り方は問われず、2024年3月の告知でも、自動化、人手、その組み合わせのいずれも対象と説明されました。

2025年6月の文書変更

Googleは、2025年6月11日の更新で、多言語の文書から、自動翻訳したページをrobots.txtでまとめてブロックする、という記述の節を削除しました。更新履歴には、2024年3月のスパムポリシー更新に合わせた、文書だけの変更で、動作は変わらないと書かれています。

この変更は、翻訳したことよりも、価値の低いページを大量に作ることが問題とされている、と読むのが自然です。どの程度から価値が低いとされるのか、具体的な基準は示されていません。

生成AIで作ったページの扱い

Googleの生成AIに関する文書も、読者への付加価値なしに多数のページを作ると、スパムポリシーに違反するおそれがあると述べています。機械翻訳にも、同じ考え方が当てはまると、筆者は考えます。

実務での進め方

機械翻訳を使う場合は、次の順で進めるのが安全です。

1. 公開するページを絞る。会社概要、主要なサービス、問い合わせなど、海外の利用者が必要とするページから始める
2. その言語が分かる人が、事実の誤り、不自然な表現、専門用語の訳を確認する
3. 現地の利用者向けに、対応地域、取引の条件、問い合わせの方法を足す
4. 翻訳していない部分を残さない。本文は日本語のまま、メニューだけ英語というページは使いにくい

直訳に近いページより、現地の利用者に役立つ情報を足したページのほうが、読者の役に立ちます。

社名・サービス名の各言語表記をそろえる

英語表記の揺れは意外と多い

日本の会社の英語表記には、次のような揺れがよく見られます。

揺れの例	起きやすい場所
Co., Ltd. と Corporation と Inc. の混在	英語版のサイト、名刺、英文の会社案内
大文字と小文字、ローマ字の綴りの違い	ロゴ、SNSのアカウント名
サービス名のカタカナと英字の混在	日本語版のサービス紹介のページ

表記が違うと、同じ会社だと気付いてもらいにくくなると、筆者は考えます。AI検索サービスがどう扱うかは、公式資料から確かめられませんでした。

表記台帳に言語ごとの列を作る

社内で次のような台帳を作り、サイト制作や翻訳の担当者と共有します。記入例は架空の会社のものです。

項目	日本語	英語
正式な社名	株式会社サンプル	Sample Co., Ltd.
略称	サンプル	Sample
主要なサービス名	サンプル分析	Sample Analytics
事業内容の1文	中小企業向けにデータ分析を支援する会社	A company that helps small businesses analyze their data

英語の社名は、名刺や契約書など、すでに使っているものとそろえます。

サイト名はドメインかサブドメインの単位

Googleのサイト名の文書によると、検索結果に出るサイト名は、ドメインまたはサブドメインの単位で決まります。サブディレクトリ単位のサイト名には対応していないと明記されています。

そのため、/en/ のサブディレクトリ方式では、日本語版と英語版で同じサイト名になると考えられます。どちらの言語の名前を使うか、台帳で決めておきます。

別名はalternateNameで伝えられます。

検索の翻訳機能とAI検索

公式に確認できること・できないこと

英語で質問された場合に、AIが日本語のページを読んで英語で答えるのかは、気になる点です。確認できた範囲を表にします。

事柄	公式の説明
検索語と違う言語の結果の、タイトルと説明文を翻訳して見せる	あり。Googleの翻訳された検索結果の文書
結果の言語は、言語設定だけでなく複数の手がかりで決まる	あり。2023年9月のGoogleの公式ブログ
AI機能やChatGPT、Perplexityが、別の言語のページを回答に使う条件	確認できる公式の説明は見つからなかった

Googleの翻訳された検索結果

Googleは、検索語と違う言語のページについて、タイトルのリンクと説明文を翻訳して表示することがあります。利用者が開くと、機械翻訳されたページが表示されます。

Googleが翻訳したページを自社で保管しているわけではありません。

この機能は、サイト側で何もしなくても適用されます。やめたい場合は、notranslateのルールを、robotsのメタタグやHTTPヘッダーで指定します。

Search Consoleでは、検索の見え方のフィルタで、この表示のクリック数と表示回数を確認できます。

複数言語で検索する人への配慮

2023年9月のGoogleの公式ブログは、複数の言語を使う人が検索するとき、言語設定だけに頼らず、複数の手がかりから、見せる言語を決めると説明しています。

同じブログは、複数の言語が日常で使われる地域のサイト運営者に、広く理解される1つの言語だけでなく、それぞれの言語で内容を作ることを勧めています。

よくある間違い

実際の多言語サイトで起きやすい間違いを、表にまとめます。

間違い	正しい状態
日本語のコードをjpにしている	jaを使う
英語版から日本語版へのhreflangがない	全言語版に同じ一覧を書き、互いに指し合う
自分自身のhreflangを書いていない	自分自身を含めて列挙する
すべての英語版が英語のトップページを指している	ページごとに、対応する言語版を指定する
英語版のcanonicalが日本語版を指している	各言語版のcanonicalは自分自身を指す
英語版のhtmlのlang属性がjaのまま	言語版ごとに正しい値を設定する
hreflangのURLが転送される、または404になる	実際に表示される最終のURLを書く
ブラウザの言語で自動的にリダイレクトしている	切り替えリンクを置き、利用者に選んでもらう
機械翻訳のまま全ページを一括で公開する	重要なページから、確認を入れて公開する

URLを書くときは、末尾のスラッシュの有無や、httpとhttpsの違いにも注意します。実際のページのURLと、一字一句同じにします。

JavaScriptで翻訳文を後から差し込む仕組みでは、クローラーに元の言語しか見えない可能性があります。確認方法は、AIクローラーとJavaScriptで説明しています。

公開前と定期点検のチェックリスト

公開前と、その後は四半期に1回ほど、次の項目を確認します。

区分	確認すること
URL	言語ごとに別のURLになっている
URL	Cookieやブラウザの言語で、同じURLの内容を切り替えていない
URL	言語を推測した自動リダイレクトをしていない
URL	全ページから、他の言語版へ切り替えるリンクがある
hreflang	指定方法を1つにそろえている
hreflang	各ページに、自分自身を含む全言語版が並んでいる
hreflang	言語版どうしが互いに指し合っている
hreflang	言語コードが正しい（日本語はja、英語はen）
hreflang	x-defaultを決めている
hreflang	URLがすべて正常に表示される
canonical	各言語版のcanonicalが自分自身を指している
lang属性	言語版ごとに正しい値になっている
内容	1ページが1つの言語で書かれている
内容	機械翻訳したページを、その言語が分かる人が確認している
内容	料金、所在地、サービス内容が、全言語版で最新になっている
表記	社名とサービス名が、表記台帳どおりにそろっている
公開設定	robots.txtやnoindexで、意図せず英語版を止めていない

Search Consoleの検査のツールでは、英語版がインデックスされているか、Googleがどのページを正規に選んだかを確認できます。英語版の正規ページに日本語版が選ばれていたら、canonicalとhreflangを見直します。

よくある質問

Q1. 英語版は全ページ作らないといけませんか。

いいえ。英語版があるページだけにhreflangを設定すれば問題ありません。

Googleのブログも、サイトの一部だけにhreflangを付けることを認めています。

会社概要、主要なサービス、問い合わせなど、海外の利用者が必要とするページから始めるのが現実的です。

Q2. サブディレクトリとサブドメインは、AI検索ではどちらが有利ですか。

AI検索でどちらが有利かについて、公式の説明は見つかりませんでした。Googleの文書は、それぞれに保守の手間やサーバーの場所などの違いがあると説明しています。

日英2言語の中小企業なら、1つのドメインで管理できるサブディレクトリが運用しやすいと、筆者は考えます。

Q3. 機械翻訳したページは、noindexにすべきですか。

一律にnoindexにする必要があるとは言えません。Googleは2025年6月に、自動翻訳ページをrobots.txtでまとめてブロックする記述を、文書から削除しました。

問題とされるのは、価値の少ないページを大量に作ることです。確認して整えたページは通常のページとして扱い、確認できていない翻訳ページを大量に公開するのは避けます。

Q4. hreflangを設定すれば、英語で聞かれたときにAIが英語版を引用しますか。

保証はありません。hreflangは、Googleが検索結果で言語版を選ぶための手がかりです。

AI検索サービスがhreflangをどう扱うかは、公式資料から確かめられませんでした。

ただし、各言語版が正しくインデックスされることは、参照されるための前提になります。

Q5. lang属性は、直さなくてもよいのでは。

Googleの言語判定には使われませんが、W3Cは正しく付けるよう勧めています。読み上げのソフトなど、別の目的で使われるため、言語版ごとに正しい値にしておきます。

まとめ

多言語サイトのAI検索対策は、特別な技術よりも、どの言語の人にどのページを見せるかを正しく伝える基本の積み重ねです。

1. 言語ごとにURLを分け、Cookieや自動リダイレクトでの切り替えを避ける
2. hreflangで、自分自身を含む全言語版を互いに指し合わせ、x-defaultを決める
3. canonicalは各言語版自身に向け、htmlのlang属性も正しく付ける
4. 機械翻訳は確認を入れ、価値の低いページを大量に作らない
5. 社名とサービス名の各言語の表記をそろえ、どの言語版も最新に保つ

AIが別の言語のページをどう使うかは、公式に明らかになっていない部分があります。どの言語のページが読まれても、正しい情報が伝わる状態にしておくことが、確実な備えです。

まずは、チェックリストで自社サイトの現状を確認するところから始めてください。

参照した公式文書

2026年10月18日に確認しました。

• Google検索セントラル、多言語・多地域サイトの管理
• Google検索セントラル、ページの別言語版をGoogleに伝える方法（hreflang）
• Google検索セントラル、ロケール適応ページのクロール
• Google検索セントラルブログ、How x-default can help you（2023年5月）
• Google検索セントラルブログ、How Google Search handles multilingual searches（2023年9月）
• Google検索セントラル、重複URLの統合と正規化に関する文書
• Google検索セントラル、スパムポリシーと2025年の文書更新履歴
• Google検索セントラル、翻訳された検索結果、サイト名、AI機能と自社サイト
• W3C、HTMLページの言語の指定に関する文書、WCAG 2.2の解説文書

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。