モバイルフレンドリーの現行要件は「同じ目的を完了できること」
Googleはモバイル版の内容を主に使ってインデックスとランキングを行います。一方、スマートフォン向けページがなければ検索結果へ一切出ない、という意味ではありません。検索だけを目的に判定ラベルを取るのではなく、利用者が同じ情報と機能へ到達できる状態を作ります。
レスポンシブ設計を第一候補にする
同じURLとHTMLを使い、CSSで画面幅や入力特性へ対応する方式は、内容・meta・構造化データの差分を作りにくく、Googleも実装と保守が容易な方式として推奨しています。既存の別URL方式を根拠なく即時統合せず、canonical、alternate、リダイレクト、計測を含む移行計画を立てます。
主要内容と機能をデスクトップとそろえる
本文、見出し、画像、動画、リンク、構造化データ、title、description、robotsをモバイルだけ減らさないようにします。アコーディオンで初期表示を整理しても、操作しなければHTMLへ存在しない主要内容はGoogleが取得できない場合があります。
GooglebotがCSS・画像・JavaScriptを取得できるようにする
robots.txtや認証で表示に必要な資源を遮断すると、Googleは利用者と同じ画面を再現できません。Search ConsoleのURL検査では、取得したHTML、スクリーンショット、クロール日時、ユーザーエージェント、ブロック資源を確認します。
合否を一つのテストへ委ねない
GoogleのMobile-Friendly TestとSearch Consoleのモバイルユーザビリティレポートは2023年12月1日に提供終了しました。終了はモバイル品質が不要になった意味ではありません。実装検査、ブラウザシミュレーション、実機操作、URL検査、利用データを組み合わせます。
Mobile-Friendly Testの代替
画面崩れはDevToolsと実機、検索エンジンから見える内容はURL検査、速度と安定性はCore Web Vitals、操作失敗はフォーム完了率やエラー記録で確認します。各ツールは対象が異なるため、単一の「合格」へまとめません。
レスポンシブWebデザインを小さい画面から実装する
端末名ごとの固定レイアウトではなく、内容が窮屈になる地点で段階的に組み替えます。320pxや390pxだけに合わせるのではなく、その間、横向き、タブレット、文字拡大でも情報と操作が残るようにします。
- 1
viewportを正しく指定する
headへwidth=device-widthとinitial-scale=1を含むviewportを設定します。maximum-scale=1やuser-scalable=noで利用者の拡大を妨げません。拡大禁止はレイアウト問題を隠しても、読みやすさを改善しません。
- 2
固定幅を可変レイアウトへ置き換える
GridやFlexboxでは子要素のmin-width、長いURL、コード、画像、iframeまで確認します。minmax(0, 1fr)、max-width:100%、overflow-wrapなどを意味に応じて使い、ページ全体へoverflow-x:hiddenを付けて原因を隠しません。
- 3
ブレークポイントを内容から決める
iPhoneやAndroidの機種名ではなく、ナビゲーション、カード、表、フォームが読みにくくなる幅を記録して切り替えます。モバイルを先に一列で作り、余白が増えた時点で列を追加すると保守しやすくなります。
- 4
画像と埋め込みを領域内へ収める
imgへ実寸のwidth・heightを持たせ、表示幅はmax-width:100%とheight:autoを基本にします。必要ならsrcsetとsizesで適切な候補を配信します。動画、地図、広告、SNS埋め込みも親幅を超えないことと、読み込み前の領域確保を確認します。
- 5
表は意味を保って表示方法を選ぶ
2列の用語表はカードや定義リストへ変換できます。多列比較表は表構造を維持し、横スクロール案内、先頭列、caption、thのscopeを付けます。列を非表示にする場合は、判断に必要な情報を失っていないか確認します。
- 6
hoverや画面幅だけに依存しない
メニュー、説明、行操作をhover時だけ出さず、タップ、キーボード、フォーカスでも利用できるようにします。小さい画面が必ずタッチ操作とは限らず、大きい画面にもタッチ端末があるため、pointerやhoverの特性を補助条件として扱います。
<meta name="viewport" content="width=device-width, initial-scale=1">アクセシビリティは文字サイズだけでなく完了操作まで確認する
WCAG 2.2のリフローでは、原則として320 CSS px相当の幅で二方向スクロールを要求せず、情報と機能を失わないことを確認します。例外となる表や地図は、その領域だけを操作可能にし、ページ全体を横へ流しません。
拡大とリフロー
ブラウザの200%拡大と、320 CSS px相当の狭い表示で、本文、メニュー、ダイアログ、固定ヘッダー、エラーメッセージを確認します。文字が切れる、ボタンが重なる、閉じる操作が画面外へ出る場合は未完了です。
ターゲットサイズと間隔
WCAG 2.2 AAのTarget Size (Minimum)は原則24×24 CSS px以上で、間隔などの例外があります。合格ぎりぎりを目標にせず、主要ボタンやアイコン操作は十分な内側余白を設け、隣接操作の誤タップを実機で確認します。
名前・状態・フォーカス
アイコンボタンにはアクセシブルな名前を付け、開閉状態はaria-expandedなどで伝えます。キーボードのフォーカス順、見えるフォーカス、モーダル内の移動、閉じた後の戻り先を確認します。見た目だけの順序変更で読み上げ順を壊しません。
フォームと入力
各入力にlabel、目的に合うtypeとautocomplete、入力例、エラー原因、修正方法を用意します。画面キーボードで送信ボタンやエラーが隠れないか、日付・選択・ファイル添付がSafariとChromium系で完了できるかを確認します。
色・動き・向き
状態を色だけで伝えず、文字やアイコンを併用します。prefers-reduced-motionでは不要な動きを弱め、点滅や自動移動を避けます。業務上不要な縦向き固定をせず、横向きでも情報と操作を維持します。
モバイル対応を6段階で検証する
検証環境だけで偶然通ることを避けるため、代表ページと重要操作を決め、静的検査から実機、検索、公開後監視へ進めます。Chrome Device Modeは有用ですが、公式説明でも実機ではない近似とされています。
- 検証 01
代表ページと重要操作を決める
トップ、記事、一覧、表、検索、問い合わせ、ログイン、購入などテンプレートと重要度が異なる画面を選びます。閲覧だけでなく、メニューを開く、入力する、エラーを直す、送信するまでを操作シナリオにします。
- 検証 02
HTMLとCSSの基本条件を検査する
viewport、見出し、landmark、label、alt、画像寸法、表見出し、重複IDを確認します。documentElement.scrollWidthがclientWidthを超える場合は、最初にはみ出す要素を特定します。
- 検証 03
320・390・768pxと横向きを連続して確認する
ChromeまたはEdgeのDevToolsで幅を固定値だけでなく連続変更し、ナビゲーション、表、長い日本語・英数字、ズーム、ソフトウェアキーボードを確認します。CPU・回線制限は再現条件として記録します。
- 検証 04
Chrome・Edge・Safariと実端末で操作する
Chromium系だけで完了にせずSafariも同じ操作深度で確認します。可能ならiOSとAndroidの実端末で、タップ、スクロール、戻る、入力、回転、共有、固定要素、セーフエリアを確認します。DevToolsの成功だけで実機合格としません。
- 検証 05
Googleが取得した内容を確認する
Search ConsoleのURL検査でインデックス登録状況、クロールしたユーザーエージェント、取得HTML、スクリーンショットを確認します。モバイルとデスクトップで主要内容、meta、robots、canonical、構造化データ、画像altが一致しているか比較します。
- 検証 06
公開後の利用データと回帰を追う
Core Web Vitals、JavaScriptエラー、フォーム失敗、完了率、端末・ブラウザ別の離脱をリリース日とともに追います。数値悪化を端末のせいにせず、再現URLと操作を残し、修正後に同じシナリオを再実行します。
不具合は隠さず、原因別に小さく戻す
ページ全体の横スクロール禁止、要素の非表示、拡大禁止で症状を覆うと、情報や操作を失います。原因を特定し、変更単位を小さく戻してから再設計します。
ページが横へはみ出す
固定幅、min-width、100vwとスクロールバー、長いURL、コード、transform、表、iframeを順に確認します。問題要素の親子サイズを記録し、要素単位で可変幅または局所スクロールへ直します。
メニューやダイアログを閉じられない
閉じるボタンの表示、アクセシブルな名前、フォーカス移動、Escape、背景スクロール、固定ヘッダーとの重なりを確認します。CSSだけを戻せるよう変更を分け、主要導線を隠す更新は公開しません。
フォームを送信できない
必須条件、入力形式、キーボード、エラー位置、送信中状態、二重送信、ネットワーク失敗、戻る操作を確認します。入力値を保持して再試行できるようにし、サーバー側検証を省略しません。
モバイルだけ内容やSEO情報が欠ける
CSS非表示とHTML未配信を分け、robots、lazy-load、canonical、構造化データ、画像alt、内部リンクを比較します。別URLやdynamic servingではキャッシュとVaryも確認し、差分を一覧化してから修正します。
速度改善で操作や表示が壊れる
遅延読込、JavaScript結合、フォント、キャッシュ、第三者タグを一つずつ無効化し、原因を特定します。速さだけでなく、同意、計測、メニュー、フォーム、購入、アクセシビリティの回帰を確認します。
本記事も390pxと実ブラウザで確認する
2026年7月25日に本記事の生成HTMLをChrome系ブラウザとMicrosoft Edgeで確認しました。以下はGoogle Chromeで500px幅を確認した視覚記録です。390pxではSafari WebDriverで表示幅と横スクロールを別途検査しています。シミュレーション画像は実端末そのものではないため、操作検証の代替にはしていません。
表示
ページ本体の横スクロールなし、H1は1件、画像破損なし、目次は本文前に表示。
操作
モバイルメニュー、目次リンク、FAQ開閉、問い合わせリンク、キーボードフォーカスを確認。
検索・意味構造
canonical、日本語のみのhreflang、Article・BreadcrumbList・FAQPage、画像altを確認。
公開前チェックリスト
一つでも重要操作が完了しない場合は公開を止め、原因を修正して同じ条件で再確認します。
レイアウトと内容
- 320～390px、横向き、200%拡大で主要内容を失わない
- ページ全体に意図しない横スクロールがない
- デスクトップと主要本文・meta・構造化データが一致する
- 画像、表、動画、広告、埋め込みが親幅を超えない
操作とアクセシビリティ
- メニュー、ダイアログ、フォームをタップとキーボードで完了できる
- 操作対象の大きさと間隔、名前、状態、フォーカスが分かる
- 入力エラーの原因と修正方法が画面・読み上げの両方で分かる
- 動きの軽減、色以外の状態表示、画面回転を確認した
ブラウザと検索
- Chrome・Edge・Safariで同じ重要操作を確認した
- 実端末またはリモートデバッグでシミュレーション差を確認した
- URL検査で取得HTML、資源、クロール情報を確認した
- 公開日、検証条件、スクリーンショット、既知の制約を記録した
公式出典
仕様やツールは更新されるため、実装時はリンク先の現行説明と更新日も確認してください。
モバイルフレンドリーのよくある質問
Mobile-Friendly Testが終了したので、スマホ対応は不要ですか？
不要になったわけではありません。終了したのはGoogleの特定テストとSearch Consoleレポートです。画面と操作はDevToolsと実機、検索から見える内容はURL検査、速度と安定性はCore Web Vitalsなど、目的別に確認します。
レスポンシブWebデザインなら自動的に合格ですか？
方式だけでは決まりません。固定幅、長い文字列、表、メニュー、フォーム、拡大、キーボード、画像、JavaScriptによって問題は起きます。代表ページと重要操作を実ブラウザで確認してください。
PCのDevToolsだけで実機確認を省略できますか？
省略できません。Chrome公式もDevice Modeを近似と説明しています。モバイルCPU、ブラウザUI、画面キーボード、タッチ、セーフエリアなどの差があるため、重要操作は実端末またはリモートデバッグでも確認します。
横スクロールをCSSで隠せば問題は解決しますか？
解決ではありません。内容や操作が切れたまま見えなくなる場合があります。はみ出す要素を特定し、固定幅、min-width、長い文字列、表、iframeなど原因ごとに直します。
モバイル対応で検索順位は上がりますか？
順位上昇は保証されません。モバイル利用者が内容を読み、操作を完了でき、Googleが主要内容を取得できる状態を目的にします。検索では内容の関連性や品質など他の要素も評価されます。
次に確認するモバイル・SEOガイド
単一の合否ではなく、内容・操作・実機・検索を順に確認する
モバイルフレンドリーの基本は、単一URLのレスポンシブ設計で主要内容と機能を保ち、320～390pxや拡大でも利用目的を完了できることです。まず構造と可変レイアウトを実装し、アクセシビリティ、DevTools、Chrome・Edge・Safari、実端末、URL検査、公開後データの順で確認してください。Mobile-Friendly Testの提供終了を、検証終了と読み替えないことが重要です。
この記事の検証方針
Finite Field 編集部
Web制作、サーバー、業務システムの記事を、読者が自分で再現・判断できる順序へ編集しています。自動ツールの合格だけで完了とせず、Chrome・Edge・Safari、狭い画面、キーボード、意味構造を確認します。
スマホ表示と操作をまとめて直したい方へ
Webサイトのモバイル対応とアクセシビリティ改善をFinite Fieldへ相談できます
対象URL、困っている端末・ブラウザ、再現操作、スクリーンショット、直近の変更があれば共有してください。はみ出し、メニュー、フォーム、速度、検索表示を切り分け、レスポンシブ実装とChrome・Edge・Safariでの回帰確認を相談できます。本記事で自己対応できる項目は先にお試しください。
モバイル対応とアクセシビリティ改善を相談する相談によって特定の検索順位、売上、適合認証、納期、見積額を確約するものではありません。対象範囲と検証条件を確認してご案内します。