多言語サイトの hreflang タグでエラーが繰り返し発生する場合の解決方法

多言語サイトで hreflang タグのエラーが繰り返し発生する場合、単に「コードの1行を書き間違えた」だけとは限りません。検索エンジンが適切な言語または地域版を適切なユーザーに表示できるかどうかに直接影響します。英語ページがドイツのユーザーに表示されたり、特定の国向けサイトがメインサイトに置き換えられたり、ページがインデックス登録されていても、ターゲット市場からのオーガニックトラフィックを長期間獲得できなかったりする可能性があります。

この種の問題に対処する際は、まず Search Console のエラーを1件ずつ修正しようと急がないでください。より効果的なのは、最初にサイトの言語構成を確認し、次にタグ間の関係が閉じているかを確認し、最後に URL、リダイレクト、インデックス状態の間にある競合を除外することです。一見独立しているように見える多くのエラーは、実際には同じ構造上の問題に起因しています。

まず判断：ページに本当に hreflang は必要か

hreflang は、コンテンツが高度に対応している一方で、異なる言語または地域のユーザーを対象とするページに適しています。例えば、同じ産業機器に英語、フランス語、スペイン語の商品詳細ページがある場合や、同じ商品ページで米国、英国、オーストラリア向けに異なる通貨、配送説明、コンプライアンス情報を提供する場合です。

中国語ページに自動翻訳プラグインを追加しただけで、ページコンテンツに安定した独立 URL がない、または異なる言語ページが実際にはすべて同一アドレスへリダイレクトされる場合、先に hreflang を追加しても通常は問題を解決できません。検索エンジンは、各バージョンをクロール、アクセス、インデックス登録できて初めて、それらの代替関係を理解できます。

特に B2B の海外貿易サイトでは、すべての言語バージョンをホームページに向ける、または各商品詳細ページでホームページの言語バージョンだけをタグ付けすることがよくある誤りです。hreflang は「ページ対ページ」の対応関係に基づくべきです。製品 A の英語ページは、製品 A のドイツ語、フランス語、または日本語ページに関連付けるべきであり、各言語のホームページに漠然と関連付けるべきではありません。

最もよくあるエラー：相互タグ付けが閉じていない

hreflang は双方向、さらには多方向の関係です。英語ページがドイツ語ページを代替バージョンとして宣言する場合、ドイツ語ページも逆に英語ページを宣言する必要があります。フランス語版やイタリア語版もある場合、参加する各ページは完全で一貫したバージョンの集合を宣言する必要があります。メイン言語ページにだけタグを追加し、他の言語ページからリンクを返さないことは、最も一般的な問題の一つです。

適切なページグループには通常、次の3層の関係が含まれます。

• 各ページが自身の言語バージョン、すなわち self-referencing hreflang を宣言する。
• 各ページが同じコンテンツの他の言語または地域バージョンを指す。
• 同じグループ内のすべてのページに列挙される URL の集合が一致している。

例えば、英語、ドイツ語、フランス語の商品ページが同じグループに属する場合です。英語ページには EN、DE、FR を列挙し、ドイツ語ページにも EN、DE、FR を列挙し、フランス語ページも同様にします。言語コードは異なっていても構いませんが、それらが指すページの集合にそれぞれ欠落があったり、別のページが混在したりしてはいけません。

一部の CMS では、新しい言語を追加した際に現在のページだけを更新し、旧言語ページには新しいリンクが同期して生成されないことがあります。また、ドメイン移行や URL ルールの調整後に、サイトマップの hreflang は更新されている一方で、ページの head タグには古いアドレスが残っているサイトもあります。これらはいずれも「戻りリンクがない」または「代替ページを確認できない」という問題を引き起こします。

言語コードが正しくても、地域コードが正しいとは限らない

hreflang の値には通常、言語コードを使用し、必要に応じて地域コードを追加します。例えばen、de、fr-CA、es-MXです。問題は、言語、国、マーケットを混同することに起こりがちです。

ドイツのユーザー向けのドイツ語ページにはde-DEを使用でき、オーストリア向けのドイツ語ページには de-ATを使用できます。しかし、両ページのコンテンツ、価格、提供方法が完全に同じで、異なる国をカバーするためだけにページを複製する場合、無理に複数の地域バージョンへ分けても必ずしも効果があるとは限りません。むしろ、メンテナンスと重複コンテンツ判定の複雑さを増すことになります。

反対に、英語ページが米国と英国をそれぞれ対象とし、通貨、計量単位、サービス規約、連絡先が異なる場合は、en-US と en-GBを明確に使用すべきです。enのみをタグ付けすることも誤りではありませんが、これは「すべての英語ユーザーに適用される」汎用バージョンを表すもので、地域バージョンを正確に区別することはできません。

コード上では、英国英語を表すためにen-UKを使用するような独自の表記は避けるべきです。言語コードと地域コードは規格に準拠し、サイト全体で統一する必要があります。ユーザーの言語または地域を判定できない場合のフォールバックバージョンには x-defaultを使用できます。通常は言語選択ページまたはグローバルデフォルトページを指します。これは特定の言語バージョンの代わりにはならず、すべてのページを x-default のみへ向けるべきでもありません。

エラーが繰り返される場合は、まず URL がインデックス可能かを確認する

検索エンジンは、「表面上は存在していても実際には利用できない」hreflang URL を受け入れません。タグ内の各アドレスは、リダイレクトページ、404 ページ、robots によりクロールが禁止されたページ、または noindex が設定されたページではなく、アクセス可能な正式ページを返す必要があります。

以下のケースは、多言語サイトで特によく見られます。

• hreflang にまだ http アドレスが記載されているが、サイトはすでに全面的に HTTPS へ切り替わっている。
• URL にセッションパラメータ、トラッキングパラメータ、または絞り込みパラメータが含まれている一方、canonical は別のアドレスを指している。
• ユーザーがある言語の URL にアクセスすると、IP ルールまたはブラウザ言語ルールにより他の言語へ強制的にリダイレクトされる。
• ページがすでに公開終了またはリニューアルされているが、タグが依然として古い商品リンクを指している。
• ある言語ページの canonical が英語ページを指しており、検索エンジンがそのページを独立バージョンではなく重複ページと見なしている。

このうち、強制リダイレクトは最も見落とされやすいものです。「自動ローカライズ」のために、フランスからの訪問者を英語 URL からフランス語 URL へ直接リダイレクトするサイトがあります。一般ユーザーにとっては便利に見えるかもしれませんが、検索エンジンが英語ページをクロールする際にもリダイレクトされ、結果として当該ページとその言語関係を正常に検証できなくなる可能性があります。より安全な方法は、ユーザーが自発的にアクセスできる元の URL を保持し、言語切替の導線または案内を提供することであり、無条件にリダイレクトすることではありません。

canonical と hreflang も整合している必要があります。言語間の相互リンクに参加できる各ページは、通常、自身の正規 URL を canonical とするべきです。フランス語ページの canonical が英語ページを指しながら、hreflang では自らをフランス語の代替バージョンとして定義している場合、二つのシグナルは互いに矛盾し、検索エンジンは多くの場合、その一部を優先的に無視します。

実装方法は一つ選び、複数の情報源が互いに上書きしないようにする

hreflang は HTML ページの head に配置することも、XML Sitemap を通じて送信することもできます。一部の非 HTML ファイルでは HTTP レスポンスヘッダーも使用できます。大半の企業公式サイトや越境ECモールでは、HTML head または Sitemap で十分です。重要なのは方法の多さではなく、データソースを一元化し、更新を同期させることです。

ページの head、Sitemap、バックエンドプラグインが同時に hreflang を出力し、三者の内容が一致しない場合、エラーの特定は非常に困難になります。例えば、ページ内のリンクは新しい URL を指し、サイトマップには古い URL が残り、さらにサードパーティ製 SEO プラグインが一部の言語しか認識しない場合、見た目には「すべてタグがある」ものの、実際には検証できない関係のセットが形成されます。

サイト規模が小さく、ページの言語バージョンが安定している場合は、head 内でタグを生成するほうが直感的です。一方、SKU が多く、言語数も多く、頻繁に一括更新するモールやコンテンツサイトでは、統一されたデータソースから XML Sitemap を生成するほうが適しています。どの方法を採用する場合でも、言語、地域、ページの対応関係をサイトデータの一部として管理すべきであり、運用担当者によるタグの手作業コピーに依存すべきではありません。

サイト全体を盲目的に修正するのではなく、「1つのページグループ」で検証する

修正時は、まずアクセス数の多い商品詳細ページや主要サービスページなど、代表的なページグループを一つ選び、すべてのバージョンを同じチェックリストにまとめることを推奨します。URL、ステータスコード、canonical、index 状態、言語コード、相互参照、x-default の向きを項目ごとに確認します。そのページグループが完全に問題なく通過した後、テンプレートと一括生成ロジックを確認します。

hreflang をランキングツールと考えないでください。これは主に、既存の多言語ページ間で検索エンジンがバージョンを対応付けるのを支援するものであり、翻訳品質の低さ、ページコンテンツの薄さ、サイトがクロールできないこと、またはターゲット市場に検索需要がないといった問題を補うことはできません。長期的に海外顧客獲得を行う企業にとって、多言語 URL ルール、コンテンツ制作プロセス、canonical ルール、hreflang データソースは、サイト構築の段階で統一して設計すべきです。ページ数が増えてからページごとに修正する場合、コストははるかに高くなります。

エラーが継続する場合は、まずエラーが報告されているページが現在もサイトの重要な正式ページであるかを確認してください。すでに公開終了、リダイレクト済み、またはインデックス対象外となっている URL については、レポート上の過去の通知を消すためだけに古い関係を復元する必要はありません。インデックス登録可能で、コンバージョンにつながり、ターゲット市場に向けた主要ページグループにメンテナンスの労力を集中させてこそ、hreflang は本来の役割を発揮します。