Domain 10 / 225

モバイルファーストインデックスはモバイル版を主に使う Google の方針

モバイルファーストの要点

モバイルファーストインデックスは Google がスマートフォン版を主にインデックス・ランキングに使う方針で現在ほぼ全サイト適用済み。モバイルとデスクトップで本文 / メタ / 構造化データが揃っている必要があり、レスポンシブが推奨

なぜこれを学ぶか

モバイルファーストインデックスは 2024 年以降ほぼすべてのサイトで強制適用された Google の標準方針。モバイル版とデスクトップ版で内容が揃っていないと、Google が「モバイルでは見えない情報」を評価対象から外し、デスクトップで上位だったページが大幅に順位を落とす事故が起きる。

EC・メディア・コーポレートサイトのリニューアルや、レスポンシブ化が中途半端なサイトでは、リスクが特に大きい。

学ばないと起きること

よくある事故	被害
モバイル版を簡易テキストにし、デスクトップに詳細を残す設計	モバイル版だけがインデックス対象になり、デスクトップにしかない情報は SEO 評価から除外
モバイル版だけ noindex / nofollow をテストで入れたまま	モバイルファーストインデックス適用後、Google がそのページを完全に外す
モバイル版に構造化データを書き忘れる	リッチリザルトの権利を失う、Search Console で「構造化データ欠落」エラー多発
モバイル / デスクトップで別の画像 URL を使う	画像検索の順位が一時的に消える、再インデックスに数ヶ月
別 URL 構成（m-dot）で canonical を双方に張り間違える	重複扱いまたはインデックス漏れ、URL の権威性が分散
モバイル版の URL に `#fragment` を含める	フラグメントは原則インデックス不可で、ページが消える
デスクトップ → モバイルへのリダイレクトでホームに集約	個別ページがすべてホームに統合され、深いページが消える

学ぶメリット

レスポンシブ / 動的配信 / 別 URL の 3 構成のうち、自社にどれが適切か判断できる
リニューアル時にモバイル版の本文 / メタ / 構造化データの整合性をチェックリスト化できる
Search Console「モバイルユーザビリティ」エラーを早期に切り分けられる
商談で「モバイルで隠した内容は SEO 評価対象外」と即答できれば信頼を得やすい

仕組み

モバイルファーストインデックスとは

Google がインデックス・ランキングの判断材料として、モバイル版（Smartphone agent でクロール）の HTML を主に使う方針。 2019 年から段階的に適用が始まり、2024 年時点でほぼすべての新規・既存サイトに適用済み。

ユーザーが PC で検索した場合も、Google はモバイル版の HTML を元に判断したインデックスから結果を返す。

モバイル対応の 3 構成

構成	仕組み	Google 推奨度
レスポンシブデザイン	同じ HTML / 同じ URL を CSS で出し分け	最も推奨
動的配信（Dynamic Serving）	同じ URL で User-Agent によって違う HTML を返す	可だが Vary ヘッダ必須
別 URL（m-dot）	デスクトップとモバイルで別 URL（例: `m.example.com`）	最も複雑、運用コスト高

レスポンシブが最も簡単で、モバイル / デスクトップで内容のズレが起きないので圧倒的に推奨。ガイドの内容（コンテンツ整合性 / canonical / hreflang）は主に動的配信と別 URL 向けで、レスポンシブなら自動的に満たせる。

モバイル版が満たすべき要件

公式に明記されている主要要件:

モバイル版のコンテンツがデスクトップ版と同等であること
同じ robots meta（noindex / nofollow）を使うこと
主要画像が同じ高品質・同じ alt テキストであること
title / meta description が同等であること
構造化データが同じものを含むこと
ユーザーアクションを必要とする lazy-load を主要コンテンツに使わないこと

「モバイル版だけ簡略化」は禁忌。

別 URL（m-dot）構成での canonical / alternate

デスクトップ側（example.com）	モバイル側（m.example.com）
自身を canonical	デスクトップ URL を canonical
モバイル URL を `rel="alternate"` で参照	（特に alternate 不要）

<!-- デスクトップ側 -->
<link rel="canonical" href="https://example.com/">
<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/">

<!-- モバイル側 -->
<link rel="canonical" href="https://example.com/">

別 URL 構成では canonical は常にデスクトップ URL を指す。これを誤ると重複扱いか canonical 不一致のエラーが起きる。

キー概念

コンテンツ整合性のチェックポイント

チェック項目	NG パターン
本文の量	モバイル版だけ要約、デスクトップに詳細
見出し構造	モバイル版の h1 / h2 が違う
主要画像	モバイル版が低解像度 / 小さい / alt 不足
構造化データ	モバイル版に Breadcrumb / Product / Video が欠落
robots meta	モバイル版だけ noindex
title / meta description	モバイル版だけ短縮版
内部リンク	モバイル版にナビゲーションがない

lazy-load の落とし穴

スクロールに連動した lazy-load は OK。ユーザーのクリック / タップ / スワイプを必要とする lazy-load は NG（Google がコンテンツに到達できない）

<!-- OK: スクロールで自動読み込み -->
<img src="article.jpg" loading="lazy" alt="...">

<!-- NG: クリックを要求するアコーディオン内主要コンテンツ -->
<button onclick="loadContent()">続きを読む</button>

主要コンテンツはアコーディオンで隠してもインデックスされるが、ユーザーアクション（クリックや swipe）で初めて取得される構造は対象外。

別 URL 構成の hreflang

別 URL 構成で多言語サイトを運営する場合、hreflang はモバイルとデスクトップで分けて記述する。

<!-- デスクトップ -->
<link rel="alternate" hreflang="es" href="https://example.com/es/">

<!-- モバイル -->
<link rel="alternate" hreflang="es" href="https://m.example.com/es/">

混ぜると Google が言語クラスタを正しく認識できない。

Search Console の Smartphone agent 確認

URL 検査ツールで「Googlebot Smartphone」の取得結果を確認すれば、Google がモバイル版で何を見ているかが分かる。レンダリング HTML を確認して、デスクトップ版と内容差分がないかをチェックする。

よくある誤解

よくある誤解	実際のところ	出典
モバイルファーストインデックスはまだ部分適用	2024 年時点でほぼすべてのサイトに適用済み	モバイルファーストインデックス
モバイル版はテキスト要約で良い	本文 / 構造化データ / メタタグはデスクトップと同等であることが要求	同上
アコーディオン / タブで隠したコンテンツは評価されない	評価される。隠れていても HTML 内にあれば Google は読む	同上
クリックで読み込む lazy-load も Google が拾う	拾わない。スクロール連動 lazy-load のみ OK	lazy-loading
モバイル版だけ noindex を入れても影響は限定的	モバイルファーストインデックスでそのページが完全に消える	モバイルファーストインデックス
別 URL 構成では canonical はモバイル URL でも良い	NG。canonical は常にデスクトップ URL を指す	同上
モバイル版の URL フラグメント（`#section`）も普通にインデックスされる	フラグメント URL は原則インデックス不可、消える	同上
レスポンシブ / 動的配信 / 別 URL は SEO 評価が同じ	レスポンシブが最も推奨。別 URL は最も複雑	同上

実務での適用

レスポンシブデザインで満たすチェックリスト

レスポンシブなら基本要件は自動的に満たせるが、以下は確認:

CSS で隠したコンテンツがモバイルで本当に読み込まれているか
画像が srcset / sizes でデバイス最適化されているか
タップターゲットが 48px 以上で、近接していないか
ビューポート設定（<meta name="viewport">）が入っているか
インタースティシャル（突然のポップアップ）でモバイル UX を阻害していないか

別 URL 構成（m-dot）で必ずチェック

デスクトップ → モバイル URL のリダイレクトが個別ページ単位で機能しているか（ホームに集約していないか）
モバイル URL に #fragment がないか
canonical / alternate / hreflang の対称性
モバイル版にも全構造化データが入っているか
モバイル版が同等の robots.txt / robots meta になっているか

リニューアル時のリスク回避

新サイトを公開する前に、モバイル版で以下を確認:

確認項目	やり方
URL 検査ツールで Googlebot Smartphone の取得結果を確認	Search Console → URL 検査
Lighthouse のモバイルスコア	DevTools → Lighthouse
Mobile-Friendly Test	search.google.com/test/mobile-friendly
構造化データがモバイルで読まれるか	リッチリザルトテスト → モバイル設定

トラブル別の対処

症状	確認すべきこと
デスクトップで上位だったページがモバイルファーストインデックス後に順位低下	モバイル版のコンテンツ・構造化データの欠落、CSS で隠した本文がレンダリング後にも消えていないか
Search Console「リッチリザルト」エラー急増	モバイル版の構造化データが欠落していないか、URL が正しいか
画像検索順位が一時的に低下	モバイル / デスクトップで違う画像 URL を使っていないか、新 URL のインデックス時間
「モバイルユーザビリティ」エラー	viewport タグ / フォントサイズ / タップターゲット間隔の問題、Lighthouse で診断
モバイル URL がインデックスから消えた	canonical の向き間違い / モバイル版だけ noindex / フラグメント URL を確認

公式ソース

自己テスト

Q1. モバイルファーストインデックスとは何か？

Google がインデックスとランキングの判断材料として、モバイル版（Smartphone agent でクロール）の HTML を主に使う方針。 PC で検索した場合も、モバイル版を元に作られたインデックスから結果を返す

Q2. レスポンシブ / 動的配信 / 別 URL のうち Google が最も推奨する構成は？

レスポンシブデザイン。同じ HTML / 同じ URL を CSS で出し分けるので、モバイル / デスクトップの内容ズレが起きない

Q3. モバイル版だけ簡易テキストにして、詳細はデスクトップに残しても問題ないか？

NG。モバイル版だけがインデックス対象になり、デスクトップにしかない情報は SEO 評価から除外される

Q4. アコーディオン / タブで隠したコンテンツはインデックスされるか？

される。HTML 内にあれば Google は読む。ただしユーザーのクリック / タップを必要とする lazy-load は対象外

Q5. 別 URL 構成（m-dot）で canonical はどちらの URL を指すべきか？

常にデスクトップ URL。モバイル版 → デスクトップ URL を canonical にし、デスクトップ → モバイル URL を rel=alternate で参照する

Q6. モバイル URL に `#fragment` が含まれているとどうなる？

フラグメント URL は原則インデックス不可。モバイルファーストインデックス適用後、そのページが消える

Q7. モバイル版に構造化データを書き忘れるとどうなる？

リッチリザルトに出る権利を失う。Search Console でも「構造化データ欠落」のエラーが急増する

Q8. クリックを要求する lazy-load は Google が拾うか？

拾わない。スクロール連動の lazy-load のみ OK。ユーザーアクション（クリック / タップ / swipe）を必要とする lazy-load の主要コンテンツは評価対象外

これらの内容を採点付きで挑戦したい場合は、本ドメインのプロ試験で 5 問形式で確認できる。