• mobile-first indexingへ備える多言語siteはhreflangをmobile URLどうしで結び直す

mobile-first indexingへ備える多言語siteはhreflangをmobile URLどうしで結び直す

公開日: 執筆:佐藤

PC版と別のmobile URLを使う多言語siteは、mobile-first indexingへ備えるとき、hreflangをPC版からmobile URLへ向け直します。日本語PC版から英語PC版へ、英語mobile版から日本語PC版へというように、端末の版が混ざる指定を残しません。言語や地域が同じpageは、mobile版どうし、PC版どうしで結びます。

Googleは12月18日、mobile-first indexingではmobile版の内容をindexとrankingに使うと案内しました。別URLのmobile siteでは、既存のrel="canonical"とrel="alternate"を維持し、hreflangはmobile URLどうし、PC URLどうしで結ぶよう説明しています。これは言語を増やすための設定ではありません。読む人の言語、端末、pageの内容がそろうURLを示すための確認です。 Google Webmaster Central Blog

言語版と端末版は別の対応関係である

多言語siteには、言語や地域ごとの対応関係があります。さらにPC版とmobile版を別URLで運用すると、端末ごとの対応関係も加わります。この二つを一つのlinkで片付けようとすると、どのpageが誰のためのものか分からなくなります。

たとえば、日本語と英語を用意し、PC版をwww.example.jp、mobile版をm.example.jpで運用するsiteを考えます。日本語PC版と英語PC版は、同じ内容を別の言語で伝えるpageです。日本語mobile版と英語mobile版も、同じ関係です。一方、日本語PC版と日本語mobile版は、同じ言語を別の端末へ届けるpageです。言語の対応と端末の対応は、同じURLの組み合わせになりません。

page 言語の対応として結ぶ先 端末の対応として確かめる先
日本語PC版 英語PC版 日本語mobile版
英語PC版 日本語PC版 英語mobile版
日本語mobile版 英語mobile版 日本語PC版
英語mobile版 日本語mobile版 英語PC版

hreflangは、言語や地域に合うpageを示すためのlinkです。rel="canonical"とrel="alternate"は、PC版とmobile版の関係を示すために使います。それぞれの役割を分けると、設定を確認する人も、どのURLを直せばよいか追えます。HTMLへlinkを追加する作業と、各言語の内容を承認する作業も別にします。

mobile版の本文とmetadataを先にそろえる

URLの対応を整えても、mobile版に必要な本文がなければ、読者は判断できません。Googleは、mobile版にも重要な本文、画像、alt属性、動画を通常のcrawl可能な形式で置くよう案内しています。構造化データはPC版とmobile版の両方に置き、mobile page内のURLをmobile版に合わせることも必要です。

ここでいう「同じ」は、文字数や画面の幅をそろえることではありません。商品やserviceを選ぶための条件、料金が変わる場合の案内、問い合わせへ進む先、事業者がどこまで対応するかといった、判断に必要な材料をmobile版にも残すことです。PC版の長い説明をそのまま小さな画面へ押し込む必要はありません。しかし、読みにくいからといって条件そのものを消すと、別のpageになります。

titleとmeta descriptionも、PC版とmobile版で同じ内容を説明します。Googleは、metadataを両方の版に置き、titleとmeta descriptionを同等にするよう案内しています。PC版では会社案内、mobile版ではキャンペーンだけを説明するtitleにすると、どちらがそのURLの正しい説明なのかが曖昧になります。短くする場合も、pageの主題を替えません。

仮に、日本語版と英語版で対応地域が違う場合を考えます。日本語版が国内配送だけを受け、英語版が海外配送にも対応するなら、同じ内容の翻訳とは言えません。この場合、hreflangの指定だけで違いを隠さず、各pageの配送条件、価格表示、問い合わせ先をそれぞれ確認します。言語を替えたpageと、対象地域を替えたpageは、同じように見えても読者が決めることが違います。

URLの組み合わせを表へ残す

別URLのmobile siteは、page数が増えるほど対応関係を見失いやすくなります。PC版のURL、mobile版のURL、言語、地域、canonical、alternate、hreflangを一枚の表へ残します。設定を作る人だけの手元に置かず、siteを管理する側もどのURLが正本かを見られる状態にします。

表には、すべてのURLを最初から書き出す必要はありません。まずtop page、会社案内、主なservice page、問い合わせpage、商品や記事の代表pageを選びます。それぞれで、日本語PC版、日本語mobile版、英語PC版、英語mobile版の対応を確かめます。templateが共通なら、代表pageで見つけた誤りをtemplateへ直し、変更後に別のpageでも確認します。

記録すること 先に決めること 確認する人
URLの一覧 PC版とmobile版の対応 制作担当者
言語と地域 同じ内容として結べる範囲 内容の承認者
canonicalとalternate 端末別URLの関係 制作担当者とsite管理者
hreflang 同じ端末内の言語別URL 制作担当者と内容の承認者
本文とmetadata mobile版に残す判断材料 内容の承認者

制作会社へ修正を頼む場合も、tagを追加する仕事だけを渡して終わりにしません。どの言語と地域へ何を案内するsiteか、どのURLが対応するpageかをsite側で決めます。作業を頼むことと、海外向けの条件や問合せ先の責任を渡すことは違います。

responsive web designなら内容の差を先に見る

PC版とmobile版が同じURLのresponsive web designなら、別URLのhreflang対応はありません。Googleは、responsive web designと正しく実装したdynamic servingで、PC版の内容とmarkupを含めていれば、一般に追加の対応は不要だと案内しています。この場合も、mobile画面で本文、画像、link、構造化データが消えていないかは確認します。

表示幅に応じてmenuを折りたたむことと、本文を出さないことは別です。操作を簡単にするために、補足を開閉できるようにすることはあります。ただし、料金条件、申込みの方法、重要な注意のように、読者の判断を変える内容をPC版だけへ置くと、mobile版で探す人は同じ情報へ到達できません。端末ごとに説明を替えるなら、何を替え、何を残すのかを先に決めます。

最初の一手は、各言語の代表pageを一件ずつ選び、PC版とmobile版のURLを四つ並べることです。そこから、hreflangが同じ端末の別言語へ向くか、canonicalとalternateが端末の対応を示すか、mobile版に本文とmetadataが残るかを確認します。mobile-first indexingへの備えは、link tagを増やすことではなく、どの人がどの端末で読んでも必要な情報へ進めるURLを保つことです。

戻る