モバイルフレンドリー更新の影響はモバイル検索とページ単位で切り分ける

4月21日前後に検索流入が変わっても、サイト全体の合計だけを見て、モバイルフレンドリー更新が原因だと決めないでください。まずモバイル検索からの流入と着地URLを分け、変化したページをMobile-Friendly Testで確認します。

この更新が対象にするのはモバイル端末の検索順位で、判定はページ単位です。パソコンからの検索や、確認していない全ページまで一つの原因で説明すると、直す場所を誤ります。

対象はモバイル検索の個別ページ

Googleのモバイルフレンドリー更新に関する発表では、4月21日から世界の全言語で更新を開始し、モバイル端末の検索順位だけを対象にすると説明しています。また、サイト全体ではなく個別ページへ適用されます。

確認する範囲は、次のように絞れます。

モバイルの自然検索だけが減り、未対応と判定されたURLへ変化が集まるなら、この更新を調べる理由が強くなります。すべての流入が同じように減っているなら、計測、公開障害、需要の変化なども切り分けます。

サイト平均ではなく着地URLを並べる

トップページがモバイル対応でも、商品、記事、問い合わせの各URLが同じ状態とは限りません。古いテンプレートだけ画面幅が固定されている場合や、一部のページだけ横スクロールが生じる場合があります。

確認表には、少なくとも次を一行ずつ記録します。

• 着地URL
• モバイル自然検索の変化
• 主な検索意図
• Mobile-Friendly Testの結果
• 使っているテンプレート
• 修正担当者

順位を検索語ごとに追える場合も、先にURLへまとめてください。同じテンプレートの20ページが同じ問題を持つなら、20回別々に直すより、共通のHTMLとCSSを一度直すほうが早く、再発も抑えられます。

合格と不合格のページを同じ条件で比べる

Mobile-Friendly TestとMobile Usability reportの案内に従い、少数のURLはテストツール、サイト内の問題一覧はWebmaster Toolsで確認できます。

問題のあるURLだけを見ると、何が違うのか判断しにくくなります。同じ種類のページから、合格したURLと不合格のURLを一件ずつ選び、次を比べます。

1. viewportの指定
2. 文字を拡大せず読めるか
3. リンクを押し分けられるか
4. 画面幅を超える内容がないか
5. GooglebotがCSS、JavaScript、画像を取得できるか

表示の違いがテンプレートにあるのか、本文へ貼った表や画像にあるのかを分けます。原因が本文なら該当ページを直し、原因が共通部品ならテンプレートを直します。

モバイル対応だけで順位を説明しない

Googleは、検索語の意図を強いシグナルとして使い、内容の質が高ければモバイル未対応のページが上位に出る場合もあると説明しています。モバイル対応は重要ですが、順位を決める唯一の条件ではありません。

したがって、テストに合格したのに順位が戻らない、という理由だけで実装失敗とは決められません。検索意図に答えているか、ページが取得されているか、公開URLが正しいか、競合する自社URLがないかも調べます。

反対に、順位が変わっていないから未対応のままでよい、とも言えません。文字が読めない、操作できない、横へ大きくはみ出すページは、検索順位とは別に利用者の行動を妨げます。

修正後は再検査と再取得を分ける

HTMLとCSSを直したら、実機表示とMobile-Friendly Testを確認します。Googleは、ページがモバイル対応になれば自動的に再処理すると説明しています。Fetch as GoogleのSubmit to Indexで、再取得を促す方法も案内しています。

ただし、再取得を依頼することと、順位が上がることは別です。テスト合格、Googlebotの再取得、検索結果の変化を同じ完了条件にしないでください。

制作会社へ修正を委託する場合は、対象URL一覧、共通テンプレート、合格条件、実機確認、再検査までを納品範囲にします。事業者側は、どのURLが問い合わせや売上に必要かを決めます。すべてのページを一斉改修する前に、重要URLと共通テンプレートから進めてください。

最初の一手は、4月21日前後のモバイル自然検索を着地URL別に並べ、変化の大きいURLを三件選ぶことです。その三件をテストし、個別本文と共通テンプレートのどちらを直すか決めます。