モバイルファーストインデックス：モバイル版コンテンツ、ビューポート設定、タッチ操作への対応
1. モバイルファーストインデックスで何が変わったのか
Google は 2019 年にモバイルファーストインデックスのテストを始め、2024 年 7 月から全サイトで必須になりました。変わったのはランキングアルゴリズムではなく、Google がサイトを見る方法です。
| 以前（デスクトップ優先） | 現在（モバイル優先） | B2B サイトへの影響 |
|---|---|---|
| デスクトップ版ページをクロールしてインデックス | モバイル版ページをクロールしてインデックス | デスクトップ版の表をモバイル版で隠すとインデックスされない |
| モバイル版は体験の最適化にすぎない | モバイル版が唯一のインデックス元 | Schema をデスクトップだけで出力しても書いていないのと同じ |
| m.example.com の独立サブドメインでも許容される | 独立したモバイルサブドメインは維持コストが高い | レスポンシブに統一し、m. サブドメインは廃止するのがおすすめ |
| デスクトップ側の外部リンクの評価が伝わる | 外部リンクもモバイル版で評価される | モバイル版が遅いとランキングにも影響する |
自分が切り替え済みかどうかを確認するには、Search Console のホームに「このサイトはモバイルファーストインデックスで評価されています」と表示されます。まだ表示されていなければ、Google は旧ルールでクロールしていますが、切り替えは時間の問題です。待たないでください。
2. 4つの必須チェック：viewport、コンテンツ、タッチ、Schema
モバイルファーストインデックスの適合チェックは4つに分けられ、それぞれに明確な基準があります。
| チェック項目 | 合格基準 | よくある誤り | 検証ツール |
|---|---|---|---|
| viewport | <meta name=”viewport” content=”width=device-width, initial-scale=1″> | width=1200 を固定指定、または viewport がない | モバイルフレンドリーテスト |
| コンテンツの一致 | デスクトップとモバイルで表示される内容が完全に一致している | モバイル版で display:none により表やスペックを隠している | モバイル版 URL のソースコードを表示して比較 |
| タッチ操作への対応 | タップ領域は 48×48 CSS ピクセル以上、間隔は 8px 以上 | ボタンが 24px、リンクが詰まっている | Chrome DevTools のモバイルシミュレーション |
| 構造化データ | モバイル版ページのソースに完全な JSON-LD が含まれている | Schema をデスクトップ用テンプレートでしか出力していない | Rich Results Test でモバイル版 URL を確認 |
事例:ある工業部品サイトの製品ページでは、デスクトップ版に完全な仕様表(30行)があるのに、モバイル版では「簡素化」のため表全体を display:none にしていた。モバイルファーストインデックス導入後、この製品ページのロングテールキーワード12個がすべて20ページ圏外に落ちた。Google はモバイル版で紹介文しか見ておらず、製品にどんな仕様があるか分からなかったからだ。表をモバイルで横スクロールできるように変えたところ、2週間で8語が10ページ以内に戻った。
コンテンツの一貫性とは、デスクトップとモバイルのレイアウトを同じにすることではない。テキスト、表、画像、Schema がすべて揃っていることだ。レイアウトは折りたたんでよいが、削除してはいけない。
三、レスポンシブ vs 動的配信 vs m. サブドメイン
Google が公式にサポートするモバイル化の方法は3つあるが、推奨度は異なる。
| プラン | 実装 | 維持コスト | 推奨度 |
|---|---|---|---|
| レスポンシブ Web デザイン | 同じ HTML を CSS メディアクエリで適応 | 低 | 第一候補 |
| 動的配信 | 同じ URL で UA に応じて異なる HTML を返す | 中 | 可 |
| 独立した m. サブドメイン | m.example.com に別のテンプレート一式 | 高 | 非推奨、負の遺産 |
| モバイル版なし | デスクトップ版を縮小表示 | なし | 禁止、モバイル非対応 |
直感に反する点:独立した m. サブドメインは「管理しやすい」ように見えて、実際にはテンプレート2套、Schema 2套、hreflang 2套を維持する必要があり、同期が崩れるとコンテンツの不一致が起きる。レスポンシブへの移行そのものが一度のサイト移行であり、301 のマッピングが必要だ。多言語サイトではさらにHreflangの多言語対応がモバイルテンプレートで壊れていないかも合わせて確認する必要がある。
四、画像・フォント・パフォーマンスのモバイル対策
モバイルファーストインデックスは「見られる」だけでは不十分で、Google はモバイル版のデータで評価するCore Web Vitals。
| プロジェクト | デスクトップでよくあるやり方 | モバイルでは必ず変更する |
|---|---|---|
| 画像 | 同じ大きな画像1枚 | srcset + sizes で DPR と幅に合わせる |
| フォント | 3ウェイトすべて読み込む | 2ウェイトのみ読み込み、font-display: swap |
| ナビゲーション | 上部の横並びメニュー | ハンバーガーメニューでモバイルのはみ出しを防ぐ |
| フォーム | 全項目を展開 | type を数値/メールに合わせ、全キーボードが出ないようにする |
| 広告とポップアップ | サイドバー | モバイルではコンテンツを覆うインタースティシャル広告を使わない |
事例2:B2B サイトのブログでモバイルの LCP が長く4.5秒だった原因は、hero 画像にデスクトップ版の幅2400px の原図を使っていたこと。srcset で640px と1080px の2サイズを用意したところ、モバイルの LCP は2.1秒に下がり、デスクトップには影響しなかった。この変更は img タグに属性を2つ足しただけで、デザインは一切変えていない。
モバイルのポップアップは Google が特に取り締まる対象だ。モバイルページでインタースティシャル広告が主要コンテンツを覆うと「モバイル非対応」と判定される。B2B サイトでよくある Newsletter ポップアップは、モバイルでは下部バーに変えるか表示しないようにする。
五、セルフチェックリストと検証フロー
| チェック項目 | ツール | 合格基準 | 頻度 |
|---|---|---|---|
| モバイルフレンドリーテスト | Google のモバイルフレンドリーテスト | すべて合格、文字が小さすぎる/タップ領域が近すぎる警告なし | リニューアル後に一度実行 |
| コンテンツの一致 | Chrome のモバイルエミュレーション + ソース表示 | デスクトップとモバイルで表示テキストが完全に一致 | 四半期ごとに10ページを抽出 |
| Schema のモバイルレンダリング | Rich Results Test でモバイル版 URL を確認 | すべての Schema タイプを検出 | テンプレート変更後 |
| CrUX モバイルデータ | Search Console の体験レポート | 3 種類の CWV モバイル版がすべて合格 | 毎月 |
| モバイルインデックス状態 | Search Console ホーム | 「モバイルファーストインデックス済み」と表示 | 毎月 |
モバイル体験の改善とサイトのアクセシビリティ（WCAG）重なる部分が多くあります。タップ領域のサイズ、コントラスト、キーボード操作。一度対応すれば両方に効きます。
6. モバイルファーストインデックス後のコンテンツの書き方調整
モバイルファーストインデックスは技術的な対応だけではありません。コンテンツの書き方も変える必要があります。PC では長い表や多列のパラメータ、長文の論証を並べられますが、モバイルの訪問者は片手でスマホを持ち、読むリズムがまったく違います。縦画面の 1 列表示に合わせてコンテンツを組み直しましょう。
| コンテンツ要素 | PC でよくある書き方 | モバイル推奨の書き方 |
|---|---|---|
| 長い表 | 8 列以上の横長テーブル | カードか横スクロールに分割し、重要な列を前に出す |
| 段落の長さ | 1 段落 200 字以上 | 1 段落は 3 から 4 行まで、短い文で改行を増やす |
| 内部リンクのアンカーテキスト | 文中のリンク | リンクテキストを独立した行にし、指でタップしやすくする |
| グラフ | 高密度のデータ図 | モバイル用に簡易版の図を別途用意し、結論を文章で添える |
| CTA ボタン | 上部ナビの小さなボタン | 記事の中盤と下部に大きなボタンを 1 つずつ置く |
書くときはまずモバイルの 1 列レイアウトで下書きし、そのあと PC に合わせます。こうすれば PC では見栄えよく、モバイルでは詰め込まれて読みにくい、という状態になりません。四半期ごとに公開済みの記事を 10 本抽出し、Chrome のモバイル表示で確認します。表のはみ出し、小さすぎるボタン、端に張り付いたリンクを見つけたら次の改善に回しましょう。
フォームはモバイルで最もコンバージョンを落としやすい箇所です。PC では十数の項目を一度に置けますが、モバイルの訪問者は片手で入力するため、項目が増えるほど離脱します。問い合わせフォームは必須 3 から 4 項目まで削りましょう。会社名、メールアドレス、要件の概要。残りは成約後に補完します。電話番号や国名など、メールアドレスと会社ドメインから推測できる項目は、訪問者に入力させないようにします。モバイルのフォームコンバージョン率が 5 ポイント上がるごとに、問い合わせ数も一段増えます。
FAQ よくある質問
Google はいつからモバイルファーストインデックスを必須にしましたか？
モバイルで display:none を使ってコンテンツを隠すと SEO に影響しますか？
独立 m.example.com サブドメインは残すべき？
タップ領域は最低どのくらい必要？
Schema をデスクトップ版だけに出力するのはあり？
モバイルのインタースティシャル広告はなぜペナルティを受ける？
最後に
モバイルファーストインデックスは「モバイル版を作れば終わり」ではありません。Google があなたのサイトを読む唯一の方法なのです。デスクトップ版がどれだけ充実していても、モバイル版で見えなければ存在しないのと同じです。
実行は3ステップ。今週は Chrome DevTools のモバイルエミュレーションで主要ページを10件抜き取り確認し、デスクトップとモバイルの内容が一致しているか確かめます。来週は viewport、タップ領域、Schema のモバイルレンダリングという3つの不備を修正します。3週目は Search Console でモバイルフレンドリーテストの合格と CrUX のモバイルデータが基準を満たしていることを確認します。
覚えておきたい一言。モバイルファーストインデックスとは、デスクトップサイトを縮小したものを作れという話ではなく、Google が見ているのは訪問者がスマホで見ているその1枚なのだと認めることです。