hreflangが「効いていない」ように見える本当の理由｜Google公式が語った多言語サイトの実装と8つの誤解

検索を学ぶ

Googleのヘルプフォーラムには17の言語版があり、言語ごとに質問の傾向が違うそうです。インドネシアはサイトマップ関連が多い。そして日本は、大規模ECサイトのcanonicalとインデックス関連の質問が多い——第69回（2024-02-21）で、Search Consoleのサポート担当者がそう語っています。

54回分のエピソードを通して、日本が名指しで出てくる場面はほとんどありません。その数少ない一つが、正規化とインデックスの話だったわけです。

この記事では、公式ポッドキャスト「Search Off the Record」で国際化を扱った回から、hreflangの仕組みと、多言語サイトで踏みやすい落とし穴をまとめました。「設定したのに効いていないように見える」の正体が、かなりの部分で説明できます。

この記事は「Search Off the Record 全54回まとめ」のクラスタ記事です。他のテーマは元記事から辿れます。

lang属性は、Googleに使われていない

第78回（2024-07-25）で明言されています。HTMLの lang 属性は、ランキングやローカライズの判定に一切使用していない、と。

理由は信頼性です。CMSやテンプレートに初期値が埋め込まれたまま放置されることが多く、実態を反映していないケースが多いためです。

具体例として挙げられているのが、Joomlaが lang 属性を常に英語で固定していて、テンプレートをドイツ語に変えても上書きできなかった、という話でした。これは極端な例に見えますが、テーマやプラグインが lang を勝手に出力するCMSは珍しくありません。

対照的に、hreflangは信頼されています。実装コストが高く、手間をかけて設定されるものだから、というのがその理由です。設定に労力がかかる仕組みほど信号として信用できる、という発想は他のシグナルにも通じる考え方だと思います。

ちなみに、同じサイト内に異なる言語のページが混在していても——/de/ 配下に英語のページがあるような状態でも——Googleはページ単位でターゲティングを判断できるため大きな問題にはならない、とされています。

「インデックスされていない」と表示されるのは、仕様

多言語サイトを運用していて、いちばん焦るのがこれだと思います。

hreflangクラスタ内のalternateページが、Search Console上で「インデックスされていない」と表示される。設定を間違えたのかと思って直そうとする。第78回では、これがバグではなく仕様であるとはっきり説明されました。

“We consider it a feature. I know that some people consider it a bug.”（第78回、2024-07-25）

仕組みはこうです。似た言語同士のページ——例に挙がっているのはスイスドイツ語版とドイツ向けドイツ語版——は重複と判定され、hreflangのalternateとして扱われます。そしてSearch Consoleはcanonicalページの情報しか保存せず、alternateページの情報は保持しません。大規模サイトのストレージ効率化のための、意図的な設計判断だと説明されています。

つまり、レポート上で見えるのはクラスタ内のcanonicalの動きだけです。alternateが表示されていないからといって、検索結果に出せない状態というわけではありません。

典型的なのが、スイス向けとドイツ向けのECサイトでVATや通貨、価格だけが異なるほぼ同一のページです。日本語圏に置き換えれば、日本向けと台湾向けで価格と通貨だけが違う商品ページ、といった構成が同じ状況になります。

正規化は、二段階で動いている

第87回（2024-12-05）は、Googleの重複排除チームがゲストの回です。ここで正規化の内部構造が説明されています。

正規化は一枚岩の処理ではなく、2段階です。

  1. クラスタリング — 同じページ群をまとめる
  2. 正規化選択 — クラスタ内でどれを代表とするかを決める

この分け方を知っていると、トラブルの切り分けが変わります。意図しないページ同士がまとまってしまっているのか（クラスタリングの問題）、まとまり方は正しいが代表の選び方が違うのか（正規化選択の問題）で、打ち手が別だからです。

正規化選択に使われるシグナルは約40種類あるとされています。そのうち rel=canonical は、クラスタリングと正規化選択の両方に影響する特殊なシグナルです。

シグナル同士が矛盾したときの挙動も説明されています。301リダイレクトと rel=canonical のような強いシグナル同士が食い違うと、システムはどちらを信じるべきか判断できず、サイトマップやPageRankといった弱いシグナルにフォールバックします。強いシグナルを2つ立てて逆を向かせると、結果的に弱いシグナルで決まるということです。

翻訳の度合いで扱いが変わる

多言語サイトの構成を考えるうえで重要なのがこれです。ローカライズには2種類あるとされています。

  • 定型文のみ翻訳（ボイラープレート） — 同一クラスタにまとめられる
  • 完全翻訳 — 別クラスタとして保持され、それぞれクロールされる

そして価格だけが違う地域版ページが、最も扱いが難しいケースだと明言されています。本文が同じで金額と通貨だけ違うページは、まとめるべきか分けるべきか、システムから見ても判断が難しいわけです。

x-defaultの位置づけ

x-defaultはクラスタリングには関与せず、正規化選択のシグナルとして機能するとされています。

第78回では実装上の補足もあります。x-defaultは必ずしも既存の言語版と同じページを指す必要はなく、完全に別のフォールバックページ——言語未対応の案内ページなど——を指定できます。canonicalとは別に設定することが推奨されています。

さらに、x-defaultを設定するとhreflangクラスタ内のページがcanonicalになりやすくなるという利点があり、これは公式の正規化ドキュメントでも言及されている、とのことでした。

hreflangの実装で決めること

第78回から、実装時の判断材料をまとめます。

実装方法は3つ、仕組み上の差はない

HTMLタグ、HTTPヘッダー、XMLサイトマップのいずれでも実装可能で、仕組みとしては差がありません。

ただしサイトマップはフィード経由で処理されるため反映が遅いという違いがあります。素早く反映させたい場合はHTMLかHTTPヘッダーが有利です。頻繁に構成が変わるサイトなら、この差は効いてきます。

自己参照は必須

hreflangクラスタ内の自己参照は必須です。ただしその理由について、Gary自身も明確には覚えていないと述べています。canonicalとの関連や、実装を複製しやすくする目的があったのではないか、という推測が語られていました。

公式のバリデーターは存在しない

Googleは公式のhreflangバリデーターを提供していません。過去に提供していたレポート機能も、使用率が低く削除済みだそうです。

代わりに、Aleyda Solis氏のツール、Bill Hunt氏（Back Azimuth）のHreflang Checker、Merkleのツールなどが外部ツールとしてヘルプセンターで紹介されている、とのことでした。

複雑になる条件

hreflangが複雑になるのは、サイト規模が大きく、複数のプロパティを持ち、それぞれURL構造が異なる場合だと整理されています。パターンで一括処理できず個別に注釈を書く必要が出てくると、ミスが起きやすくなります。

裏を返せば、URL構造を揃えられるなら揃えたほうが後々楽だ、ということでもあります。

注意: 第78回は2024年の収録で、hreflangやccTLDの信頼性についての言及は継続的な傾向の変化を示すものです。最新の実装ガイドラインは developers.google.com で確認してください。

ccTLDの効果は落ちている

第78回では、ccTLDの位置づけの変化が語られています。

.de のような国コードTLDは、かつては言語降格・国促進（LDCP）というアルゴリズムで多少のブーストを受けていました。ですが .ai のような創造的な使われ方が増え、TLDが国を示す信号としての信頼性は低下してきているとされています。

例として挙がっているのが、Martin氏の個人ブログ 50linesofco.de です。.de ドメインですが内容は英語でドイツ向けではないため、LDCPのブーストを受けなかった、と。

第62回（2023-07-20）にはドメイン選定の話がまとまっています。

  • ccTLDはジオターゲティングに影響する — ただし .asia や .eu のような汎用TLD、.tv のような古いccTLDはGoogleでは汎用扱いで、地理的な効果はありません
  • TLDにキーワードを含めても直接の優位性はない — .coffee のような例。ただしユーザーがリンクしやすくなる可能性はある、とされています
  • .edu や .gov からのリンクが特別な価値を持つのは神話
  • ハイフンの有無はランキングに影響しない — 読みやすさというUXの観点はあります
  • wwwの有無もSEO的には差がない — ただしユーザーが混同しないよう両方でアクセスできるようにし、リダイレクトを設定するのが望ましい
  • 極端に安い・無料のTLDはスパマーが集まりやすく、そのドメイン群全体がクロール・評価されにくくなる可能性がある

URLに含まれる要素の扱いについて、”Anything that’s in the URL can be technically manipulated by the site owner”（第62回、2023-07-20）という説明がありました。サイト運営者が自由に操作できるものは、シグナルとして重く扱えない。lang属性の話と同じ構造です。

なお .jp については、この回で個別に言及されたわけではありません。国コードTLDとしてジオターゲティングの対象に含まれる、という一般論の範囲になります。

IPベースのリダイレクトは避ける

多言語サイトでよくある実装ですが、第72回（2024-04-25）で明確に問題が指摘されています。

理由は2つです。

  1. IPと国の対応データベースは古くなりやすい — 誤ったリダイレクトを引き起こす可能性があります
  2. Googleのクロールは通常1つの地域からのみ行われる — IPで振り分けると、一部のバージョンしかクロールされないリスクがあります

2つ目が特に重要です。クロールが米国から来ることを踏まえると、IPベースで日本語版に飛ばす実装をしている場合、他の言語版がまったくクロールされない事態が起こり得ます。

同じ回で、rel=prev / rel=next についても改めて確認されています。”you can still use it. It’s just ignored.”（第72回、2024-04-25）——使ってもいいが、無視されるだけです。ページネーションの重複問題をこれで伝えられるという理解は、現在は成り立ちません。

多言語サイトで壊れやすい実装

第87回で語られた、クラスタリングが壊れるパターンを挙げます。多言語サイトは元々クラスタが複雑なので、ここを踏むと影響が大きくなります。

エラーページが200を返す

“Only 200s go into black holes.”（第87回、2024-12-05）

エラーページが200を返すと、正常なページと同じチェックサムでクラスタリングされ、「ブラックホール」化します。一度巻き込まれると抜け出しにくい。クロールが再訪しにくくなるためです。一時的なエラーで発生すると特に危険だとされています。

具体例として、在庫切れ商品ページが全て同じ「この商品は利用できません」という文言のHTTP 200ページになり、チェックサムが同一でクラスタ化されるケースが挙がっています。ECサイトなら普通に起こり得る構成です。

回避策は、正しいHTTPステータスコード（404/403/503など）を返すこと。JavaScriptレンダリングの都合で難しい場合は、明示的なエラーメッセージ文言を表示するか、静的な404/500ページへJSリダイレクトする方法が有効とされています。

なお、noindexとHTTPエラーコードは扱いが異なります。noindexは即座にインデックスから削除されますが、エラーコードは猶予期間を経て削除されます。一時的なエラーにnoindexを使うべきではありません。

rel=canonicalが空、または変数のまま

これは怖い話です。rel=canonical に空値が入っていると、ルートパスとして解釈され、サイト全体を消す指示と同義になり得るとされています。

スクリプトの変数評価ミスで $variable のような文字列が残り、サイト全体のcanonicalが hostname/variable を指してしまう事例も紹介されました。そして検証機構は不完全である、とも。

テンプレートでcanonicalを生成している多言語サイトは、言語ごとの出力を実際に確認しておく価値があります。

CDNのbot検出ページ

「You look like a bot」のようなページがGooglebotにも配信されると、複数のサイト間で誤ってクラスタリングされる問題があります。Gary氏が提供事業者に働きかけている、という話も出ていました。

修正しても、すぐには直らない

rel=canonical を後から修正しても、再クロールされなければ古いクラスタリングが解消されない可能性があります。これはクロールチームのスケジューリングの問題である、と説明されています。

直したのに変わらない、という状況は起こり得るということです。

Googleが否定した、国際化・ドメイン関連の8つの通説

通説Googleの説明出典鮮度
HTMLのlang属性で言語を認識してもらえるランキングやローカライズ判定に一切使用していない第78回 2024-07-25要確認
hreflangのalternateが未インデックス表示なのはバグ仕様。Search Consoleはcanonicalの情報のみ保存する第78回 2024-07-25要確認
.eduや.govからのリンクは特別な価値を持つ神話である第62回 2023-07-20要確認
URLやTLDにキーワードを含めると有利直接的なランキング優位性はない第62回 2023-07-20要確認
ドメイン名のハイフンの有無が順位に影響する影響しない第62回 2023-07-20要確認
www付きとnaked domainでSEO的な差がある差はない第62回 2023-07-20要確認
rel=prev/nextでページネーションの重複を伝えられる廃止済みで無視される第72回 2024-04-25要確認
Googleはランキングのために別ページからランダムに抜粋する抜粋は該当ページ内からのみ行われる第72回 2024-04-25要確認

日本のサイト運営者にとって

冒頭に書いたとおり、第69回では日本語フォーラムの質問傾向として大規模ECサイトのcanonicalとインデックス関連が多いと語られています。54回を通して日本が具体的に言及される数少ない場面であり、しかもそれがこの記事のテーマそのものです。

その前提で、優先度が高いと思われるものを挙げます。

在庫切れページのステータスコード

第87回のブラックホール問題です。在庫切れ時に同一文言のページを200で返す実装は、国内のECサイトでもよくある構成だと思います。多言語展開している場合、クラスタが元々複雑なところに同一チェックサムのページが大量に入ることになります。ここは実装を確認する価値が高い項目です。

日本語版と中国語圏版の価格差ページ

第87回で「価格だけが違う地域版ページが最も扱いが難しい」とされている、まさにそのケースです。日本と台湾、日本と香港のように、本文はほぼ同じで通貨と価格だけが違う構成は珍しくありません。完全翻訳に近づけるか、ボイラープレートのみに留めるかで扱いが変わることを踏まえて設計する必要があります。

IPベースのリダイレクト

第72回のとおりです。日本国内からのアクセスを日本語版に飛ばす実装をしている場合、Googlebotが米国から来ることで他言語版がクロールされない可能性があります。

canonicalテンプレートの出力確認

第87回の空値・変数残りの話です。言語ごとにテンプレートを分けているサイトほど、どこか一つの言語で出力が壊れている可能性があります。

lang属性の見直し

第78回のとおり、Googleは見ていません。ただしスクリーンリーダーなどアクセシビリティの観点では意味があるので、「SEOのために」ではなく「ユーザーのために」正しく設定する、という位置づけに切り替えるのが妥当だと思います。

まとめ

国際化まわりで語られてきた内容を並べると、hreflangは効いていないのではなく、効いているところが見えていないだけというケースがかなりの割合を占めそうです。

alternateがSearch Consoleに保存されないのは仕様であり、レポートの数字は実態より少なく見えます。lang属性は最初から使われていません。ccTLDの効果は落ちてきています。このあたりを知らないまま設定をいじると、直っていないものを直そうとして、正しく動いていたものを壊すことになります。

その代わり、本当に壊れるパターンははっきりしています。エラーページが200を返している。canonicalが空か変数のまま出力されている。IPでリダイレクトしていてGooglebotが一部しか見ていない。 どれも実装側で確認できるものです。

日本のフォーラムに寄せられる質問が正規化とインデックスに集中しているという話は、たぶん偶然ではありません。多言語・多地域のECサイトを運用していると、この記事に出てきた条件がひととおり揃うからです。

なお、この記事の項目はいずれも収録から時間が経っており、仕様が変わっている可能性があります。実装を決める前には developers.google.com の最新ドキュメントで裏を取ってください。

関連記事