mobile-first indexingに備えるならスマホ版の本文とmarkupを先にそろえる

Googleは、検索結果の関連性を判断するとき、ページのdesktop版を主に見る仕組みから、mobile版を主に見る仕組みへ移す実験を始めています。スマホ版とdesktop版で主な本文やmarkupが違うなら、画面幅を整える前に、検索で読ませたい情報がスマホ版にもあるかをそろえます。

ここで見るのは、文字が縮小表示されるかどうかではありません。利用者がスマホで読む本文と、検索エンジンが理解するmarkupが、desktop版だけに残っていないかです。responsive design、またはdynamic servingで主な本文とmarkupが同じなら、Googleは変更を要しないと案内しています。別URLなどで内容を分けているなら、両方を比較して不足を直す必要があります。

スマホ版を軽くするために本文を短くしているsiteでは、何を省いたかを確認します。価格の条件、対応地域、商品の違い、申し込みの手順、注意事項のように、利用者が選ぶために必要な情報までdesktop版だけに置けば、スマホで読む人は判断できません。段落の順番や画像の大きさを替えることはあっても、主な説明をなくす理由にはなりません。

responsive designで一つのHTMLを使っていても、CSSやJavaScriptによって特定の内容を隠している場合は確認が必要です。画面を狭くしたときにmenuが閉じることと、商品説明そのものが表示されないことは別です。スマホで実際にpageを開き、本文、画像の説明、link、問い合わせへの導線を順に見ます。sourceに文字があるだけでなく、利用者が読める状態かを確認します。

先にmobile版の構成を確かめる

まず、どのURLがスマホ利用者へ返るかを確かめます。同じHTMLを画面幅に応じて表示しているなら、比較する対象は一つです。端末ごとに別のHTMLを返す、またはmobile版の別URLへ案内するなら、同じ内容を二つの場所で保つ責任が生じます。

この違いを決めずに「スマホ対応済み」とだけ記録すると、確認がぼやけます。変更する人が、本文を直すのか、markupを直すのか、robots.txtを直すのかも決められません。重要なページを一つ選び、desktop版とmobile版のURL、表示する本文、管理する担当を一枚に書き出します。

別URLのmobile版を使う場合は、対応するURLの組を先に作ります。desktop版のどのpageが、どのmobile版へ対応するかが分からなければ、比較する内容も決められません。商品page、サービスpage、記事、問い合わせpageなど、siteの種類ごとに一組ずつ選びます。top pageだけを確認しても、個別pageで説明やmarkupが欠けていることがあります。

dynamic servingを使う場合は、同じURLでも利用者やGooglebotへ返すHTMLが異なることがあります。desktopのブラウザーで見た内容だけを正本にせず、スマホ向けに返る内容を確かめます。確認する人がURLを開けても、どの画面へどのHTMLが返ったかを分からなければ、修正後の確認ができません。構成方式、対象URL、確認した端末またはuser-agent、結果を短く残します。

画面の見え方と検索で使う情報を分ける

本文とmarkupは、別々に確かめます。本文を短くしたページへ、desktop版と同じ内容を示すmarkupだけを残しても、ページの内容と印が合いません。Googleはmobile版へ、ページの情報に関係しないmarkupを大量に加えないよう案内しています。markupを増やすことではなく、そのページで実際に伝える情報を正しく示すことが目的です。

markupを比べるときは、単に項目数を数えません。商品についてのpageなら、スマホ版にもその商品を選ぶための説明があるかを読み、対応するmarkupがそのpageの内容を指しているかを確認します。記事なら、記事title、本文、著者の案内など、利用者が読める内容とずれていないかを見ます。desktop版にだけある情報をスマホ版のmarkupへ残せば、印が詳しいからよいのではなく、pageの説明との関係が崩れます。

画像やCSS、JavaScriptなど、pageを読める状態にする資源も確認対象です。本文が返っていても、必要な画像やstyleがGooglebotへ届かなければ、pageの内容を確認しにくくなります。robots.txtを直す場合は、広く許可することだけを目的にせず、必要なpageと資源へ到達できるかをテストします。検索のための設定を替える作業と、公開してよいfileを決める作業を分けます。

一つのページを並べて差を見つける

説明用の仮例として、desktop版には商品を選ぶ条件と仕様の説明があり、mobile版には短い紹介文と問い合わせボタンだけを置いたページを考えます。mobile版を軽く見せる意図があっても、選ぶために必要な説明まで消せば、読む人が受け取る情報が変わります。

次の順で確認します。

1. desktop版とmobile版を並べ、見出しごとに主な説明が両方にあるかを印を付ける。
2. 構造化データテストツールへ両方のURLを入れ、出力されたmarkupを比べる。
3. robots.txtテストツールで、Googlebotがmobile版へアクセスできるかを確認する。
4. mobile版のSearch Console propertyを追加し、確認できる状態にする。

差が見つかったときは、先に本文をどうそろえるかを決めます。その後でmarkupを本文に合わせ、最後にアクセスの可否を確認します。順番を逆にすると、印だけ直してページの説明が不足したままになりやすいためです。

差分を直すときは、すべてのpageを同じ文面にする必要はありません。スマホでは段落を短く分ける、tableを別の見せ方にする、画像を小さくするなど、読みやすくするための出し方は替えられます。重要なのは、利用者が選ぶための結論、条件、根拠、次に進む方法が同じように確認できることです。見せ方の違いと、情報の不足を混同しません。

制作会社へ修正を頼むなら、スマホ対応を広く依頼するだけでは足りません。対象のURL、desktop版にあってmobile版にない情報、markupで直す項目、robots.txtで確認する資源、公開後に確認する人を渡します。themeを直す人と、商品やサービスの条件を確認する人が別なら、本文の正しさは事業側が確認します。表示の調整を任せても、何を伝えるべきかの判断まで任せるとは限りません。

canonical linkはこの確認だけで変えない

mobile-first indexingの実験に備えるためだけにcanonical linkを変更する必要はありません。Googleは、desktopとmobileの利用者へ適切な結果を出す案内としてcanonical linkを引き続き使うとしています。URLの代表を決める作業と、mobile版の本文やmarkupをそろえる作業は、同じ変更として扱わない方が安全です。

実験は小規模に始まっています。順位の変化を予測するより、問い合わせや購入などの判断に必要な本文がmobile版にあり、その本文に合うmarkupとアクセス設定になっているかを確かめます。まずは重要な一ページを選び、desktop版とmobile版を並べるところから始めます。

一pageで確認した方法を、同じ種類のpageへ広げます。記事で本文差分が見つかったなら、ほかの記事も確認します。商品pageでmarkupの不足が見つかったなら、同じtemplateから出る商品pageを確認します。個別入力の問題か、共通templateの問題かで、直す場所と再検査する範囲を分けます。重要なpageから始めれば、見落としを減らしながら作業を広げられます。