スマホのSEO対策として語られるのは、たいていレスポンシブ化と表示速度の2つです。ただ、その2つを終えても順位が動かないサイトは珍しくありません。Googleの公式ドキュメントはこの3年で静かに書き換わっており、モバイル専用の検証ツールは2023年末にすべて廃止され、Googlebotが1つのURLから読み取るバイト数の上限も2026年3月に改めて公開されました。ここでは、モバイルファーストインデックス完了後のスマホSEOを、公式の現行記述に沿って「どの順番で確認するか」まで含めて整理します。
まとめ：スマホSEOで最初に確認する5点
- 評価対象はスマホ版。PC版にしか無い本文・構造化データ・titleは、無いものとして扱われます。
- 2024年7月5日以降、モバイル端末でコンテンツにまったくアクセスできないサイトはインデックス対象外になりました。別URLのモバイル版を持つこと自体は要件ではありません。
- Googlebotが1つのURLから取得するのは先頭2MBまで（HTTPヘッダを含む）。PDFのみ64MBです。
- Core Web Vitalsの合格線はLCP 2.5秒以内・INP 200ミリ秒以下・CLS 0.1以下で、判定はモバイルとデスクトップを分けた75パーセンタイル値です。
- 検証はSearch ConsoleのURL検査とLighthouse。モバイルフレンドリーテストとモバイルユーザビリティレポートは2023年12月1日に廃止されています。
以下では、この5点の根拠と、スマホだけ順位が低いときにどこから手を付けるかを順に見ていきます。
モバイル版が評価対象になる範囲と、非対応サイトの現在の扱い
Googleは2016年にモバイルファーストのクロールとインデックス登録を開始し、2023年10月31日の公式ブログ「Mobile-first indexing has landed」で移行完了を宣言しました。仕組みの成り立ちはモバイルファーストインデックス（MFI）とは？その基本的な概要で整理しています。
ただし、この2023年の記事だけを読むと現状を読み違えます。当時はモバイルで動作しないごく少数のサイトをレガシーのデスクトップGooglebotでクロールし続ける猶予がありましたが、その猶予は2024年6月3日の公式ブログで撤回されました。同記事は「After July 5, 2024, we'll crawl and index these sites with only Googlebot Smartphone.」と述べ、続けてこう明言しています。「If your site's content is not accessible at all with a mobile device, it will no longer be indexable.」モバイル端末でコンテンツに一切アクセスできないサイトは、インデックス登録の対象外になります。
混同しやすいのが「モバイル版ページの用意は要件か」という論点です。おすすめの方法のページ（2025年12月10日更新）は「モバイル版のページを用意することは、コンテンツを Google の検索結果に表示させるための要件ではありませんが、非常に強く推奨されています」と書いています。要件でないのはPC版とは別にモバイル専用ページを作ることであって、モバイル端末で開けることではありません。レスポンシブなら1つのHTMLで両方を満たします。
なお、Googlebot Desktopがサーバーログから消えるわけではありません。同ブログは商品情報（product listings）やGoogle しごと検索のクロールで今も使われると記しています。ログにデスクトップのUser-Agentが残っていても、それは検索インデックス用のクロールではありません。
PC版のみに存在する要素の扱い
公式のおすすめの方法が具体的に指定しているのは、次の同一性です。
- コンテンツ：モバイル版の情報量がPC版より少ない場合、MFIが有効になった時点でトラフィックがある程度落ちると公式が説明しています。モバイルで別のデザインにすること自体は認められており、アコーディオンやタブへ移す形なら内容が同等である限り問題ありません。条件は「削らないこと」です。
- robots meta タグ：モバイル側だけに noindex や nofollow があると、クロールとインデックス登録に失敗することがあります。
- 構造化データ：PC版と同じものをモバイル版にも置きます。追加する型に優先順位を付ける必要があるなら、Breadcrumb、Product、VideoObject から着手するよう案内されています。実装は構造化データとは？SEO効果とJSON-LD実装・型の選び方【2026年時点】を参照してください。
- title 要素とメタディスクリプション：PC版とモバイル版で同じ内容にします。
- メインコンテンツの遅延読み込み：スワイプ・クリック・入力といったユーザー操作を必要とする読み込みは、Googleが実行しません。無限スクロールで本文が出てくる設計は、その部分が評価対象から丸ごと外れます。
これらはPC版とモバイル版でHTMLが分かれる構成、つまり動的な配信と別個のURLで問題になります。レスポンシブデザインは同じURLで同じHTMLを配信するため、この種のズレは構造的に発生しません。公式ガイドも、この節の内容は動的な配信と別個のURLの構成にのみ当てはまると断っています。
Googlebotの取得上限（先頭2MB）と押し出される本文
2026年3月31日の公式ブログ「Inside Googlebot」は、クロール基盤のバイト数上限を明示しました。「Googlebot currently fetches up to 2MB for any individual URL (excluding PDFs)」。この2MBにはHTTPヘッダも含まれ、PDFだけが64MBです。上限を指定していない他のクローラーの既定値は15MBなので、クローラー全般の解説記事にある15MBという数字とGooglebotの2MBは矛盾しません。Googlebotのドキュメント自体も2026年2月3日更新版から2MB表記に変わっており、それ以前の記述は15MBでした。手元の社内資料が15MBのままなら、そこは更新対象です。
挙動は次のとおりです。2MBを超えるHTMLでもページが拒否されるわけではなく、取得がちょうど2MBで打ち切られ、そこまでのバイト列が完全なファイルとしてインデックス処理とレンダリングに渡されます。2MBより後ろのバイトは取得もレンダリングもインデックスもされません。HTMLから参照されるCSSやJavaScriptは親ページとは別のカウンタで数えられるため親の2MBを圧迫しませんが、各リソースにも同じ2MBが適用されます。
公式が挙げる危険な構成は、base64で埋め込んだ肥大画像、巨大なインラインCSS／JavaScript、そして数メガバイト分のメニューがページ先頭に来るケースです。本文や構造化データが2MBの外へ押し出されれば、Googlebotにとってそれは存在しないのと同じになります。自サイトのHTMLの実バイト数は、レンダリング前の生HTMLで測ります。
curl -s https://example.com/page/ | wc -c返る値が2,000,000に近いページがあれば、そこが最優先の修正対象です。重いCSSとJavaScriptは外部ファイルへ出し、本文と構造化データをHTMLの前方へ置くのが公式の推奨です。ページ数が多いサイトでは、記事テンプレートより先に一覧ページや商品詳細テンプレートを疑ってください。
スマホだけ順位が低いときの切り分け
「スマホの順位が低い」という状況の多くは、デバイスを問わず順位が低いだけです。デバイス別データを見ないまま速度改善に着手すると、モバイル固有ではない問題に何十時間も使うことになります。順番を決めてから動いてください。
デバイス別データによるモバイル固有性の判定
Search Consoleの検索パフォーマンスは、モバイル・デスクトップ・タブレットのデバイス別に分割できます。主要クエリを絞り込み、モバイルとデスクトップの平均掲載順位を並べてください。差が小さければモバイル固有の問題ではないので、SEO対策の基本｜初心者が押さえる3本柱と進め方【2026年版】で扱う内部対策とコンテンツ側に戻ります。レポートの操作はサーチコンソールとは？できること・設定手順とSEO改善への使い方【2026年時点】にまとめています。
差が出たときに見る3系統と、その順番
デバイス間に明確な差があるときは、次の順で確認します。
- コンテンツ差：URL検査ツールの公開URLテストで、レンダリング後のHTMLに本文が入っているかを見ます。スマホ表示でだけJavaScriptが失敗している、条件付きで本文を出し分けている、という事故がここで見つかります。レンダリング環境はリクエスト間でローカルストレージやセッションを保持しないため、保存済みの状態を前提にした出し分けは再現されません。
- レイアウト：viewport が未指定だとブラウザはPC幅で描画するため、文字が縮小され操作もできません。URL検査のスクリーンショットで実際の描画を確認します。
- 速度：Core Web Vitalsの携帯電話セグメントを見ます。詳細は次章のとおりです。
<meta name="viewport" content="width=device-width, initial-scale=1">この順番には理由があります。ページエクスペリエンスの公式ドキュメントは「Google Search always seeks to show the most relevant content, even if the page experience is sub-par」と書いており、関連性が優先されることを明言しています。本文が取得できていない状態は関連性そのものを損ないますが、速度は同条件の候補が並んだときに効く要素です。順番を逆にすると投資対効果が合いません。
Core Web Vitalsの合格判定と携帯電話セグメントの読み方
現行のCore Web Vitalsは3指標で、良好とされる基準値はLCPが2.5秒以内、INPが200ミリ秒以下、CLSが0.1以下です。判定はモバイルとデスクトップを分けたうえで、各セグメントの75パーセンタイル値で行われます。INPは2024年3月12日にCore Web Vitalsの一つとなってFIDを置き換え、FIDはChromeの計測ツールで2024年9月9日に提供が終了しました。いまだにFIDを指標に据えている社内レポートがあれば、その時点で更新が止まっています。
スマホで落ちやすいのはINPです。端末のCPU性能が低く、タップに対する応答がPCより遅れるためで、同じページでもデスクトップは合格・携帯電話は不合格という分かれ方をします。原因の大半はメインスレッドを占有する長いタスクと、後から読み込まれるサードパーティスクリプトです。CLSの原因はもっと単純で、幅と高さを指定していない画像、遅れて差し込まれる広告枠、Webフォントの入れ替えに集中します。
PageSpeed Insightsのフィールドデータは携帯電話とデスクトップで切り替えられるので、必ず携帯電話側で読んでください。一方、Lighthouseが返すのは端末をエミュレーションしたラボ値で、実機の分布とは一致しません。パフォーマンススコアを100に近づける作業に時間を使うより、携帯電話セグメントで不合格になっている指標を1つ選んで潰すほうが確実です。ページエクスペリエンスの公式記述も「There is no single signal.」として、単一の指標で順位が決まるものではないと述べています。速度改善は必要条件ではあっても、十分条件ではありません。
モバイル検証ツール廃止後の確認手段
スマホSEOの解説記事にいまも「モバイルフレンドリーテストで確認しましょう」と書かれていることがありますが、このツールは存在しません。2023年4月19日の公式ブログが告知しています。「Also starting December 1, 2023, we'll be retiring Search Console's "Mobile Usability" report, the Mobile-Friendly Test tool and Mobile-Friendly Test API」。同じ告知の中で、モバイルユーザビリティが重要でなくなったわけではないとも明言されています。無くなったのは判定ツールであって、満たすべき中身ではありません。
| 廃止・再編されたもの | 時期 | 現在使うもの |
|---|---|---|
| モバイルフレンドリーテスト（廃止） | 2023年12月1日 | Lighthouse |
| モバイルユーザビリティレポート（廃止） | 2023年12月1日 | Lighthouse／URL検査 |
| モバイルフレンドリーテストAPI（廃止） | 2023年12月1日 | 同等の後継APIは無し |
| ページエクスペリエンスレポート（再編） | 2023年内 | Core Web Vitals・HTTPSレポート |
| 設定ページのインデックスクローラ情報（削除） | 2023年10月31日 | クロールの統計情報 |
ツールが判定してくれなくなったぶん、要件は自分で持つ必要があります。viewportの指定、横スクロールが発生しない幅、拡大しなくても読める文字サイズ、指で押し分けられるタップ要素の間隔、そして本文を覆う全画面インタースティシャルを出さないこと。最後の項目はモバイル固有です。ページエクスペリエンスの自己評価項目にも、煩わしい広告や過剰なインタースティシャルが無いかという問いが並んでいます。同意取得バナーやアプリ誘導のモーダルが初回表示で画面を覆うなら、そこは検証対象です。
自動判定をAPIで回していた場合、同等の後継は用意されていません。Lighthouseをビルドパイプラインに組み込む形へ置き換えることになります。
レスポンシブ・動的な配信・別個のURLの選び分け
公式が挙げるモバイル対応の構成は3つです。同じURLで同じHTMLを返すレスポンシブデザイン、同じURLでUser-Agentに応じて異なるHTMLを返す動的な配信、デバイスごとにURLを分ける別個のURL（m.ドメイン）。このうちGoogleは「実装と維持が最も簡単なデザイン パターンとして」レスポンシブウェブデザインを推奨しています。仕組みの比較はレスポンシブデザインとは？仕組み・メリットとスマホ対応方式の選び方を制作目線で解説、実装手順はレスポンシブデザインの作り方｜メディアクエリとブレークポイント設計の実装手順で扱っています。
別個のURLを選んだ場合だけに発生する失敗が、公式ドキュメントに列挙されています。
- PC版は通常のコンテンツを返すのに、対応するモバイル版がエラーページを返す（インデックス登録されません）。
- モバイル版のURLにフラグメント（#以降）がある（ほとんどインデックス登録できず、除外されます）。
- 内容の異なる複数のPC版ページを、モバイルでは同じURL（ホームページなど）へリダイレクトしている（同じく除外されます）。
- hreflangの指定が混在している（モバイル向けURLにはモバイル向けURLを、PC向けURLにはPC向けURLを指定します）。
- Search Consoleに片方しか登録していない（両方を登録します）。
- 画像URLをPC版とモバイル版で分けている（分けると移行時に画像流入の一時的な損失が起きます）。
2026年に新規で別個のURLを選ぶ理由はまずありません。判断が要るのは既存のm.ドメインを抱えている場合ですが、これは順位への影響より保守コストで決めるべき問題です。テンプレートが2系統ある限り、前章の同一性チェックが永久に発生し続けます。統合を検討するなら費用感はスマホサイト制作の費用相場と進め方｜方式の選び方・制作会社の見極め方を解説が参考になります。
よくある質問
スマホとPCで検索順位は違いますか？
同じクエリでも掲載順位は分かれます。インデックスはモバイル版から作られる1本ですが、検索結果に表示される要素の構成がデバイスで異なるためです。差がどの程度あるかはSearch Consoleのデバイス別データで実測できます。まずそこで差の大きさを確認してから対策を決めてください。
AMPは今も必要ですか？
順位のために導入する必要はありません。公式ドキュメントは「Google Search indexes AMP pages just like other web pages, and applies the same standard to all pages, regardless of the technology used to build the page」と述べており、AMPであること自体が評価を変えるものではないと明示しています。速度が目的なら、AMPという形式ではなくCore Web Vitalsの実測値で判断してください。
スマホアプリを出せば検索順位は上がりますか？
アプリ本体はWeb検索のランキング対象ではないため、上がりません。App StoreやGoogle Playの掲載ページはWebページとして検索結果に出ますが、それは自社サイトの順位とは別の話です。アプリ内にしか無い情報がある場合、その内容はWeb側にもクロール可能なページとして用意する必要があります。
順位は上がったのにスマホからの流入が増えないのはなぜですか？
モバイルの検索結果は画面が狭く、AIによる概要や広告枠が上部を占めるとオーガニックの1位でもファーストビューに入りません。順位とクリックが連動しなくなる構造はゼロクリック検索とは？AI時代に検索流入が減る仕組みと選ばれるSEO対策で扱っています。Search Consoleで掲載順位とCTRを分けて追い、順位が改善してもCTRが動かないなら、原因は順位ではなく検索結果上の見え方です。
モバイルファーストインデックスへの対応として具体的に何をすればよいですか？
レスポンシブ構成なら、確認するのは2点です。ユーザー操作を前提にした遅延読み込みでメインコンテンツを出していないか、HTMLが先頭2MBの上限に収まっているか。動的な配信や別個のURLを使っている場合は、これに加えて本文・構造化データ・title・メタディスクリプションがPC版と同じだけ揃っているかを確認します。
