モバイルフレンドリーとは — viewport とレスポンシブ対応
モバイルフレンドリーとは、スマートフォンの画面で見やすく操作しやすい状態を指します。要点は 3 つで、viewport メタタグで実寸表示にすること、レスポンシブデザインで画面幅にレイアウトを合わせること、そして Google はスマホ版の内容で評価する(モバイルファーストインデックス)ため、PC 版だけを充実させても不利になることです。
モバイルフレンドリーとは何ですか?
モバイルフレンドリーとは、スマートフォンで文字が読みやすく、リンクやボタンが押しやすく、横スクロールなしで閲覧できる状態を指します。PC 向けのページをそのまま縮小表示するのではなく、画面幅に合わせてレイアウトを組み替え、拡大操作なしで内容が伝わることが条件です。Google もスマホ版を基準に評価するため、今では必須の前提になっています。
スマホからの閲覧が多数を占める今、モバイルフレンドリーは「あると良い」ではなく前提条件です。 判断は難しく見えて、実際は具体的なチェック項目に分解できます。次の 3 つが満たせていれば、ほとんどのサイトは合格します。
- 実寸で表示される —
viewportの指定があり、勝手に縮小されない - 画面幅に合う — レスポンシブデザインで、横スクロールなしに収まる
- 操作しやすい — 文字が拡大不要で読め、リンクやボタンが指で押せる大きさ
いずれも見た目の印象ではなく、HTML と CSS の実装で決まります。だからこそ機械的に確認でき、直し方も明確です。以下で 1 つずつ見ていきます。
viewport メタタグが無いとどうなりますか?
viewport メタタグが無いと、多くのスマホはページを 980px 前後の仮想的な PC 幅で描画し、全体を縮小して表示します。結果、文字は小さく潰れ、利用者は毎回ピンチ拡大を強いられます。head 内に width=device-width を含む 1 行を置くだけで、端末の実際の画面幅で表示され、この問題は解消します。まず確認すべき最初の項目です。
これが最も基本で、かつ抜けていると影響が大きい項目です。スマホのブラウザは、viewport の指定が無いページを「PC 用に作られたページ」と見なし、980px 前後の仮想的な横幅で描画してから、画面に収まるよう全体を縮小します。 結果として文字は豆粒のようになり、利用者は毎回ピンチ操作で拡大しなければ読めません。
| 状態 | スマホでの描画幅 | 利用者の体験 |
|---|---|---|
width=device-width | 端末の実際の画面幅 | 拡大せず読める(正しい) |
| 指定が無い | 980px 前後の PC 幅 | 全体が縮小され、毎回拡大が必要(NG) |
user-scalable=no | 実寸だが拡大禁止 | 弱視の利用者を締め出す(NG) |
<!-- これを head 内に置く。width=device-width で端末の実寸表示になる -->
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- ★ 無いと 980px 前後の PC 幅で描画され、全体が縮小表示される(NG) -->
<!-- ★ 拡大の禁止は入れない。弱視の利用者を締め出す(NG) -->
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">指定する内容は width=device-width, initial-scale=1 の 1 行で十分です。 幅を端末に合わせ、初期倍率を等倍にする、という意味です。ここに拡大を禁じる値を足さないことが、 アクセシビリティを保つ上で大切です。
レスポンシブデザインとは何ですか?
レスポンシブデザインとは、1 つの HTML を CSS のメディアクエリと可変レイアウトで画面幅に応じて組み替える手法です。スマホ用に別 URL を用意する必要がなく、同じ内容を 1 つの URL で配信できるため、Google も推奨しています。固定 px 幅ではなく %・fr・max-width などの可変指定を基本にし、折り返しや段組みを画面幅で切り替えます。
viewport で実寸表示にしたら、次は中身を画面幅に合わせて組み替える番です。 これがレスポンシブデザインで、柱は 2 つあります。
- 可変レイアウト — 幅を固定 px ではなく
%・fr・max-widthで指定し、画面幅に追従させる - メディアクエリ —
@media (min-width: 768px)のように、画面幅で段組みや余白を切り替える
/* 可変レイアウト: 固定 px ではなく画面幅に追従させる */
.container {
width: 100%;
max-width: 960px;
margin-inline: auto;
}
/* メディアクエリ: 画面幅で段組みを切り替える */
.grid { display: grid; grid-template-columns: 1fr; }
@media (min-width: 768px) {
.grid { grid-template-columns: 1fr 1fr; }
}スマホ用に別 URL(いわゆる m ドット)を用意する構成もありますが、内容の同期や正規 URL の管理が二重になり、事故が増えます。 1 つの HTML と CSS で完結するレスポンシブは、URL が 1 本で済むぶん Google にも管理者にも素直です。
モバイルファーストインデックスとは何ですか?
モバイルファーストインデックスとは、Google がスマホ版のページ内容を基準にクロール・評価する仕組みで、現在はほぼ全サイトがこの方式で処理されます。PC 版にだけ本文や構造化データを載せ、スマホ版で省略していると、その省略した内容は評価対象から外れます。本文・見出し・alt・構造化データを PC 版とスマホ版で揃えることが重要です。
ここは誤解が多い点です。「PC 版が本番で、スマホ版はおまけ」という感覚は、もはや逆になっています。 Google はスマホ版のページを主としてクロールし、検索順位もスマホ版の内容で決めます。 したがって、次のような「スマホ版だけ省略」は、そのまま評価の取りこぼしになります。
- 本文の一部をスマホで折りたたみ・非表示にしている — 表示自体はしていれば通常は評価されるが、DOM から丸ごと削ると対象外になる
- 構造化データを PC 版にしか入れていない — スマホ版にも同じ 見出し構造・JSON-LD を置く
- 画像の alt をスマホ版で省いている — PC 版と揃える
タップ領域や文字サイズは何を守ればいいですか?
タップ領域は十分に大きく、本文は拡大不要な文字サイズにし、横スクロールを発生させないことが要点です。指で押す対象は目安として 24×24px 以上、快適には 48px 前後を確保し、隣の要素と間隔を空けます。本文は 16px 前後を基準にし、ページ幅は画面に収めて、左右にはみ出す要素を作らないようにします。
レイアウトが画面幅に合ったら、最後は指での操作に耐えるかどうかです。マウスカーソルと違い、 指は太く、狙いも大まかです。小さすぎるリンクや、隣同士が近すぎるボタンは、誤タップの元になります。
| 項目 | 目安 | 補足 |
|---|---|---|
| タップ領域 | 24×24px 以上(推奨 48px 前後) | 隣の要素との間隔も空ける |
| 本文の文字サイズ | 16px 前後 | 拡大しなくても読めることが基準 |
| 横スクロール | 発生させない | 画面幅を超える要素を作らない |
/* タップ領域を確保する。小さいアイコンボタンでも実寸を広げる */
.icon-button {
min-width: 48px;
min-height: 48px;
}
/* 本文は拡大不要なサイズに。16px 前後を基準にする */
body { font-size: 16px; line-height: 1.7; }横スクロールは、幅を px で決め打ちした画像・表・埋め込みが原因で起きがちです。 画像には max-width: 100% を効かせ、表のように縮められないものは、その要素だけを横スクロールさせてページ本体は画面内に保ちます。
よくある実装ミスは何ですか?
よくある失敗は、viewport の指定で拡大を禁止すること、固定幅の要素で横スクロールを生むこと、スマホ版で内容を削ることの 3 つです。user-scalable=no や maximum-scale=1 は拡大を封じ、弱視の利用者を締め出します。幅の広い画像や表は max-width と横スクロール用の工夫で、ページ全体ではなくその要素の中だけに収めます。
- 拡大の禁止 —
user-scalable=noやmaximum-scale=1を viewport に入れる。弱視の利用者が拡大できなくなる - 固定幅による横スクロール —
width: 1200pxのような決め打ちや、はみ出す画像・表 - スマホ版で内容を削る — モバイルファーストインデックスで、削った分がそのまま評価から外れる
- タップ領域が狭い・密集 — 小さなアイコンやリンクが隣接し、誤タップを誘発する
いずれも「スマホでの見え方を後回しにした」結果として現れます。設計の早い段階からスマホ幅で確認しておくと、 こうした手戻りを避けられます。表示速度の観点は Core Web Vitals も併せて参照してください。
モバイルフレンドリーはどう確認しますか?
確認は Search Console の「ページ エクスペリエンス」やブラウザの Lighthouse で行います。かつて存在した Google 単体のモバイルフレンドリー テストは 2023 年 12 月に終了したため、現在はこれらを使います。加えて、実機やブラウザの開発者ツールの端末エミュレーションで、拡大せず読めるか・横スクロールが出ないかを目視で確かめるのが確実です。
かつては URL を入れるだけの「モバイルフレンドリー テスト」という単体ツールが Google から提供されていましたが、2023 年 12 月に終了しました。現在は次の方法で確認します。
- Search Console — 「ページ エクスペリエンス」で、実サイトのモバイル面の状況を確認する
- Lighthouse — ブラウザの開発者ツールに内蔵。ページ単位で機械的にチェックできる
- 端末エミュレーション / 実機 — 開発者ツールの端末表示や実機で、拡大せず読めるか・横スクロールが出ないかを目視する
機械が判定できるのは viewport の有無や文字サイズといった形式的な部分までです。 「指で押しやすいか」「一目で読めるか」は、最後は実機で自分の指で触って確かめるのが確実です。