Googleのモバイル対応評価が強まる前に表示と操作を同じ条件で確認する
公開日: 執筆:佐藤
スマートフォン対応は、画面を小さく表示できるかだけで決めません。検索から来た人が、desktopと同じ目的の情報を読み、同じ目的の操作をできるかで確認します。電話を受けたいなら電話番号と電話をかける操作、問い合わせを受けたいなら内容とformまでの道筋を、スマートフォンで確かめます。
Googleの公式案内は、2016年5月からモバイル検索におけるモバイル対応の評価を強める予定だと説明しています。すでにモバイル対応ができているpageは影響を受けず、検索語に対する内容の適合性も引き続き強い要素です。
順位のために、desktop pageから説明を減らしてしまうと本末転倒です。利用者が画面の小さな端末で読むからといって、対応地域、利用条件、料金の考え方、連絡先まで短くしてよい理由にはなりません。読ませる順番を整理し、必要な情報へ早く着けるようにすることと、判断に必要な情報を消すことは別です。
確認の起点はトップpageではなく、検索結果から直接開かれるpageです。service名、地域名、悩みの言葉で探した人は、トップを経由せずに個別pageへ来ることがあります。そのpageだけを開いた人が、何を提供しているか、誰に向くか、次にどこへ進めばよいかを理解できるか見ます。headerのmenuを小さく整えただけで、個別pageの導線まで直ったと判断しません。
見た目の縮小と必要な情報の省略を混同しない
desktop用のpageをスマートフォンで見やすくするために、横幅、文字、buttonを調整することは必要です。ただし、その途中で価格、対応地域、問い合わせ方法、商品説明を省くと、訪問者は判断に必要な情報を失います。
たとえば、スマートフォン用のheaderへmenuをまとめる場合を考えます。menuを開けば会社情報や問い合わせへ進めるだけでは不十分です。検索からservice pageへ直接来た人が、headerを探さなくても、価格や条件を読み、次の行動へ進める必要があります。
電話番号を表示している場合は、番号が見えることと電話をかけやすいことも分けます。数字が画像の中にある、本文の途中に一度だけ出ている、受付時間が書かれていないといった状態では、連絡したい人は判断を止めます。電話を受けられない時間に連絡を促すなら、formやmailの案内を添えます。利用者がどの方法で連絡できるかを、pageの目的に合わせて示します。
formも、入力欄が画面へ収まるかだけを見ません。必須項目、送信button、入力に失敗したときの案内、送信後の画面まで操作します。長い入力を求めるなら、最初に何のために必要かを説明します。desktopで入力できても、移動中にスマートフォンで入力する人にとって負担が大きければ、問い合わせを受ける入口として機能しません。
| 確認するもの | smartphoneで見る内容 | 見落とすと起きること |
|---|---|---|
| 本文 | serviceの内容、条件、価格の考え方 | 比較や問い合わせの判断ができない |
| 操作 | 電話、form、資料請求への導線 | 連絡したい人が次の操作へ進めない |
| navigation | 必要なpageへ戻る経路 | 途中で別の情報を確認できない |
| 表示速度 | 画像やscriptを含めた表示 | 読む前に離脱される可能性がある |
検索から来るpageを先に試す
すべてのpageを一度に直そうとすると、確認の優先順位が曖昧になります。まず検索から訪問者を受けるpageを選び、そのpageで必要な情報と操作を試します。
- 検索で見つけてほしいpageを三つ選ぶ。
- 各pageで、訪問者が知りたいことを一つ書く。
- その答えが本文にあり、横へスクロールせず読めるか確認する。
- 次にしてほしい操作を一つ決め、buttonやlinkを押して完了まで試す。
- Mobile-Friendly Testでpageを確認し、問題があれば表示と操作をもう一度試す。
testの結果だけで完了にしないことが大切です。testは技術的な問題を見つける手掛かりになりますが、事業の説明が足りるか、問い合わせまで迷わず進めるかは、実際のpageを読んで確かめます。
確認する端末や画面幅を一つに固定しすぎないことも必要です。特定の機種で見栄えがよくても、少し幅が違う画面で文字が重なったり、横へ動かさなければ表を読めなかったりすることがあります。横幅を狭めたとき、header、見出し、表、画像、formを順に見ます。画像を縮めたことで商品や作業の要点が見えなくなっていないかも確認します。
表示速度の確認では、画像を軽くしたのか、外部scriptを減らしたのか、serverの応答を直したのかを分けます。スマートフォンで遅いという現象だけを見て、すべてを同じ修正で片付けようとしません。最初に読ませたい本文や連絡先より、飾りの画像や使っていないscriptが先に重くなっているなら、読み込みの順序を見直します。速度の数字を上げることだけでなく、利用者が必要な情報へ着くまでを短くします。
外部の制作担当へ修正を頼む場合は、「スマホ対応にしてほしい」だけでは確認範囲が決まりません。検索から来るpage、残すべき説明、電話やformでしてほしい操作、確認する端末幅、直してはいけない部分を渡します。作業後には、どのtemplateとCSSを変えたか、画像やformの扱いを変えたかを受け取ります。見た目を直す仕事と、内容を省いてよい判断を同じ依頼にしません。
内容が合っていればモバイル対応だけで順位は決まらない
Googleは、モバイル対応ではないpageでも、検索語に対して質が高く関連する内容なら表示される場合があると説明しています。だからこそ、スマートフォン対応を順位のためだけの作業にしません。検索語に答える内容を整えたうえで、その答えをスマートフォンでも読めて行動できる状態へ直します。
評価が強まる時期を前にすると、画面の表示だけを急いで直したくなります。しかし、mobile pageとdesktop pageで説明や連絡方法が食い違えば、検索から来た人はどちらを信じればよいか分かりません。二つの画面を持つsiteなら、同じserviceについて、対象、条件、連絡先がそろっているかを比べます。片方だけを更新する運用になっているなら、更新する人と手順を決め直します。
順位の上下には、内容、競合するpage、検索する人の状況など、スマートフォン対応だけでは分けられない要因があります。対応後に順位を一度見て終わりにせず、検索から来るpageで利用者が読んでいるか、連絡できているかを続けて確認します。表示が良くなっても問い合わせの内容が変わらない場合は、画面幅ではなく説明や提案の側に理由があるかもしれません。
最初に直すpageは、検索から人を受け、事業の説明と次の操作が一緒にあるpageです。そのpageをスマートフォンで開き、内容、画像、電話、form、送信後の案内まで実際に通します。順位を待つ前に、利用者が目的を果たせる状態を作ります。
最初の一手は、スマートフォンで自分のservice pageを開くことです。画面を縮めたことではなく、初めて来た人が必要な情報を読んで問い合わせまで進めるかを確認します。
関連記事

