全画面のアプリインストール案内はモバイル検索から読める本文を隠さない
公開日： 執筆：佐藤
モバイル検索からページを開いた直後に、本文の大部分を隠すアプリインストール案内を表示しないでください。11月1日以降、そのようなページはモバイルフレンドリーと見なされません。
アプリを案内すること自体が問題なのではありません。検索した人が期待した本文を先に読めるようにし、案内には画面を占有しないバナーを使います。
検索結果から開いた本文を先に見せる
Googleのアプリバナーに関する案内が対象にするのは、モバイル検索結果からページへ移ったときに、本文の大部分を隠すapp install interstitialです。
利用者は検索結果のtitleと説明を見て、ページにある情報を読むためにリンクを押します。その直後に全画面の案内が現れると、本文へ進むには閉じる操作が必要になります。アプリの宣伝を先に見せることと、検索した疑問へ先に答えることは両立しません。
まず、検索結果から直接入る代表ページをスマートフォンで開きます。読みたい見出しと本文が、アプリ案内を閉じなくても見えるかを確認してください。
対象をアプリの全画面案内へ限定して確認する
この変更だけを根拠に、すべてのpopupや案内表示が同じ扱いになるとは判断できません。Googleは、本文の大部分を隠すアプリインストール用interstitialを対象とし、ほかの種類のinterstitialには影響しないと説明しています。
確認する単位もsite全体ではなくページです。モバイル検索の入口になっているページ、アプリ案内を表示する条件、案内が占める範囲を分けて調べます。
| 確認対象 | 見る内容 |
|---|---|
| 入口ページ | モバイル検索から直接開かれるURLか |
| 表示条件 | 初回だけか、毎回か、検索経由だけか |
| 画面占有 | 本文の大部分を隠していないか |
| 閉じる操作 | 本文を読む前に操作を強制していないか |
| 案内先 | 対応するアプリやstoreへ正しく進むか |
全画面であることだけを数えて終わらず、検索した人が本文へ到達できるかを見ます。表示条件を制作会社へ任せている場合は、どのURLで、どの流入元に、何回表示されるかを設定として受け取ってください。
バナーへ変えて本文を隠さない
代わりに、browserが用意するアプリインストールバナーを使えます。SafariのSmart BannersとChromeのNative App Install Bannersは、画面を占有しにくい案内方法としてGoogleが挙げています。
独自のバナーを使うこともできます。ただし、検索した人がページの内容を見られない状態にしてはいけません。上部へ固定する場合は、見出しと本文がどれだけ残るか、小さな画面で閉じる操作ができるかを実機で確かめます。
アプリへの誘導数だけで評価すると、本文を読みに来た利用者の離脱を見落とします。ページを読む目的と、アプリをインストールしてもらう目的を分け、少なくとも次の記録を変更前後で残します。
- モバイル検索からの入口URL
- アプリ案内の表示回数とclick
- 案内を閉じた後に本文へ進んだ割合
- 入口ページから離れた割合
計測できない項目があるなら、無理に推定値を作らず、取得できるdataと取得できないdataを分けてください。
Mobile-Friendly TestとSearch Consoleで範囲を分ける
代表URLを直したら、Mobile-Friendly Testで一件ずつ確認します。site内の問題ページを探す場合は、Search ConsoleのMobile Usability reportを使います。
一件のtest結果とsite全体の修正完了を同じ意味にしないでください。共通templateで直せる問題でも、アプリ案内の表示条件がURLや流入元によって違えば、代表ページだけでは確認できません。
また、モバイルフレンドリー判定は検索順位を決める唯一の条件ではありません。順位の変化だけを見て原因を断定せず、まず本文を隠す表示が残っていないかをページ単位で確認します。
制作を委託する場合は、全画面表示を外すcodeだけでなく、表示条件、対象URL、バナーの寸法、計測方法、変更後の確認記録まで受け取ります。実装を任せても、検索した人へ本文を先に見せる判断と、アプリ案内の成果を評価する責任はsite側に残ります。
最初の一手は、モバイル検索の入口URLを一件選び、スマートフォンで直接開くことです。本文を隠すアプリ案内が出るなら、いったん停止するかバナーへ変え、Mobile-Friendly Testと実機の両方で確認してください。
関連記事
