Googleは、スマートフォン用のクローラーで取得したモバイル版のページの内容を、検索のインデックス登録とランキングに使います。これをモバイルファースト インデックスと呼びます。スマホ表示の点検では、PCとスマホで中身が同じかと、Googleがスマホとして取得できるかの2つを確かめます。
この記事は、2026年10月25日にGoogleのモバイルの公式ガイドと関連する資料を開いて確かめた内容です。
モバイル フレンドリー テストは、もう使えない？
使えません。Googleは2023年4月の記事で、Search Consoleのモバイル ユーザビリティ レポート、モバイル フレンドリー テスト、そのAPIを2023年12月1日から提供終了すると予告しました。旧ツールの紹介記事の冒頭にも、終了したと追記されています。
同じ記事でGoogleは、モバイルの使いやすさが重要でなくなったから終えるわけではないと書いています。評価できる道具として、Chromeの Lighthouse などが増えたことを理由に挙げています。古い解説記事で「テストに合格すればよい」と書かれていても、今はその道具がありません。
Googleは、スマホ版の何を見ている？
公式ガイドには、PCとスマホで次のものをそろえるよう書かれています。
| 項目 |
ガイドが求めていること |
| 本文 |
スマホにもPCと同じ主要な内容を載せる |
| 見出し |
スマホでも明確で意味のある見出しを使う |
| 構造化データ |
PCと同じものをスマホ版にも入れる |
| title・説明文 |
PCとスマホで同じにする |
| 画像 |
小さすぎる画像を避け、同じ代替テキストを付ける |
| robots meta |
PCとスマホで同じ指定にする |
製造業のサイトで起きやすいのは、本文の差です。PCでは製品ページに寸法と材質の表があるのに、スマホでは表を消して「詳しくはカタログをご覧ください」に置き換えている形です。スマホ版で評価されるので、表の中にしか無い型番や寸法は、検索で使われないおそれがあります。
タップしないと読み込まれない本文
ガイドは、メインの内容をスワイプ、クリック、入力などの操作をしたときの遅延読み込みにしないよう求めています。Googleは、読み込みにユーザーの操作が必要な内容を読み込まないという説明です。
HTMLの中に本文があり、アコーディオンを開くと見えるだけの作りとは分けて考えます。問題になるのは「仕様を見る」を押して初めてサーバーから表を取ってくる作りです。タブで畳むこと自体の扱いはクロールバジェットの記事でも触れています。
サイトの作りは、どれになっている？
公式ガイドは、モバイル対応のサイトの作り方を3つ挙げています。
- レスポンシブ デザイン：同じURLで同じHTMLを返し、画面の幅で見え方だけを変える
- 動的な配信：同じURLで、機器に応じて違うHTMLを返す
- 別個のURL：スマホ用に
m. などの別のURLを用意する
Googleは、実装と維持がいちばん簡単な形としてレスポンシブ デザインを勧めています。この形なら、ガイドの細かい注意の多くは当てはまりません。PCとスマホで中身とメタデータが同じになるからです。
制作会社に「うちはどれですか」と聞けば分かります。2か3なら、スマホ版にだけ noindex が付いていないか、PCの各ページに対応するスマホのページがあるかを、ガイドの困ったときの節に沿って確かめます。PCの多くのページをスマホのトップへ転送している作りは、ガイドがエラーとして挙げている例です。
別個のURLなら、canonicalとalternateを見る
m. のような別のURLでスマホ版を出している場合、ガイドは、PC版のURLを正規URLにし、スマホ版をその代替として示すよう求めています。PC版のページには、スマホ版のURLを示す rel="alternate" を書き、スマホ版のページには、PC版を指す rel="canonical" を書きます。
ガイドはほかにも、エラーページのステータスをPCとスマホでそろえること、スマホ版のURLに#の後ろの部分を使わないことを挙げています。PCでは普通に読めるのに、スマホ版だけエラーを返すページは、インデックスに登録されないという説明です。
画像は、同じURLと同じ代替テキストで
画像も、PCとスマホで同じ代替テキストを付けます。PCとスマホで画像のURLが違うと、移行のときに画像検索からの流入が一時的に減ることがある、ともガイドは書いています。ページに直接書いたSVGの中で <image> を使って読み込んだJPGは、登録できないという例も載っています。代替テキストの書き方はalt属性の書き方にまとめています。
手順1：代表ページを選んで、スマホで開く
全ページを見る必要はありません。テンプレートの種類ごとに1枚ずつ選びます。トップ、製品一覧、製品ページ、技術記事、問い合わせフォームのような単位です。同じテンプレートなら、1枚で問題が見つかれば全体に同じ問題があります。
実機で開くのがいちばん確かです。手元に無いときは、Chromeのデベロッパーツールのデバイスモードでスマホの画面幅を試せます。ただしデバイスモードの説明は、これを一次近似と呼び、実機でコードを動かすわけではないと断っています。最後は実機で確かめます。
見るのは次の点です。
- 表や画像が画面からはみ出し、横にずれないか
- PCにある仕様表や注意書きが、スマホで消えていないか
- 「詳しく見る」を押さないと出ない本文が無いか
- 問い合わせボタンや電話番号がタップできるか
手順2：URL検査で、Googleの取得を見る
Search ConsoleのURL検査ツールに代表ページのURLを入れます。インデックス登録の結果には、クロールに使われたユーザー エージェントの種類（パソコンかモバイルか）が表示されます。
次に「公開 URL をテスト」を押します。ヘルプによると、レンダリングされたページのスクリーンショットはこのライブテストでだけ見られます。スクリーンショットとHTMLで、スマホで消えている表や、読み込まれていない本文が無いかを確かめます。ライブテストに通っても、インデックス登録が保証されるわけではありません。
手順3：Lighthouseで、表示の設定を見る
ChromeのLighthouseは、パフォーマンスやユーザー補助、SEOの監査を行う道具です。デベロッパーツールからそのページに対して実行できます。
スマホで基本になるのは、HTMLの head にある viewport の指定です。web.dev のレスポンシブの基本は <meta name="viewport" content="width=device-width, initial-scale=1"> の形を示し、この指定が無いページはLighthouseの監査で見つけられると書いています。読み込みの速さや点数の読み方はPSIの見方と表示速度の指標の記事に任せます。
手順4：PCとスマホのHTMLを比べる
動的な配信か別個のURLの作りなら、PCとスマホで返るHTMLを比べます。制作担当に頼むなら「スマホのユーザー エージェントで取得したHTMLと、PCで取得したHTMLの差を出してほしい」と伝えます。
このサイトの記事ページで試すと、スマホのユーザー エージェントで取得しても、PCで取得しても、同じHTMLが返りました（2026年10月25日に curl で確認）。違ったのは、配信サービスがメールアドレスを隠すための符号の部分だけです。レスポンシブの作りなら、こうした比較で差がほぼ出ないことを確かめておけば、点検の範囲を画面の見え方に絞れます。
スマホ版の noindex に注意
別個のURLの作りで、スマホ版にだけ noindex や nofollow が付いていると、ガイドはクロールとインデックス登録に失敗することがあるとしています。スマホ版を作り直したときは、robots meta がPCと同じかを最初に見ます。
見つかった問題は、どう渡す？
制作担当へは、ページのURL、実機かデバイスモードかの別、画面のスクリーンショット、PCとの差を1行ずつ渡します。「スマホで見にくい」だけでは、何を直すかが決まりません。
使いやすさの点検項目（タップの大きさ、色、フォーム）はユーザビリティで扱っています。検索に出ないこと自体の切り分けは検索に出ない理由から始めます。サイト全体の設計はサイト設計にまとめています。
仕様・出典の確認日：2026年10月25日。
