hreflang

hreflangが実際にしていること

同じページが複数の言語で存在するとき、検索エンジンは2つの問いに直面します——これらは同じページなのか、そしてこの検索者にはどちらを見せるべきなのか、という問いです。hreflangはその両方に答えます。各バージョンを、同じクエリを巡って競合するほぼ重複のコンテンツとしてではなく、互いの翻訳としてグループ化し、それぞれにどの読者向けに書かれたものかというラベルを付けます。これがなければエンジンは推測するしかなく、目に見える症状としては、サンパウロにいる検索者があなたの英語ページに着地し、そのまま離脱してしまう、といったことが起こります。

hreflangがしないことについても、正確に理解しておく価値があります。hreflangはページを上位表示させることはなく、canonicalタグのようにランキングシグナルを統合することもなく、誰も検索していない翻訳版を救うこともありません。ページはまず自分自身の言語で順位を勝ち取らなければならず、hreflangはすでに競争力のあるページの正しいバージョンが表示されることを保証するだけです。この違いこそが、何も上位表示されていないサイトを翻訳しても何も生まれない理由です——そもそも翻訳すべきかどうかの判断については、SEOのためにウェブサイトを翻訳すべきかで扱っています。

hreflangをどう実装するか

これを宣言できる場所は3つあり、サイトごとにそのうちのどれか1つだけを選び、混在させることはしません。どれを選んでも、コードと相互参照に関するルールは同じように適用されます。

• head内のlinkタグ — バージョンごとに1つのalternate link要素を、すべてのバージョンに配置する。最も一般的な方法で、ルーティングテーブルから生成するのが最も簡単。
• HTTP Linkヘッダー — 同じ情報をレスポンスヘッダーとして送信する方法。タグを置くhead自体が存在しないPDFなど、HTML以外のファイル向けの選択肢。
• XMLサイトマップのエントリ — サイトマップ内の各URLが、その代替バージョンを列挙する。大規模サイトで有用なのは、注記を何千ものページに分散させるのではなく、1つのファイルにまとめておけるため。
• x-defaultの値 — ターゲットにしていない言語の検索者向けのフォールバックで、通常はデフォルト言語のページか言語セレクターを指す。任意だが、何も一致しない場合に誰が何を表示されるかという曖昧さを取り除いてくれる。

値はISO 639-1の言語コードで、必要に応じてその後にISO 3166-1 Alpha 2の地域コードを続けます——en、pt-br、zh-Hansのように。言語コードのみは有効ですが、地域コードのみは無効です。すべてのバージョンは、他のすべてのバージョン*と自分自身*の両方を参照しなければならず、それらの参照は相互的でなければなりません——ページAがBを自分のスペイン語版だと主張しても、Bが一度もAを指し返していなければ、エンジンはその主張を未確認として扱い、無視します。

hreflangがうまくいかなくなるポイント

失敗のほとんどは編集上の問題ではなく機械的な問題です。だからこそhreflangの問題は、優れた翻訳をもってしても生き残り、たいていローンチのずっと後になってから見つかります。

• 一方通行の注記 — 群を抜いて最もよくある間違い。戻りのリンクは両側から確認できなければならず、そうでなければクラスタ全体が破棄されます。
• 存在しない、あるいは食い違ったコード — en-ukは無効です。イギリスの地域コードはgbだからです。不正な値が1つあるだけで、その注記は静かに無効になります。
• URLのトークンを言語タグだと思い込む — サイトが/ptというパスからブラジルポルトガル語を配信しながら、pt-BRと注記するのはまったく正当なことです。パスからタグを導き出してしまうと、間違ったラベルの静かな発生源になります。
• リダイレクトする、404になる、あるいはnoindexが付いたURLを指す — 参照先は実際に存在し、インデックス可能なバージョンでなければならず、そうでなければシグナルは無視されます。
• ブラウザの言語で訪問者を自動的にリダイレクトする — これは注記の意味を完全に無効にします。1つのバージョンに弾き返されたクローラーは、告げられていたはずの他のバージョンに二度とたどり着けなくなるからです。