ページの hreflang 言語不一致問題をどのように調査・修正するか？

まず判断：これは標準的な hreflang 言語不一致なのか

　　ページに hreflang の言語不一致が発生している場合、問題は「エラーそのもの」ではなく、検索エンジンがページの言語、地域版、代替関係を誤って判断してしまう点にあります。通常、サイト全体のトラフィックが一気に失われるわけではありませんが、海外サイト内の一部ディレクトリや特定国向けページでインデックス登録が遅れたり、順位がずれたり、英語ページがフランス語圏に表示されたり、スペイン語ページが汎用ページとして処理されたりすることがあります。

　　技術評価を行う際は、タグを急いで修正するのではなく、まず問題の定義を確認してください。hreflang で指定した言語または地域が、ページ上で現在実際に表示されているコンテンツと一致しているかが重要です。たとえば en-us を指定しているのに、本文の大部分がドイツ語になっている場合や、URL はスペイン語ディレクトリなのに、テンプレートのヘッダーが英語版の hreflang を継承している場合です。このようなケースが典型的な問題です。一方、ナビゲーション、ボタン、コメント欄など一部だけが複数言語になっている場合は、必ずしも深刻な不一致とは限りません。ページの主要コンテンツの言語とページの位置付けを確認する必要があります。

　　サイト検査ツールで pages have hreflang language mismatch issues のような表示が出た場合は、通常、まず次の3点を確認します。ページの実際の言語、hreflang の記述方法、そして各言語版が相互に正しく参照し合っているかです。多くのチームは最初にサイト全体のタグを置き換えようとしますが、その結果、もともと正常だったバージョン間の関係まで乱してしまうことがあります。

まずページ自体を確認し、コードだけに注目しない

　　私は通常、まずエラーが発生したページを開き、ファーストビューと本文の中ほどを直接確認します。判断の考え方はシンプルです。検索エンジンが言語を識別する際の中心となるのは、ディレクトリ名ではなく、ページ上で実際に表示されている主要テキストです。

• 本文の半分以上を占めている言語が、そのページで認識される可能性の高い言語です。
• ヘッダーとフッターだけが翻訳され、中央の商品説明が原言語のままだと、hreflang は不一致と判定されやすくなります。
• 機械翻訳が未完了のページもよく見られます。タイトルはフランス語なのに、仕様表は英語のままといったページは、特に問題が発生しやすいです。
• 同じ URL で IP、Cookie、ブラウザ言語などに応じてコンテンツを動的に切り替えている場合も、重点的に確認する必要があります。クローラーが取得したバージョンと、ユーザーが手動で見ているバージョンが、まったく異なるページである可能性があります。

　　ここでの経験則として、ページの主要言語が安定していない場合は、まずコンテンツと出力ロジックを修正し、その後に hreflang を修正します。タグがどれだけ正しくても、実際のコンテンツが混乱しているページを救うことはできないためです。

hreflang の記述を確認する。多くの問題は基本的な形式にある

　　2つ目のステップで、初めてソースコード、サイトマップ、またはレスポンスヘッダー内の hreflang 宣言を確認します。重要なのは「存在するか」ではなく、「正しく記述され、正しいページを指しているか」です。

　　サイト構築システムを使ってタグを一括生成している場合、最も起こりやすいのはテンプレートの継承ミスです。たとえば、商品詳細ページがカテゴリーページの言語グループを呼び出していたり、サイト全体で同じ hreflang グループを出力していたりすると、フランス語ページやドイツ語ページが互いに無関係なページを参照してしまいます。これは単一ページの問題ではなく、通常はテンプレートのマッピングルールに戻って修正する必要があります。

言語版の関係を確認する。「翻訳ページ」を「対応ページ」とみなさない

　　hreflang の前提は、「2つのページが異なる言語で作られていること」ではなく、「業務上、同じコンテンツの異なる言語版または地域版であること」です。この点を、多言語サイトの多くが誤って処理しています。

　　よくあるケースを挙げます。英語ページが商品Aであるのに、スペイン語ページが商品Aのカテゴリーページになっており、チームが「テーマが近いので相互に指定してもよい」と判断するケースです。このようにすると、検索エンジンは代替関係を判断しにくくなります。確認すべき点は次のとおりです。

1. ページの種類が一致しているか。詳細ページと詳細ページ、カテゴリーページとカテゴリーページという対応になっているか。
2. 主要コンテンツが対応しているか。一文ごとの完全な一致までは必要ありませんが、対象となる業務・商品が一致している必要があります。
3. 欠落している言語版がないか。対応するバージョンがない場合は、無理に指定するよりも、指定しない方が適切です。

　　このステップは、海外向けサイト、越境EC、多地域向け公式サイトにとって特に重要です。北米、欧州、日韓、中東などの市場を対象とする場合、多くのサイトには言語差だけでなく地域差も存在します。ページのコンテンツ、通貨、物流に関する案内、連絡先が明確に異なる場合、それは単なる言語版ではなく、地域ごとの独立ページである可能性があります。hreflang の関係はディレクトリ名から推測するのではなく、実際の業務構成に基づいて整理する必要があります。

正規化、リダイレクト、hreflang をまとめて確認する

　　hreflang だけを見ても問題が分からない場合がありますが、canonical やリダイレクトと併せて確認すると、エラーが明確になることがあります。よくある競合には、次のようなものがあります。

• フランス語ページが自らを fr と宣言しているのに、canonical が英語ページを指している。
• hreflang が指定する URL が、別の言語版へ自動的にリダイレクトされる。
• モバイル版、パラメータ付きページ、末尾スラッシュ付きページが言語グループに混在している。

　　対応原則は明確です。各言語版がまず独立してアクセスでき、インデックス登録可能な正式 URL となってから、hreflang の相互参照関係を構築します。URL 自体が安定していなければ、検索エンジンがそのタググループを意図どおりに理解する可能性は低くなります。

Sitemap と HTTP ヘッダー内の重複した宣言も忘れない

　　ページのソースコードを修正したにもかかわらずエラーが残る場合があります。その原因は、XML Sitemap に古い hreflang 関係が残っていたり、一部の HTML 以外のファイルが HTTP ヘッダーを通じて別の指定を出力していたりすることです。検索エンジンが互いに矛盾する複数のシグナルを受け取ると、問題は解消されません。

　　そのため、調査時はフロントエンドの HTML だけを取得するのではなく、少なくとも次の箇所を同時に確認してください。

• ページの head 内にある hreflang。
• 多言語 Sitemap 内の代替リンク。
• サーバーまたは CDN が言語関連のレスポンスヘッダーを追加していないか。

　　サイトが SaaS 型のサイト構築サービスやテンプレートによる一括生成を利用している場合は、この3か所の生成元を統一することを推奨します。フロントエンドのテンプレート、サイトマップ、プラグインがそれぞれ別の指定を追加する状態は避けてください。多言語サイトでは、シグナルが分散することが最も大きなリスクになります。

修正は優先順位に沿って行い、サイト全体を一度に変更しない

　　実際に修正する段階では、順序が重要です。まずは影響の大きいページ、すなわち、すでにインデックス登録されていてトラフィックのあるカテゴリーページ、主要商品ページ、国別サイトのトップページを優先し、その後にロングテールページを処理することをおすすめします。hreflang を一括で誤って変更すると、単一ページのコンテンツエラーよりも影響範囲が大きくなるためです。

　　実行可能な修正手順は、通常次のようになります。

1. ページの主要言語を確認し、翻訳が完了していないコンテンツを整理する。
2. 現在のページの canonical と、最終的にインデックス登録される URL を修正する。
3. 同じグループのページに自己参照と相互参照を追加する。
4. Sitemap 内の代替関係を同時に更新する。
5. サンプルをクロールし、異なる地域からアクセスした際に誤ったバージョンへ切り替わらないことを確認する。

　　多言語サイトの技術評価を行う際は、ドキュメント管理も重要です。社内研修や業務フローの整理では、言語版のルール、ページのマッピング関係、チームの協業方法を標準化された文書にまとめる必要が生じることがあります。このような作業は、知識経済時代における企業人材資源開発・管理モデルの革新戦略のような方法論資料の利用場面とやや近く、重要なのはいずれも「ルールの統一」であり、その場しのぎの対応ではありません。

よくある誤解をいくつか。修正前に避けるべきこと

　　技術的に対応できないのではなく、業務上の判断が先にずれていることが原因のエラーもあります。

• 自動翻訳ページをそのまま正式な言語ページとして公開する。 本文、仕様、パンくずリスト、構造化フィールドが一緒に翻訳されていなければ、言語の不一致はほぼ避けられません。
• 国ごとに1つのディレクトリを設け、コンテンツを完全に流用する。 これは必ずしも誤りではありませんが、すべてのページが英語のコピーに hreflang を追加しただけでは、検索エンジンが定義された地域差を受け入れない可能性があります。
• より多くの市場をカバーするため、地域コードを乱用する。 明確な地域差がない場合は、汎用的な言語版を使用する方が通常は安定します。
• トップページだけを修正する。 実際には、商品詳細ページ、ブログ記事、絞り込みページ、ページネーションページでエラーが発生しやすくなります。これらは異なるテンプレートによって生成されることが多いためです。

技術評価を実行に移す際は、このように整理する

　　現在、すでに複数の hreflang 異常ページを抱えている場合でも、問題を大きく考えすぎる必要はありません。まずページを3種類に分けてください。実際にコンテンツの言語が誤っているページ、タグのマッピングが誤っているページ、URL の関係が誤っているページです。前者2つは通常、テンプレートとコンテンツソースを修正し、後者は canonical、リダイレクト、Sitemap をまとめて見直す必要があります。

　　実務上の優先順位は明確です。まず主要なトラフィックページを確認し、次に同じテンプレートのページを調べ、その後にシステム全体の生成エラーが存在するかを確認します。ページの主要言語が安定し、バージョン間の対応関係が正しく、相互参照が完全であれば、pages have hreflang language mismatch issues のような問題は通常、収束させることができます。すべての市場、すべてのディレクトリを一度に完璧に修正しようとするのではなく、まず検索エンジンが最も誤認しやすいページ群を確実に修正してください。その後の最適化は、そこから始まります。