多言語SEOでよくある間違いとその修正方法

多言語SEOで問題が起こるパターンは、ある程度決まっています。翻訳に投資して言語別フォルダを公開しても、検索結果に意図しないURLが表示されたり、ローカライズしたURLがまったく表示されなかったりします。こうした失敗の大半は、不可解なアルゴリズムの更新が原因ではありません。Google自身が多言語サイト向けドキュメントで警告している実装上の不備です。たとえば、発見できない言語版、不完全なhreflangクラスタ、canonicalの競合、翻訳と地域ターゲティングを同一視した戦略の混同などが挙げられます。

この診断ガイドでは、影響の大きい間違いを深刻度順にまとめています。既存サイトの監査や、公開前の可否判断にご活用ください。各セクションはGoogleの公式ガイダンスに基づき、それぞれの概念を詳しく扱う解説を案内しています。戦略については国際SEOと多言語SEOの違い、アノテーションについてはhreflangの仕組み、コンテンツの充実度については翻訳とローカライズの違い、そして多言語SEO施策全体の設計を参照できます。

このガイドでわかること

• Googleのドキュメントに照らして、よくある多言語SEOの間違いとは？
• CookieやIPアドレスによる言語切り替えが検索でうまく機能しないのはなぜ？
• hreflangクラスタが不完全だと、どのような問題が起こる？
• 共通部分だけの翻訳は検索結果にどう悪影響を及ぼす？
• 同じ言語で複数の地域を対象とするサイトでは、どのようなcanonicalの間違いが起こる？
• 多言語対応と多地域対応の要件は、どのように混同される？
• 公開後に修正しにくいサイト構造の間違いとは？
• 複数の問題が同時にある場合、修正の優先順位をどう決める？

要点：言語版を発見できなくする間違い

要点はシンプルです。対象言語がコンテンツの大部分を占める、安定したURLをGooglebotがクロールできなければ、多言語SEOは意図どおりに機能しません。Googleは、1つのURLでCookieやブラウザ設定に応じて言語を切り替えるのではなく、言語版ごとに異なるURLを使用することを推奨しています。ページの言語は、HTMLのlang、URL、hreflangではなく、実際に表示されるコンテンツから判断されます。リターンリンクが欠けた不完全なhreflangは無視されます。また、同じ言語で内容が似たページが国別に存在する場合は、canonicalとhreflangの併用が推奨されています。

すべてに問題がある場合は、まずクロール可能な個別URLを確保し、次にhreflangの相互参照、canonicalの方針、コンテンツの充実度の順で修正します。本文を単一言語のまま残し、ナビゲーションだけを表面的に翻訳するのはコンテンツ上の間違いですが、URLが発見できない場合と同じように検出そのものを妨げることは、ほとんどありません。

間違いの深刻度マップ

すべてのエラーに同じ緊急度で対応する必要はありません。影響の大きさと修正コストを比較して、作業の順序を決めましょう。

影響度の評価は、確認されている問題のパターンを示すものであり、検索順位へのペナルティを保証するものではありません。復旧コストは、エンジニアリング、リダイレクト、コンテンツに必要な作業量を表します。Googleが明示していない所要期間を示すものではありません。

Cookie、IP、自動リダイレクトによる言語切り替え

よくある誤り：すべての言語を1つのURLで提供し、Cookie、セッション変数、Accept-Language ヘッダー、またはIPアドレスによる位置情報の照合を使って、読み込み後にテキストを切り替える。

問題が起きる理由：Googlebotは Accept-Language なしでクロールすることが多く、通常は米国内のインフラからアクセスします。デフォルトのクロールで英語しか確認できなければ、ほかの言語はインデックスに登録されない可能性があります。また、ユーザーがリンクを共有した場合も、受け取った人にはデフォルトの言語が表示されます。

Googleの指針：言語バージョンごとに異なるURLを使用します。地域や言語を選べるリンクをユーザーに提示してください。ユーザーの言語を推測して自動リダイレクトすると、ユーザーや検索エンジンがすべてのバージョンを閲覧できなくなる可能性があります。

修正の進め方：

1. 各言語に専用のURLを割り当てる（フォルダ、サブドメイン、またはccTLD）
2. 旧来の単一URL方式でインデックスに登録されているURLに301リダイレクトを設定する
3. ユーザーに知らせずに言語を切り替えるのではなく、画面上に言語セレクターを設ける
4. 位置情報を手がかりにする場合は、最も適したロケールを強制せず、提案する

例：Cookie lang=de がある場合にのみドイツ語を表示する example.com/pricing は、example.com/de/pricing に変更し、/en/pricing と /de/pricing へのリンクを備えたセレクターを設けます。

不完全または無効なhreflang

よくある誤り：一部のテンプレートにhreflangタグはあるものの、クラスター内のリンクが一方向になっている、相対URLを使っている、リダイレクト先を指している、または無効な地域コードを使っている。

問題が起きる理由：2つのページが相互に参照していない場合、hreflangタグが無視されることがあります。Googleは、en-GB の代わりに en-UK を使うことや、eu を地域として使うことなど、無効なコードの使用をよくあるエラーとして挙げています。hreflangは代替バージョンを宣言するものであり、ページの言語を設定するものではありません。

主な症状：

• 正しい言語のURLが存在するのに、検索結果には別のロケールが表示される
• Search Consoleのhreflangレポートにリターンタグやコードのエラーが表示される
• グローバル向けのフォールバックページがあるのに、x-default がない

修正の進め方：

1. ローカライズされたすべてのURLをマトリクスに整理する
2. 各ページに、そのページ自身とすべての代替バージョンを絶対URLで記載する
3. 相互参照を検証する（A → B があれば B → A も必要）
4. コードをISOの言語・地域規格に合わせる
5. 必要に応じて x-default を追加する

クラスターの詳しい仕組み、サイトマップとHTMLでの実装の違い、QAツールについては、関連記事「hreflangクラスターの仕組みを独立した技術作業として扱う」で解説します。このセクションでは誤りを指摘するにとどめ、具体的な修正手順はそちらで扱います。

共通部分だけが翻訳された、内容の乏しい言語バージョン

よくある誤り：ナビゲーション、フッター、ボタンは翻訳されているのに、商品説明、記事、法的文書などは原文のままになっている。

問題が起きる理由：Googleは画面に表示されるコンテンツから言語を判定します。大部分が英語のページは、hreflangやフォルダ名にかかわらず英語として扱われます。Googleは、主要コンテンツを翻訳せずに共通部分だけを翻訳すると、同じコンテンツが共通部分の言語だけを変えて繰り返し表示され、ユーザー体験を損なうと明確に警告しています。

主な症状：

• /fr/ のURLが英語の検索クエリで検索結果に表示される
• 対象ロケールのユーザーの直帰率が高い
• 「翻訳済み」のページが人手による言語QAに合格しない

修正の進め方：

1. テンプレートごとに最低限翻訳すべき範囲を定める（ヒーローエリア、本文、メタデータ、構造化されたテキスト）
2. 主要コンテンツが基準を満たすまで公開を止める
3. 用語集と翻訳メモリは一貫性を保つために活用し、YMYLページでの人手によるレビューの代わりにはしない
4. 真のローカライズ（市場に合わせたオファー、単位、具体例の調整）と直訳を区別する。コンテンツ担当者は、真のローカライズと直訳を明確に分けて考える必要がある

編集上の管理基準を設けずに機械翻訳を大規模に行うと、有用なコンテンツに求められる要件にそぐわない、内容の乏しいページを生み出す可能性もあります。自動化そのものが誤りなのではありません。読みにくいページや、既存ページと同じ価値しか提供しないロケール別ページを公開することが問題なのです。

複数地域向けサイトにおけるcanonicalの競合

よくある誤り：example.com、example.co.uk、example.com/en-gb/ にある類似した英語ページがそれぞれ自分自身を正規URLとして宣言している。または、グローバル向けの .com を正規URLに指定した結果、国別URLが候補から外れてしまう。

問題が起きる理由：複数地域のURLに同じ言語の類似コンテンツがある場合、Googleは優先するバージョンを選び、rel="canonical" とhreflangを併用することを推奨しています。これにより、適切な言語や地域のURLを表示できます。hreflangを使う場合は、同じ言語の正規URLを指定してください。同じ言語の正規URLが存在しない場合は、利用可能な言語のうち最も適切な代替言語を指定します。

よくあるパターン：

• すべての国別ページで米国英語版を正規URLに指定している
• ccTLDとgTLD配下のフォルダに重複ページがあり、優先するURLが指定されていない
• canonicalの参照先がリダイレクトチェーンやパラメータ付きURLになっている

修正の進め方：

1. 同一言語内にほぼ重複するコンテンツがある場合、どのURLを優先するかを明文化する
2. 必要に応じて、優先するURLパターンに自己参照canonicalを設定する
3. hreflangクラスターを維持しつつ、同一言語内の重複コンテンツではcanonicalで優先URLを示す
4. 完全な重複ページは廃止し、実際の市場の違いを反映した正当な地域別バージョンは維持する

ローカライズ版が重複と見なされるのは、主要コンテンツが未翻訳のままの場合に限られます。地域別の価格説明や現地の法的事項に関するセクションがあれば、別々のURLを設ける根拠になります。

多言語対応と多地域対応の目的の混同

よくある間違い：市場に合わせて商品カタログ、通貨、受注から配送までの対応を変える必要があるのに、ある国への進出を「サイトの翻訳」だけで済ませようとすること。または、対応言語を増やすだけなのに、地域ターゲティングとして扱うことです。

うまくいかない理由：多言語SEOは、ユーザーが理解できる言語で情報を届けるための施策です。多地域SEOは、国ごとに適した体験を提供するための施策です。両方に取り組む場合は、URLを設計する前に「国×言語」のマトリクスを作成する必要があります。目的を混同すると、フォルダ名、hreflangの値、canonicalのルールを誤って設定してしまいます。

例：

• マトリクス上では/es/にes-MXのコンテンツとメキシコ向けの購入手続きが必要なのに、メキシコのスペイン語向けに/mx/を追加する
• ドイツという国を対象にするのではなく、世界中のドイツ語話者を対象に.deのccTLDを使う
• 言語ではなく配送先の国だけが異なるページに、hreflang enを設定する

国際SEOと多言語SEOの違いを参考にマトリクスを修正してから、このページに戻って実装の順序を確認してください。

後から修正しにくいアーキテクチャの間違い

アノテーションを直すだけですぐに解決するミスもあれば、将来のリダイレクト対応という負債を抱え込むミスもあります。

国際サイトのアーキテクチャについては、URLパターンを詳しく解説する専用ガイドが必要です。その公開までは、パラメータを主な区分手段にする設計や、意味が文書化されていないフォルダを、公開後の修正事項ではなく、公開前に解決すべき必須事項として扱ってください。

lang属性やパス内のコードで言語が判定されると思い込む

よくある間違い：QAでhtml lang="fr"しか確認しない、または/fr/があればフランス語の検索でのランキングが保証されると思い込むことです。

うまくいかない理由：Googleは、HTMLのlang、URL、hreflangではなく、画面に表示されるコンテンツから言語を判定します。対象ユーザーを明示的に対応付けない限り、サブドメインやサブディレクトリのコードが対象ユーザーの判定に使われることはありません。

修正の進め方：

1. 各ロケールのテンプレートごとに、表示内容を人が実際に読んで確認する
2. 本文に原文の言語が残っていないか自動チェックする
3. hreflangとアーキテクチャをマトリクスに合わせる。ただし、コンテンツ自体の言語への対応をそれらで代替しない
4. Search Consoleの検索クエリをページURLで絞り込み、言語別の検索パフォーマンスが意図に合っているか確認する

この間違いは、見つかれば低コストで修正できます。しかし、表示される言語の確認をチームが何か月も省略すると、大きな損失につながります。

修正の優先順位を決めるフレームワーク

複数の間違いが同時に存在する場合は、次の順序で対応してください。

フェーズ1 — ロケール別URLをクロール可能な状態に戻す（第1週の優先事項）

• CookieやIPに基づく単一URLでの切り替えをやめ、個別のURLを設ける
• 別バージョンの取得を妨げる強制リダイレクトを停止する
• ロケール別パスへのアクセスを妨げるrobots.txtの制限やログイン要件を解除する

フェーズ2 — アノテーションの整合性（第2〜3週）

• hreflangの相互参照と無効なコードを修正する
• 同一言語の国別重複ページでcanonicalの整合性を取る
• サイトマップを更新し、ロケール別の正規URLのみを記載する

フェーズ3 — コンテンツの実際の言語を確認・修正する（並行して実施）

• 定型部分だけが翻訳されたテンプレートは、noindexでインデックスから除外するか、翻訳を完了させる
• トラフィックの多いテンプレートと収益につながる導線を優先する
• YMYLページには用語集を適用し、人によるレビューを行う

フェーズ4 — 戦略とアーキテクチャの負債を解消する（四半期単位）

• 関係者と国×言語のマトリクスを見直す
• パラメータ方式や区分が曖昧なフォルダ構成からの移行を計画する
• アクセス解析とSearch Consoleでロケールごとの計測方法を統一する

フェーズ5 — 継続的な運用管理

• 新規ロケールの公開チェックリスト
• CMSや翻訳プラグインの更新時にリグレッションテストを実施する
• 英語のキーワードリストを翻訳するのではなく、市場ごとにキーワードを調査し、コンテンツの優先順位を決める。このフェーズは、市場別のキーワード調査でさらに充実させる必要がある

クロール対応やhreflangの整備と、コンテンツの品質改善スケジュールが両立しない場合は、クロール対応を優先します。正確な文章でも、見つけてもらえなければ誰の役にも立ちません。

復旧チェックリスト

• 対象となるすべてのロケールURLを一覧にし、Googlebotと同じ条件で各URLを取得する（Cookieなし、強制リダイレクトなし）
• 言語バージョンごとに固有のURLがあることを確認し、旧URLパターンからのリダイレクト対応表を文書化する
• サンプルとして抽出したテンプレートで、表示されるメインコンテンツが対象言語になっていることを確認する
• hreflangの相互参照、絶対URL、有効な言語・地域コード、参照先へのアクセス可否を点検する
• 同じ言語で複数の国を対象とするページ間のcanonicalの競合を解消する
• サイトマップにロケールURLが含まれ、パラメータによる重複がないことを確認する
• ユーザー向けの言語・地域切り替え機能を追加または修正する
• Search Consoleのカバレッジとhreflangのレポートをプロパティごとに検証する
• 国×言語のマトリクスを文書化し、戦略・アノテーション・コンテンツそれぞれの担当者を決める
• CMSや翻訳ツールのアップグレード後に再点検を行う予定を立てる

回答エンジン対応と複数プラットフォーム対応で起こりがちなミス

Googleだけを対象に最適化する

BingやMicrosoftの各サービスを無視すると、Search Consoleだけでは把握できないインデックスの抜けが残ります。BingがクロールできるロケールURLを公開し、Bing Webmaster Toolsで確認しましょう。

AI回答エンジンを無視する

多言語SEOを通常の検索結果への対策だけと捉えると、ChatGPT、Claude、Gemini、Perplexity、Copilotで引用されたり、情報源として採用されたりする機会を逃します。各言語のページは、主張を明確にし、地域に即したFAQとアクセス可能なHTMLを用意して、回答に活用しやすい状態にしておきましょう。

すべてのAIプラットフォームを同じものとして扱う

どのアシスタントにも同じ「AI SEO」の説明文を使い回すと、すべてが同じ仕組みで動いているかのような誤解を生みます。ChatGPTの引用の仕方、Perplexityの出典表示、Google AI Overviewsは、同一のランキングシステムとして扱えるものではありません。

回答を地域に合わせず、翻訳だけで済ませる

現地の事例や用語を取り入れずに直訳すると、その地域の検索意図に対して上位表示されにくく、文化的背景を踏まえた質問に答えるアシスタントの情報源としても役立たないページになります。

エンティティの一貫性が不十分

同じ企業であることを明確に示さず、言語ごとに異なる社名を使うと、ナレッジグラフのような仕組みによる情報の理解も、アシスタントによる推薦も混乱させます。

裏付けのない主張と質の低い引用

架空の統計や出典のないランキングは、検索における信頼性を損ない、調査用アシスタントにも引用されにくいページにしてしまいます。

アクセスできないページ

クライアント側だけで動作し、別言語のコンテンツをクローラーから見えなくする言語切り替え機能は、GoogleやBingのインデックス登録にも、回答エンジンからのアクセスにも悪影響を及ぼします。

プラットフォーム別ガイド：Google Search

多言語SEOの不具合の多くは、今でもGoogle Search Consoleで最初に見つかります。hreflangの不備、canonicalの競合、未翻訳のメインコンテンツなどです。既知の限界は明確に文書化しましょう。ランキング要因を勝手に作り上げず、従来のインデックス関連指標と回答エンジンでの引用確認を分けて扱ってください。

プラットフォーム別ガイド：Bing

Bing Webmaster Toolsでの確認を省き、Googleだけを見ていると、Microsoftのサービスで生じているロケール対応の抜けを把握できません。既知の限界は明確に文書化しましょう。ランキング要因を勝手に作り上げず、従来のインデックス関連指標と回答エンジンでの引用確認を分けて扱ってください。

プラットフォーム別ガイド：ChatGPT

英語のみ、またはアクセスできないロケールページは、英語でのGoogle検索順位が良好でも、ChatGPTが地域に役立つ回答を引用するうえではほとんど役に立ちません。既知の限界は明確に文書化しましょう。ランキング要因を勝手に作り上げず、従来のインデックス関連指標と回答エンジンでの引用確認を分けて扱ってください。

プラットフォーム別ガイド：Claude

内容の薄い翻訳では、Claudeなどで詳しい説明を求める、現地の用語や根拠が必要なプロンプトに対応できません。既知の限界は明確に文書化しましょう。ランキング要因を勝手に作り上げず、従来のインデックス関連指標と回答エンジンでの引用確認を分けて扱ってください。

プラットフォーム別ガイド：Gemini

従来のGoogle向けSEOを行えば、Geminiを含むあらゆるAI体験にも自動的に最適化されると考えるのは、文書で確認されている範囲を超えた主張です。既知の限界は明確に文書化しましょう。ランキング要因を勝手に作り上げず、従来のインデックス関連指標と回答エンジンでの引用確認を分けて扱ってください。

プラットフォーム別ガイド：Perplexity

裏付けのない主張や不十分な出典表示があると、ロケールページは調査目的のクエリで引用されにくくなります。既知の限界は明確に文書化しましょう。ランキング要因を勝手に作り上げず、従来のインデックス関連指標と回答エンジンでの引用確認を分けて扱ってください。

プラットフォーム別ガイド：Microsoft Copilot

Googleだけを対象にしたツール構成では、Bingにインデックス登録できるURL経路を見落とします。MicrosoftがサービスをBingと連携させている場合、こうした経路がCopilotに見つけてもらううえで重要になることがあります。既知の限界は明確に文書化しましょう。ランキング要因を勝手に作り上げず、従来のインデックス関連指標と回答エンジンでの引用確認を分けて扱ってください。

GlotEOが担う役割

最初のステップは問題の診断、次のステップはロケールURL・翻訳・アノテーションの整合性を継続的に保つことです。GlotEOの多言語SEOプラットフォームは、用語集の管理、レビューサイクル、クロール可能な言語バージョンなど、多言語運用の編集ワークフローを支援します。これにより、次のプラグイン更新やコンテンツ制作の集中期間を経ても、修正内容を維持できます。

hreflangの問題を悪化させる構造化データの不備には、ロケールごとにスキーマを検証して対処しましょう。再翻訳に取りかかる前の調査では、英語のキーワードリストを翻訳するよりも、市場ごとのキーワード調査を優先してください。

ワークフローを実際の運用に取り入れる準備ができたら、まずはGlotEOのSEOに最適化された多言語ウェブサイトを確認し、多言語ウェブサイトの料金をご覧ください。