このテーマにたどり着く方のきっかけは、ほぼ例外なく同じ症状です。日本語セクションがあり、インデックスもされている。それなのに、日本のユーザーが英語ページにばかりたどり着いてしまう。日本語の検索クエリで、英語ページのほうが日本語ページより上に表示されることさえあります。
多くの場合、hreflangがその原因の一つです。原因のすべてとは限りません。誰も検索しない日本語ページは、どう記述しても上位表示されないからです。それでもhreflangは確実に修正できる部分なので、ほかの原因を探る前に直しておく価値があります。
hreflangが実際にしていること
hreflangはページを上位表示させるものではありません。複数のURLが同じコンテンツの別言語版・別地域版であることをGoogleに伝え、そのうちの1つが検索結果に表示される対象になったとき、ユーザーの言語と地域に合ったバージョンに差し替えられるようにするものです。
この定義から2つのことが導かれます。hreflangのミスの多くは、このどちらかを見落としていることから生じます。
1つ目に、hreflangは「差し替え」の仕組みであって、順位を押し上げるものではありません。日本語ページにそれ自体の検索上の可視性がなく、英語ページにもないなら、hreflangを正しく設定しても何も変わりません。
2つ目に、hreflangはサイト単位ではなく URLのクラスタ 単位で機能します。ページごとに独自のクラスタがあります。/services/technical-seo/ と /ja/services/technical-seo/ で1つのクラスタ、2つのトップページで別の1つのクラスタです。各言語のトップページを指すサイト共通のアノテーションを全ページに入れてしまうのは、hreflangを設定しているのに何の効果も得られない、最もよくあるパターンの一つです。
ja か ja-JP か
言語サブタグは ja です。jp ではありません。jp は国コードで、.co.jp や ja-JP に現れるものですが、単独では有効な言語の値ではありません。hreflang="jp" は無効で、そのまま無視されます。日本語セクションで私たちが目にするhreflangのエラーとしては、これが最も多いものです。無効なアノテーションはエラーを出さずに失敗するため、何年も放置されていることがあります。
ja と ja-JP のどちらにするかについて率直に言えば、ほとんどのサイトでは ja が正解です。
jaは「このページは、世界のどこにいるかを問わず日本語話者向けである」という意味です。ja-JPは「このページは 日本にいる 日本語話者向けである」という意味で、日本国外から閲覧している日本語話者は対象外になります。
地域サブタグを使うのは、国ごとに区別された日本語版が実際に複数ある場合だけにしてください。たとえば、日本向けの価格を載せた ja-JP ページと、シンガポール法人向けの ja-SG ページがある場合です。日本語ページが1つしかないなら、ja で、海外に旅行中や在住の日本語話者を含め、見るべき人すべてをカバーできます。理由もなく ja-JP に絞り込むと、単に対象者を減らすだけです。
地域サブタグを使う場合は、ISO 3166-1 alpha-2 の国コードでなければなりません。慣例的な表記は ja-JP です（値は大文字・小文字を区別しませんが、統一しておくと監査が楽になります）。
最もつまずきやすいのは相互参照のルール
クラスタ内のすべてのURLは、そのクラスタ内の すべての URLを、自分自身も含めて列挙しなければなりません。ページAがページBを日本語の代替ページとして指定しているのに、ページBがページAを指し返していなければ、Googleはそのアノテーション全体を無視する可能性があります。
自己参照は必須ですが、実際には非常によく抜け落ちています。日本語ページには、英語ページを指す行だけでなく、自分自身を指す hreflang="ja" の行も必要です。
英語の原文ページと日本語版があるサイトでは、両方のページにまったく同じブロックを記述します。
<link rel="alternate" hreflang="en" href="https://example.com/services/pricing/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/services/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services/pricing/" />相互参照を確実に正しく保つ最善の方法は、手作業で管理しないことです。各ページがどの言語で存在するかを把握しているページレジストリのような、単一の情報源からクラスタを生成すれば、クラスタ内のすべてのページが仕組み上同じリストを出力するようになります。手作業で管理したhreflangは、誰かが最初にページを追加した時点で崩れ始めます。
x-default
x-default は、ユーザーに合うバージョンがほかにない場合に表示するページを示します。任意の設定で、よく誤解されています。
「よりよく合うものがない人」に対する妥当な受け皿となるページを指定してください。通常はグローバルの英語版、あるいは言語選択ページを用意しているならそのページです。x-default を日本語ページに向けてはいけません。意図していないユーザーに日本語ページが表示されてしまいます。
x-default も相互参照の対象です。同じアノテーションを、指定先のページも含め、クラスタ内のすべてのページに記述します。
知っておきたい細かな点が一つあります。x-default が役に立つのは、選択肢となるバージョンが複数ある場合だけです。1つの言語でしか存在しないページでは、アノテーションのブロック全体が意味のない記述になります。
どこに記述するか
Googleにとってはどれも同等に有効な、3つの方法があります。
<head>内の<link>要素：最もシンプルで、ほとんどのサイトではこれを基本とするのが適切です。JavaScriptで<body>に挿入するのではなく、生のHTMLの<head>内に記述する必要があります。- HTTPの
Linkヘッダー：PDFなどHTML以外のファイルでは、これが唯一の選択肢です。 - XMLサイトマップでの指定：大規模サイトでは最も管理しやすいことが多い方法です。クラスタの対応関係全体が、何千ものテンプレートに分散するのではなく、生成された1つのファイルにまとまるためです。
方法は1つに絞ってください。内容の食い違う2つの方法が併存すると、どちらか一方だけの場合より悪い結果になります。プラグインと手書きのテンプレートが両方有効になっていると、意外なほどよくこの状態に陥ります。
canonicalとhreflangは一致していなければならない
ほかは正しく設定できていても、ここでつまずくケースが少なくありません。
すべての言語版は 自己参照のcanonical でなければなりません。日本語ページのcanonicalは日本語ページ自身を指します。日本語ページの <link rel="canonical"> が英語のURLを指していると（重複コンテンツへの懸念の名残として、想像以上によく見られます）、日本語ページはそもそもインデックスされるべきでないとGoogleに伝えたことになり、そのページを指すhreflangのアノテーションは意味を失います。
同じ原則から導かれる関連ルールは次のとおりです。
- hreflangは、正規の、インデックス可能なURLを指さなければなりません。リダイレクト、パラメータ付きのバリエーション、noindexのページを指してはいけません。
- プロトコルを含む絶対URLを使ってください。相対URLのhreflangはサポートされていません。
- 末尾のスラッシュ、
www、httpsの表記ルールを正確に揃えてください。https://example.com/ja/pricingとhttps://example.com/ja/pricing/は別のURLです。ブラウザでは同じ場所に着いても、表記の不一致は相互参照を崩します。
サブディレクトリ、サブドメイン、それとも .co.jp
hreflangは3つのいずれでもまったく同じように機能します。example.com/ja/、ja.example.com、example.co.jp は互いに代替ページとしてアノテーションでき、Googleはクロスドメインのhreflangクラスタも問題なく扱います。
したがって、URL構造の判断はhreflangの判断ではありません。評価、運用、信頼性に関する判断であり、これについては日本で上位表示するために.co.jpドメインは必要か？で別途詳しく取り上げています。hreflangに関係する点は1つだけです。クロスドメインのクラスタは相互参照を保つのが難しくなります。両側は通常、別々のチームが別々のリリースサイクルで管理しているからです。これは順位ではなく運用上のリスクですが、決して軽視できません。
最初に確認すべき失敗パターン
私たちが見つける頻度のおおよその順に並べます。
hreflang="ja"ではなくhreflang="jp"になっている。- 片側または両側に自己参照のアノテーションがない。
- クラスタが相互参照になっていない。多くの場合、日本語セクションが後から、別のチームによって、別のテンプレートで作られたことが原因です。
- サイト共通のアノテーションで、全ページが2つのトップページを指している。
- hreflangの指定先がリダイレクトする、404を返す、または
noindexが付いている。 - 日本語ページのcanonicalが英語ページを指している。
- アノテーションと実際のURLの間で、プロトコル、
www、末尾のスラッシュが一致していない。 - アノテーションがクライアントサイドのJavaScriptで挿入されている。
- IPアドレスに基づく自動リダイレクトにより、Googlebot（主に米国のIPアドレスからクロールします）が日本語ページから完全に遠ざけられている。
最後の項目は、ほかのすべての設定を無意味にしてしまうため、特に強調しておきます。日本のIPからの訪問者を /ja/ に強制リダイレクトし、それ以外の全員をそこから強制的に遠ざけていると、アノテーションはGoogleがクロールできないサイトを記述していることになります。言語の切り替えは、閉じることのできるバナーで提案するにとどめ、強制しないでください。
検証の方法
GoogleはSearch Consoleの「インターナショナル ターゲティング」レポートを廃止したため、頼れるGoogle公式のhreflang検証ツールはもうありません。検証は自分たちで行う必要がありますが、難しくはありません。
- 両方の言語セクションをクロールします。 hreflangを抽出できるクローラーを使い、1ページだけを抜き取り確認するのではなく、全体で相互参照を確認してください。相互参照のエラーは系統的に発生します。1ページにエラーがあれば、おそらく数百ページにあります。
- すべての指定先URLが200を返し、自己参照のcanonicalを持ち、インデックス可能であることを確認します。
- 生のHTMLを確認します。 ブラウザの検証ツールでレンダリング後のDOMを見るのではありません。両者は異なる場合があります。
- URL検査ツールを使い、代表的な日本語ページについて、意図したcanonicalをGoogleが認識しているか確認します。
- Search Consoleの検索パフォーマンスを国（日本）で絞り込み、日本語クエリの表示回数が「どのURL」に計上されているかを確認します。修正から数週間たってもまだ英語のURLであれば、アノテーションが反映されていないか、日本語ページがそのクエリに対して評価に値する検索結果になっていないかのどちらかです。
この最後の区別こそ、押さえておくべき点です。hreflangが決めるのは、自社のどのページを表示するかです。そもそも表示に値するページがあるかどうかを決めるものではありません。日本語ページが英語ページの直訳で、英語の検索需要をもとに作られているなら、アノテーションが正しくても、誰も探していないページが表示されるだけです。この点はWebサイトを翻訳しても日本市場向けSEOにならない理由で詳しく論じています。
まずは技術面を修正してください。原因を確実に特定でき、一度直せばその状態を維持できるからです。そのうえで、より難しい残りの半分に取り組みましょう。
設定をきちんと確認したい場合は、日本向けの国際SEOやテクニカルSEOの支援の中で対応します。URLをお送りください。確認した結果をお伝えします。