多言語GEO：どの言語でも引用されるために
GEOのガイドはほぼすべて英語だけのサイトを前提にしています。私のサイトはそうではなく、13言語で運営しています。英語の外側に目を向けた途端、3つのことが壊れているか、期待より機能していませんでした。hreflang/x-defaultの正しさ、llms.txtのカバー範囲、言語間でのスキーマの一貫性です。ここでは実際に何が変わるのかと、多言語サイトを一度でチェックするために使っている監査プロンプトを紹介します。
毎週水曜。28,400人以上の読者。無駄なし。
✓ メールをご確認ください — 確認リンクをクリックして登録を完了してください。
✓ 登録が完了しました！
✓ すでに登録済みです。
2026年9月公開。
TL;DR: GEOのガイドはほぼすべて英語だけのサイトを前提にしています。私のサイトはそうではなく、13言語で運営しています。英語の外側に目を向けた途端、3つのことが壊れているか、期待より機能していませんでした。hreflang/x-defaultの正しさ、llms.txtのカバー範囲、言語間でのスキーマの一貫性です。ここでは実際に何が変わるのかと、多言語サイトを一度でチェックするために使っている監査プロンプトを紹介します。
[オペレーターの視点] 私が読んできたGEOのチェックリストは、自分で書いた2本を含めて、すべて単一言語向けに書かれていました。その助言がどれだけ英語を前提にしていたかに気づいたのは、スペイン語版と日本語版のページが英語のオリジナルと同じ扱いを受けていない理由を調べに行ったときでした。中身も、スキーマのテンプレートも同じなのに、結果はまったく違っていたのです。
目次
目次を開く
多言語GEOが「SEOをあと12言語分」では済まない理由
従来の国際SEOには確立された手順があります。hreflangタグを設定し、コンテンツを翻訳すれば完了です。GEOはその手順ではカバーできない層を加えます。AIエンジンはページをインデックスするだけでなく、クエリごと、言語ごとに、ユーザーへ引用する唯一の情報源をそのつど決めているからです。この判断はエンジンが対応する言語ごとに別々に行われ、競合の顔ぶれも、引用に値する情報源のプールも、時にはエンジン自体も異なります。
英語でのChatGPTの回答は、同じ質問を日本語でしたときとは異なる候補プールから生成されています。ここを無視すると、GEOの作業は英語だけで一度行い、それが自動的に他言語へ伝わると思い込むことになります。そうはなりません。
最初に壊れるもの：hreflangとx-default
これはエラーとして表に出ることなく、可視性だけを静かに削っていくものです。2つの失敗パターンがあり、どちらも目に見えません。
- x-defaultの欠落または誤り。 hreflangのクラスターにはそれぞれ
x-defaultのエントリが必要で、これはどの翻訳とも言語が一致しない訪問者にどのバージョンを表示すべきかをエンジンやクローラーに伝えます。これを省くと、ターゲットの定まらないすべてのクローラーに「推測してくれ」と言っているのと同じです。 - hreflangが実際の翻訳ではないページを指している。 見た目以上に厄介で、よくある問題です。言語切り替えのリンクが、翻訳がまだ存在しない言語ではその言語のトップページへフォールバックし、その予備リンクにも
hreflangを付けている場合、英語のみの記事が自分自身のスペイン語訳であると主張していることになります。実際にはそうではありません。Googleのクローラーはやがてクラスター全体を信用しなくなり、あなたの<link>タグから引用のグラフを構築するAIエンジンも同じ欠陥のある信号を引き継いでしまいます。
私自身、まさにこのバグを抱えていました。ヘッダーの言語切り替えは、翻訳がまだ存在しないためにその言語のトップページへフォールバックしたリンクも含め、すべての言語リンクにhreflangを出力していました。英語のみの記事は、実際には存在しない12個の翻訳があるかのように静かに主張していたことになります。問題が見つかってしまえば修正は機械的でした。実際に翻訳が存在するときだけhreflangを付け、クラスターに英語のメンバーがない場合は最初に利用可能な代替へフォールバックしつつ、常にx-defaultを出力するようにしたのです。これで実在するすべてのクラスターにx-defaultが備わります。
実際にページの<head>にレンダリングされる修正後の形は次のようになります。
<link rel="alternate" hreflang="es" href="https://example.com/es/post-slug/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/post-slug/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/post-slug/" />自分のサイトで、この順番で確認する価値のある3つのルールがあります。すべてのhreflangクラスターにちょうど1つのx-defaultがあること。実際の翻訳ではないページを指すhreflangリンクがないこと。同じクラスター内で同じコードを共有する<link>タグが2つ以上ないこと(重複があると、Googleはその重複だけでなくクラスター全体を破棄します)。
誰も確認していない穴：llms.txtは英語しかカバーしていない
llms.txtは、クローラーに自分でクロールして推測させる代わりに、優良コンテンツを厳選したインデックスとしてAIクローラーに渡すための新しい慣習です。私はこのサイト用に数か月前に作りました。それに気づいたのは、この記事のためにデータを探していたときでした。どの記事をインデックスに含めるかを選ぶフィルターがlang === 'en'だけを見て止まっていたのです。
つまり、このサイトのコンテンツの13分の12は、llms.txtを単なる提案ではなくインデックスとして扱うクローラーにとって見えない状態だったということです。英語以外の記事はサイトマップや内部リンク経由でクロールされ続けますが、AIエンジンに最良のページを渡すために特別に構築された、厳選され信頼度の高いインデックスは、意図的にではなく見落としによって英語オンリーになっていました。
多言語対応のllms.txtを運用しているなら、今すぐ確認してください。そのファイル(またはファイル群)は本当に翻訳された記事を列挙していますか、それとも私のものと同じように、インデックスが静かに元の言語だけに縮小していませんか。英語のURLしか列挙していない共有のllms.txtが1つあること自体は、厳密には間違いではありません。ただ、サイトが存在する他の言語には何の役にも立っていないというだけです。
言語をまたいだスキーマとエンティティの一貫性
すでに導入しているFAQPage、Article、Personのスキーマ(まだ設定していない場合はスキーママークアップの解説を参照してください)は、どの言語でもあなたについて同じことを語っている必要があります。AIエンジンはこれらすべての言語をまたいで、1つのエンティティグラフを構築しているからです。
正しくすべき点は2つあります。
- 識別子は翻訳せず、人間向けの文字列だけ翻訳する。
PersonまたはOrganizationスキーマの@id、url、sameAs配列、jobTitleの値は、どの言語でも同一でなければなりません。これがエンジンに「言語をまたいで同じエンティティだ」と伝える手段です。変わるのは周囲のテキストと、人間が読むためのラベルだけです。 - 古い翻訳がスキーマに置いていかれないようにする。 Articleスキーマの
dateModifiedを更新したり、英語版にFAQの項目を1つ追加したりしたら、同じ変更をすべての言語のJSON-LDにも反映させる必要があります。テキストだけではありません。先週更新された英語のコンテンツと、半年前のスキーマのままのフランス語版の同じページを見たエンジンは、それを1つのページの2言語版としてではなく、2つの別ページとして読み取ります。
言語が違えば、AIエンジンも違う
GEOをめぐる議論は、デフォルトでChatGPT、Perplexity、Google AI Overviewsを前提にします。英語圏の会話がそこで行われているからです。しかし、ロシア語、中国語、韓国語で発信するようになった途端、それは全体像ではなくなります。
Yandexはロシア語のクエリに対して独自の生成的な回答レイヤーを持っており、ロシア語検索におけるシェアはGoogleを明らかに上回っています。BaiduのERNIEベースの回答は中国語にとって重要です。Naverの AI要約は韓国語にとって重要です。GEOのチェックリストが米国中心の3つのエンジンしか考慮していないなら、国際的な読者が実際に使っている回答エンジンのうち、おそらく60%程度しか最適化できていないことになります。しかも、それらのエンジンはどれもGoogle Search Consoleには表示されないため、気づくことすらできません。
ここからYandexやBaiduでの引用率をきれいに確認する方法は私にはなく、それをごまかさずにそのまま言います。言えるのは、英語向けに最適化しているのと同じ3つのエンジンのリストが、どこでも完全なリストだとは思わないほうがいいということです。
自分のサイトから得られた実際の証拠
これは私が実際に測定できるものです。同じGEO対SEOの比較記事、同じコンテンツテンプレート、同じスキーマを、それぞれの言語に翻訳したものです。データはSearch Consoleの2026年6月15日から9月11日までのものです。
| 言語 | インプレッション数 | 平均掲載順位 |
|---|---|---|
| スペイン語 | 2,077 | 31.9 |
| オランダ語 | 3,370 | 46.6 |
| フランス語 | 1,393 | 25.1 |
| 日本語 | 106 | 14.8 |
| 韓国語 | 57 | 24.9 |
| ドイツ語 | 86 | 60.6 |
| イタリア語 | 32 | 67.8 |
| 英語 | 569 | 58.2 |
同じ記事、同じ構成、同じスキーマテンプレートなのに、順位の幅は14.8位から67.8位まで広がっています。これが何を証明し、何を証明しないのかについては正直に言っておきたいと思います。これはSearch Consoleから得た古典的なGoogleの掲載順位であり、AI引用のデータではありません。ChatGPTやPerplexityの引用を言語別にきれいに帰属させる手段は私にはなく、それを持っている人も知りません。これが証明しているのは、「翻訳すれば同じ最適化作業がどこでも均等に効く」という考えが、自分のサイトにおいてさえ誤りだということです。日本語版はインプレッション数がごくわずかにもかかわらず、英語のオリジナルを含む他のすべての言語より順位で上回っています。競合状況、翻訳の質、日本語でのエンティティの解決のされ方など、このページの何かが、まったく同じスキーマテンプレートを使っているドイツ語やイタリア語では機能していない形で機能しているのです。
Claude やChatGPTにやらせる：多言語GEO監査プロンプト
hreflangの仕様を読む必要はありません。サイトのURLとともに、これをClaudeやChatGPTに貼り付けてください。
複数言語のコンテンツを持つウェブサイトを運営しています。[URL]について、次を確認してください。(1) ページが
x-defaultのhreflangタグを出力しているか、ページ上のすべてのhreflangタグが予備のトップページではなく実際の翻訳を指しているか。(2) ページのJSON-LDスキーマ(Person、Organization、Article)が、言語をまたいで@id、url、sameAsに同一の値を使っているか、それとも言語ごとに異なっているか。(3) サイトにllms.txtファイルがある場合、英語以外の言語のページを列挙しているか。これらのうちどれが失敗しているかを正確に教えてください。一般的な要約ではなく、問題のある具体的なタグやフィールドを引用してください。
信用する前に、その回答を実際のページのソースコードと照らし合わせて確認してください。実物を見せなければ、モデルは存在しないx-defaultタグを自信満々に説明してしまいます。
避けるべきこと
サーバーログでサブドメインごとのAIクローラーのアクセスが確認できるといった実際の根拠もなく、勘だけで、エンジンがあなたの各言語を別のプロパティとして扱っていると判断して、13個も別々のllms.txtファイルを作らないでください。翻訳済みのURLを実際に列挙する、範囲の明確な1つのファイルがあれば、13ファイルを維持する手間なしに上記の穴を塞げます。
言語の欄を埋めるためだけに、機械的にページを翻訳しないでください。薄っぺらで直訳的な翻訳は、翻訳がまったくない状態よりもGEOにとって悪影響です。競合のネイティブ言語のコンテンツと比較される際に、AIエンジンへ低品質な情報源を渡すことになり、サポートフォーラムで「変な翻訳のサイト」として引用される最短ルートになります。
結論
自分のGEOチェックリストが単一言語向けに書かれているなら、システムとして信頼する前に、成績が最も悪い言語でそれを試してみてください。私のサイトには、確認するまで数か月も気づかなかった実在の静かなhreflangのバグと、英語オンリーの引用インデックスがありました。どちらも簡単な修正でした。もし2つ目の言語を念頭に置いて探しに行かなければ、どちらも表には出てこなかったはずです。
多言語GEO — よくある質問
hreflangは本当にAIエンジンの引用に影響するのか、それとも従来のGoogleランキングだけなのか
両方に影響しますが、そのしくみは異なります。従来のGoogleでは、hreflangはどの言語に対してどのURLを検索結果に表示すべきかをクローラーに伝えます。AIエンジンでは、hreflangとスキーマが合わさって、「言語をまたいでこれが同じエンティティ/コンテンツかどうか」をエンジンが判断する材料の一部になります。ここを誤ると、英語版とスペイン語版のページを、1つのテーマが2回扱われているものとしてではなく、無関係な情報源として扱われるリスクがあります。
サイトが対応しているすべての言語に、すべての記事を翻訳すべきか
いいえ。そのテーマとその市場での検索需要が見合う記事だけを翻訳してください。米国限定の料金ガイドはアラビア語訳が不要かもしれませんが、GEOに関するグローバルな解説記事はおそらく必要でしょう。言語間で未翻訳のほぼ重複したコンテンツを持つより、記事数が少なくても完全に翻訳されているほうがましです。
自分のllms.txtの範囲が正しく設定されているかどうか、どう確認すればよいか
ファイルを開いて、列挙されているURLに元の言語以外のパスが含まれているか確認してください。すべてのURLが1つの言語で、サイトが複数言語で公開されているなら、それが意図的かどうかにかかわらず、インデックスはその1言語だけに限定されています。
言語ごとに別々のスキーマが必要か、それとも1つのスキーマブロックをどこでも使い回せるのか
1つのエンティティを、翻訳された形で提示します。識別用のフィールド(@id、url、sameAs)は言語をまたいで同一のままにし、人間が読むテキスト(headline、description、FAQの回答)は言語ごとに翻訳します。これは複数のエンティティではなく、複数の言語で説明された1つのエンティティとして扱ってください。
関連記事： GEOのためのスキーママークアップ · 1つのエージェントでブログ記事を13言語に翻訳する方法 · ひとり運営のGEO
自分のサイトの多言語設定について、第三者の目でチェックしてほしいですか？ お問い合わせください。複数言語で公開しているサイト向けにGEO監査を行っています。今日すぐ確認したい場合は、上のプロンプトをClaudeで自分で試してみてください。
毎週水曜。28,400人以上の読者。無駄なし。
✓ メールをご確認ください — 確認リンクをクリックして登録を完了してください。
✓ 登録が完了しました！
✓ すでに登録済みです。
関連記事
AIプレイブックをメールでお届け
毎週水曜。28,400人以上の読者。無駄なし。
メールをご確認ください。
確認メールをお送りしました — リンクをクリックして登録を完了してください。1分以内に届かない場合は迷惑メールをご確認ください。
登録が完了しました。
ようこそ — 次号がまもなくお手元に届きます。
すでに登録済みです — 毎週水曜日にお届けします。