Hreflang最適化時に、言語バージョン同士が競合するのはなぜですか？

公開日：07/09/2026

作者：易営宝（Eyingbao）

閲覧数：

Hreflang最適化において、言語バージョン同士が競合するのはなぜですか？本記事では、canonicalの不整合、双方向リンクの欠如、ターゲティングの重複、ページがインデックス不可であることなどの主な原因を解説し、多言語サイトの確認方法を紹介します。企業が言語バージョンのシグナルを統一し、誤ったインデックス登録やトラフィックの分散を減らすのに役立ちます。

今すぐ問い合わせ：4006552477

Hreflang アノテーションにおける「言語バージョン間の競合」とは、通常、コードを検索エンジンが読み取れないことを指すのではなく、同一のページ群が、相互に矛盾する言語、地域、正規化、インデックス可否のシグナルを同時に送信している状態を指します。その結果、検索エンジンは特定の言語または市場に対してどの URL を提供すべきか判断しにくくなり、誤ったバージョンをランキング対象として選択したり、一部の hreflang 関係を直接無視したりする可能性があります。

技術的な調査では、ページにrel="alternate"が存在するかどうかだけを確認してはなりません。Hreflang 最適化が実際に成立するかを決めるのは、URL のアクセス可能性、双方向の関係、言語・地域ターゲティング、canonical の参照先、およびページの実際の内容が、一貫したロジックを構成できているかどうかです。

競合の本質：同一のユーザーターゲットを複数の URL が奪い合う

有効な hreflang セットでは、明確な各言語または言語・地域の組み合わせに対し、唯一のインデックス可能な URL を割り当てる必要があります。例：

en：英語ユーザー向けの一般的な英語ページ；
en-US：米国市場向けの英語ページ；
en-GB：英国市場向けの英語ページ；
zh-CN：中国本土のユーザー向けの簡体字中国語ページ；
x-default：一致しない場合に使用するデフォルトバージョンまたは言語選択ページ。

競合は、2 つ以上の URL が同じオーディエンス向けとしてマークされているにもかかわらず、明確な優先関係がない場合に発生します。たとえば、/en/ と /us/ の両方が en-US としてマークされている場合です。あるいは、同一の英語ページが en、en-US、en-GB の唯一の代替ページとして同時に宣言されている場合も該当します。検索エンジンは、企業内部のディレクトリ命名に基づいて優先順位を推測することはなく、ページの宣言、コンテンツ、canonical、クロール状態が一致しているかのみを評価します。

したがって、ディレクトリパス内の/us/、/uk/、または国別トップレベルドメインは、それ自体が正しい地域ターゲティングを意味するものではありません。パスはデプロイ戦略を表現できますが、有効な hreflang 言語コードの代わりにはなりません。

最も一般的な競合は、4 種類のシグナルの不一致に起因します

1 ページが複数の異なる正規ページを参照している

hreflang と canonical では役割が異なります。hreflang は異なる言語または地域のユーザー向けの等価バージョンを識別するために使用され、canonical はコンテンツの重複度が高い場合の優先 URL を処理するために使用されます。両者は相互に代替すべきものではありません。

典型的な誤りとして、米国英語ページ/en-us/product-a/が hreflang では en-US として宣言されている一方、その canonical が一般的な英語ページ /en/product-a/ を参照しているケースがあります。これにより、検索エンジンは 2 つの矛盾した情報を受け取ります。1 つはそのページが独立した米国向けバージョンであるという情報であり、もう 1 つは別の URL の重複コピーにすぎないという情報です。そのページに実際に独立した市場価値があるなら、canonical は通常、自身を参照すべきです。一方、独立したコンテンツやサービス上の意義が実際にないなら、hreflang によって地域バージョンとして見せかけるべきではありません。

特に、パラメータ付き URL、大文字・小文字が異なる URL、末尾スラッシュのバージョン、HTTP/HTTPS バージョン、およびトラッキングパラメータ付きの広告ランディングページに注意が必要です。hreflang が最終的な正規 URL を参照していない場合、言語関係は不安定なアドレス上に構築されることになります。

戻りリンクが欠落し、言語セットが不完全である

hreflang 関係は、検証可能な閉ループを形成する必要があります。A ページが B をフランス語版として宣言する場合、B ページも A を対応する中国語版、英語版、またはその他のバージョンとして宣言し、自身への参照も含める必要があります。英語ページに 10 の言語バージョンが列挙されているのに、フランス語ページには自身と英語ページしか記載されず、残りのバージョンが記載されていない場合、検索エンジンはこれらのページを同一の完全なセットとして安定的に認識できません。

この種の問題は、テンプレートを段階的に公開した場合、CMS のマルチサイト設定が同期していない場合、または翻訳ページを後から追加した場合によく発生します。ページ数が多い場合、ソースコードを単純に抜き取り確認するだけでは信頼性が低く、ページテンプレート、言語ディレクトリ、URL マッピングルールに基づいて一括検証を行うべきです。

言語コードは有効でも、ビジネス上のターゲティングが重複している

言語コードが正しいからといって、ターゲティングが適切であるとは限りません。en は一般的な英語、en-US は米国英語です。pt は一般的なポルトガル語、pt-BR はブラジルポルトガル語です。一般言語ページと地域ページは共存できますが、前提として各ページの役割が明確でなければなりません。

たとえば、あるサイトでen、en-US、en-GBを同時に維持しているにもかかわらず、3 ページの価格、単位、連絡先、配送範囲、スペル、コンテンツが完全に同一である場合、技術的にはアノテーション可能でも、ビジネス上は区別する根拠に欠けます。この場合、問題は hreflang だけでなく、サイトが同種の検索ニーズを奪い合う複数の URL を人為的に作り出していることにもあります。

逆に、地域ページで誤ったコードを使用した場合も、同様に機能しません。hreflang の言語部分には ISO 639-1 言語コードを使用し、地域部分には ISO 3166-1 Alpha-2 の国または地域コードを使用します。形式は言語を先、地域を後にし、de-DE、ja-JPのように記述します。存在しないコード、コードの代わりに言語名を使用すること、または国コードを先に置くことは、いずれも解析上の問題を引き起こします。

ページ自体がインデックス不可能であるにもかかわらず、言語バージョンに含まれている

hreflang が参照する対象 URL は、正常にクロール可能な有効ページを返す必要があります。対象ページでリダイレクト、404、ソフト 404、5xx エラー、noindex、robots.txt によるクロール禁止が発生している、またはログインが必要な場合、言語関係はソースコード内に記述されていても機能しにくくなります。

さらに見つけにくいケースとして、地理的リダイレクトがあります。ユーザーまたはクローラーが一般的な英語ページにアクセスした際、サーバーが IP に基づいて自動的に米国ページへリダイレクトし、米国ページが hreflang で再び一般的な英語ページを参照するケースです。自動リダイレクトはクロールとユーザーによる自主的な選択を妨げ、ページのターゲティングとアノテーションの宣言が不一致になりやすくなります。地域の推奨は、通知バー、セレクター、または明確なリンクで実現でき、訪問者と検索エンジンの入口 URL を強制的に上書きすべきではありません。

HTML、HTTP Header、Sitemap で相互に矛盾するバージョン一覧を出力してはなりません

hreflang は HTML<head>、HTTP レスポンスヘッダー、または XML Sitemap を通じて提供できます。通常の Web ページでは HTML アノテーションが確認しやすく、HTML 以外のファイルでは HTTP Header を検討できます。URL 数が非常に多い場合は、Sitemap による一元管理が便利です。どの方法を採用する場合でも、重要なのは「複数箇所に配置する」ことではなく、各箇所で同一の URL マッピングを使用することです。

HTML で/fr/を fr-FR とマークし、Sitemap では同じ URL を fr-CA とマークしても、カバレッジが向上することはなく、かえって説明不能なターゲティングの競合を生み出します。実装上は、言語バージョンの関係を構造化データとして扱い、統一されたマッピングテーブルから生成すべきであり、異なるチームがテンプレート、プラグイン、Sitemap で個別に管理すべきではありません。

調査では、まずページの「アイデンティティ」を確認し、その後にタグを確認する

効果的な確認手順は、コード断片ではなく URL のアイデンティティから始めます。まず各ページに独立した言語または地域のサービス対象があるかを確認し、次に各対象に対してインデックス可能な正規 URL が 1 つだけであることを確認します。続いて、その URL の自己参照 canonical、HTTP ステータス、robots 指示、ページコンテンツを検証し、最後にすべての代替バージョンが同一セット内で相互参照されているかを確認します。

多言語 B2B サイトでは、製品ページ、カテゴリページ、ソリューションページ、問い合わせランディングページで、バージョンのカバー範囲が異なることがよくあります。フランス語コンテンツがないページについて、表面的な完全性のためにフランス語 hreflang を作り出す必要はありません。一部の地域で英語コンテンツのみを共有している場合も、国ごとに英語 URL を複製する必要はありません。hreflang の価値は、実際に存在するバージョンの曖昧さを解消することにあり、すべての市場ディレクトリを一通りマークすることではありません。

言語バージョン間で競合が発生している場合は、重複したターゲティングの削除、canonical と最終 URL の修正、双方向参照の補完を優先し、その後に HTML または Sitemap におけるマッピングの情報源を統一します。ページコンテンツ、アクセスパス、検索シグナルが同一のバージョン定義を指して初めて、hreflang は地域マッチングの役割を果たし、誤ったインデックス登録やトラフィック分散の新たな要因になることを防げます。