モバイルSEOチェックリスト

要点 — モバイルSEOは、いまやSEOそのものです。Googleはページのモバイル版を使ってサイトをインデックス登録し、順位付けします。したがって確認点は3つです。モバイル版にデスクトップ版と同じ重要コンテンツを載せること、スマートフォンで高速かつ滑らかに動作させること、親指で操作しやすくすることです。なお、古いモバイルフレンドリーテストは廃止済みなので使いません。

Evidence for this claim Google predominantly uses the mobile version of a site's content for indexing and ranking. Scope: Google mobile-first indexing behavior. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile-first indexing Evidence for this claim Google recommends responsive web design as the easiest mobile configuration to implement and maintain. Scope: Google's implementation recommendation; other supported configurations can work. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile site configurations

モバイルSEOがSEOそのものになった理由

長年、モバイルSEOは脇役でした。まずデスクトップ向けに最適化し、その後でスマートフォン表示が崩れていないか確認する、という扱いです。しかし、その時代は終わりました。2024年7月以降、Googleはデスクトップ検索を含むすべての検索で、ページのモバイル版のみをインデックス登録と順位付けの基準にしています。モバイル版の品質がデスクトップ版より低ければ、Googleが評価するのはその低品質な版です。

つまり、現在のモバイルSEOチェックリストは簡潔ですが、確実に実行する必要があります。

1. モバイルとデスクトップで同じコンテンツ（「コンテンツパリティ」）

最重要項目です。Googleに認識させたい見出し、本文、画像と代替テキスト、内部リンク、構造化データは、すべてページのモバイル版にも存在しなければなりません。モバイルテンプレートがセクションをひそかに省いたり、単に折りたたむのではなく段落をページから削除したり、内部リンクを減らしたりすると、Googleはそのコンテンツを認識できない可能性があります。

モバイル版でタブやアコーディオン内にコンテンツを収めること自体は問題ありません。ページのHTMLに実際に含まれていれば、Googleは読み取れます。問題になるのは、コンテンツが本当に欠落している場合です。

2. スマートフォンでの速度と応答性（Core Web Vitals）

Googleは、モバイルとデスクトップを分けて3つのCore Web Vitalsを測定します。

• LCP — 画面内で最大の要素が表示されるまでの速さ（2,5秒以下が目安）。
• INP — タップに対してページが反応するまでの速さ（200ミリ秒以下が目安）。
• CLS — 読み込み中にレイアウトがどの程度ずれるか（0,1以下が目安）。

一般に、モバイルのスコアはデスクトップより低くなります。スマートフォンはネットワークやCPUが遅いためです。特によくある重大なミスは、主要なヒーロー画像を遅延読み込みすることです。ファーストビューより下の画像は遅延読み込みして構いませんが、ページ上部の大きな画像には使わないでください。

3. 親指で使いやすいこと

• ページを画面幅に合わせる正しいビューポートタグ：<meta name="viewport" content="width=device-width, initial-scale=1">。
• タップターゲットは約48×48ピクセル以上とし、隣同士に間隔を設ける。
• 本文は16px以上にして、ピンチズームせず読めるようにする。
• 検索結果から訪れた直後にページ全体を覆う巨大なポップアップを表示しない。

以前使われていたツールは廃止済み

「Googleのモバイルフレンドリーテストを実行する」と案内するガイドは古い情報です。Googleは2023年12月に同ツールとSearch Consoleのモバイルユーザビリティレポートを廃止しました。 現在はPageSpeed Insights（pagespeed.web.dev）、ChromeのLighthouse、Search ConsoleのURL検査、Core Web Vitalsレポートを使います。

コンテンツ同等性の例外、Google自身も認めたLCP画像の遅延読み込み問題、旧指標FIDとINPの違い、インタースティシャルの例外、AMPの現状、Bingとの違いまで含む監査方法は、「Advanced」タブで確認できます。

要点 — モバイルファーストインデックスは2024年7月5日に最終移行が完了し、Googleはすべてのデバイスの検索でモバイルHTMLを順位付けに使用します。確認事項は次の4つです。(1) コンテンツの同等性 — 本文、タイトルとメタディスクリプション、見出し、画像、代替テキスト、内部リンク、構造化データをモバイル版とデスクトップ版で揃える。(2) モバイルのCore Web Vitals — LCPは2,5秒以下（LCP画像を遅延読み込みしない）、INPは200ms以下（2024年3月12日にFIDから移行）、CLSは0,1以下。(3) ユーザビリティ — 正しいビューポート、48×48px以上のタッチターゲット、16px以上のフォント、邪魔なインタースティシャルを避ける（例外あり）。(4) 現行ツールでの監査 — Lighthouse、PageSpeed Insights、URL検査、CWVレポートを使う。モバイルフレンドリーテストとGSCモバイルユーザビリティレポートは2023年12月に廃止済みです。Googleはレスポンシブデザインを推奨しています。AMPには2021年6月以降、順位上の優位性がありません。Bingはモバイルファーストインデックスを採用していません。

Evidence for this claim Google predominantly uses the mobile version of a site's content for indexing and ranking. Scope: Google mobile-first indexing behavior. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile-first indexing Evidence for this claim Google recommends responsive web design as the easiest mobile configuration to implement and maintain. Scope: Google's implementation recommendation; other supported configurations can work. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile site configurations

基本：モバイルファーストインデックスは完了しました

ほかの項目を理解するための前提です。Googleは2023年10月にモバイルファーストインデックスへの移行がほぼ完了したと発表し、2024年7月5日に最終措置を実施しました。Googlebot Smartphoneでアクセスできないサイトはインデックス登録されなくなり、デスクトップファーストのクロールは終了しました。

重要なのは、ページのモバイル版が、すべてのデバイスと検索で順位を決める基準になることです。デスクトップ検索も例外ではありません。補助的な「モバイル体験」を最適化するのではなく、サイトの基準となる版を最適化します。

1. コンテンツの同等性 — 最も重要な技術的要件

このリストで1項目だけ直すなら、コンテンツの同等性を選びます。Googleの案内は明確です。「“Make sure that your mobile site contains the same content as your desktop site.”」 (翻訳) 「モバイルサイトにデスクトップサイトと同じコンテンツを含めてください」。つまり、見出し、本文、画像、代替テキスト、内部リンクを両版で揃えます。さらに、「“Make sure that the title element and the meta description are equivalent across both versions.”」 (翻訳) 「タイトル要素とメタディスクリプションを両方の版で同等にしてください」とされています。

実用的な同等性チェック：

• 本文がモバイル版にもあり、簡略化されたテンプレートで削除されていないこと。
• タイトルとメタディスクリプションが両版で同等であること。
• 見出し（同じH1／H2構造）がモバイルHTMLにもあること。
• 画像にデスクトップ版と同じ説明的な代替テキスト、キャプション、ファイル名があること。
• 内部リンクがモバイル版にもあること。「簡略化した」ナビゲーションでリンク構造を失わないこと。
• 「“lazy-load primary content upon user interaction”」 (翻訳) 「ユーザー操作に応じて主要コンテンツを遅延読み込みする」ことを避ける。タップ後にしか表示されないコンテンツをGoogleは認識できない可能性があります。

同等性には2つの注意点があります。タブやアコーディオンは問題ありません。 折りたたみ式UIに再構成されていても、コンテンツがDOM内にあればインデックス登録の対象です。問題は、モバイル版のマークアップから完全に削除されたコンテンツです。また、robots metaタグも両版で揃える必要があります。 「“Use the same robots meta tags on the mobile and desktop site”」 (翻訳) 「モバイルサイトとデスクトップサイトで同じrobots metaタグを使用してください」。揃っていないと、Googleが実際に使うモバイル版を誤ってnoindexにするおそれがあります。

2. 構造化データの同等性

構造化データにも同じ原則が適用されます。Googleは2018年12月に、「“If you use structured data on the desktop versions of your pages, you should have the same structured data on the mobile versions of the pages, since with mobile-first indexing, we’ll only use the mobile version of your page for indexing.”」 (翻訳) 「デスクトップ版で構造化データを使う場合は、モバイル版にも同じ構造化データを用意してください。モバイルファーストインデックスでは、インデックス登録にモバイル版のみを使用するためです」と案内しました。リッチリザルトテスト（現在も提供中）で確認してください。個別URL（m-dot）構成では、構造化データ内のURLが正しいモバイルURLを参照している必要があります。

3. クロール可能性とrobots設定

• robots.txtで、モバイルページのレンダリングに必要なリソース（CSS、JS）をブロックしない。Googleがレンダリングできなければ、同等性も確認できません。
• robots metaタグをすべての版で一致させる。
• 個別URLの場合は正規化を正しく設定する。両版でデスクトップURLをcanonicalにし、デスクトップ版にはモバイルURLを指すrel="alternate"を設定する。

4. モバイルでの Core Web Vitals

GoogleはCWVを、モバイルとデスクトップに分けたページ読み込みの75パーセンタイルで測定し、Core Web Vitalsをランキングシステムで使用しています。差が出やすいのはモバイルです。ネットワークやCPUが遅いため、3指標すべての合格率はモバイルで約48%、デスクトップで約56%となっており、主にLCPとINPが差を生んでいます。

しきい値（良好／要改善／不良）は次のとおりです。

• LCP — 2,5秒以下／2,5～4,0秒／4,0秒超。
• INP — 200ms以下／200～500ms／500ms超。
• CLS — 0,1以下／0,1～0,25／0,25超。

LCP — ヒーロー画像を遅延読み込みしない。 モバイルパフォーマンスで特によくある重大なミスです。web.devは、「“Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.”」 (翻訳) 「LCP画像を遅延読み込みしないでください。不要なリソース読み込み遅延が必ず生じ、LCPに悪影響を及ぼします」と明記しています。代わりに、プリロードまたは<img>へ直接指定したfetchpriority="high"で優先度を伝えます。GoogleのMartin Splitt氏も、GoogleのCMSが*「“defaults all images to lazy loading, which is not great.”」* (翻訳) 「すべての画像を既定で遅延読み込みにしており、望ましくない」状態だったと認めています。Googleでも起きるため、自サイトでも注意が必要です。

INP — FIDとの違い。 INP（Interaction to Next Paint）は2024年3月12日にFIDを置き換えました。 FIDが最初の操作について処理開始前の遅延だけを測ったのに対し、INPはページ利用中の操作全体から遅い応答を評価します。そのため、低性能なCPUでタッチ操作が200msのしきい値を超えやすいモバイルでは、遅いJavaScriptの影響がより明確に表れます。監査資料がまだFIDだけを扱っているなら古い情報です。

CLS — スペースを確保します。 画像や埋め込みに明示的な width と height（または aspect-ratio）を設定し、広告や遅延読み込みコンテンツ用にスペースを確保し、読み込み後にファーストビューにコンテンツを注入しないでください。

5. モバイルでの画像と動画

• WebP／AVIFなどの新しい形式と、対応している形式のみを使う。インラインSVG内のJPGはインデックス登録されません。
• srcsetとsizesでレスポンシブ画像を配信し、CLSを防ぐためwidthとheightを明示する。
• 小さすぎる画像や低解像度画像を避ける。また、頻繁に変わる画像URLを避ける。読み込みごとにURLを生成すると画像のインデックス登録を妨げます。
• デスクトップ版と同じ代替テキスト、タイトル、キャプション、ファイル名を使う。
• 動画は有効なHTMLタグ（<video>、<embed>、<object>）と対応形式を使い、安定したURLと一致する動画構造化データを用意し、スクロール量が少ない目立つ位置に配置する。

6. モバイルユーザビリティ

• ビューポート： <meta name="viewport" content="width=device-width, initial-scale=1">。width=device-widthは必須です。maximum-scale=1やuser-scalable=noはピンチズームを妨げ、アクセシビリティ上の問題になるため避けます。ビューポートタグがないと、モバイルブラウザは約980pxのデスクトップ幅で描画して縮小します。
• タッチターゲット： 48×48 CSSピクセル以上、隣接するターゲットとの間隔は8px以上を目安にする。
• フォントサイズ： 本文を16px以上にして、読みにくい小さな文字を避ける。
• フォーム： tel、email、numberなど適切な入力タイプを使い、スマートフォンで適切なキーボードを表示する。

7. インタースティシャルと広告 — および例外

「ポップアップがあると順位が下がる」という説明は単純化しすぎです。対象になるのは邪魔な形式です。「“Don’t obscure the entire page with interstitials”」 (翻訳) 「インタースティシャルでページ全体を覆わないでください」、および*「“Don’t redirect the user to a separate page for their consent or input”」* (翻訳) 「同意や入力のために別ページへリダイレクトしないでください」とGoogleは案内しています。ユーザーが操作する前に表示する全画面ポップアップや、独立したインタースティシャルページが該当します。

明示的に許容される例： 法律上必要なCookie同意バナー、正規のペイウォールに対するログイン画面、画面の妥当な範囲を使う小さなバナー、法的に必要な年齢確認です。また、インタースティシャルのシグナルはCore Web Vitalsの指標ではありません。Googleは、「“Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results. However, they can make your website more satisfying to use.”」 (翻訳) 「Core Web Vitals以外のページエクスペリエンス要素は検索順位の上昇に直接寄与しませんが、サイトをより快適に使えるようにします」と説明しています。広告はBetter Ads Standardに従ってください。

8. AMP: 中立、廃止でも必須でもない

AMPは2021年6月に順位上の優位性を失いました。 Googleがトップニュースの掲載条件からAMP要件を外したためです。Core Web Vitalsが良好な通常ページもトップニュースに掲載され得ます。AMPページは引き続き動作しますが、適切に最適化した標準ページに対するSEO上の利点はありません。すでにAMPを使っている場合は、移行コストと利点を比較してください。SEO目的で新たに採用する理由はなくなりました。

9. サイト構成: レスポンシブが推奨される方法

Googleの推奨順に並べると、構成は次の3つです。

1. レスポンシブデザイン（推奨）： 同じURLとHTMLを使い、CSSでレイアウトを調整します。URLが1つなので重複リスクがなく、構造上も同等性を保ちやすい方式です。
2. 動的配信： 同じURLで、ユーザーエージェントに応じて異なるHTMLを返します。モバイルユーザーへ誤ってデスクトップ用HTMLを返すリスクがあります。
3. 個別URL（m-dot）： 異なるURLで異なるHTMLを配信します。慎重な正規化と、最も厳格な同等性管理が必要です。John Mueller氏は以前から、「“At some point all of these sites with separate mobile URLs should just move to a responsive design.”」 (翻訳) 「いずれ、個別のモバイルURLを持つサイトはすべてレスポンシブデザインへ移行すべきです」と述べています。

10. 現在の非推奨ではないツールで監査する

2025年時点のモバイルチェックリストでは、ツールが現行かどうかも重要です。Googleは2023年12月初旬にMobile-Friendly Test、同API、GSC Mobile Usabilityレポートを廃止しました。 Googleは*「“Today we’re sunsetting Search Console’s Mobile Usability report, Mobile-Friendly Test tool and Mobile-Friendly Test API,”」* (翻訳) 「本日、Search Consoleのモバイルユーザビリティレポート、モバイルフレンドリーテスト、同APIを廃止します」と発表し、「“many other robust resources for evaluating mobile usability have emerged.”」 (翻訳) 「モバイルユーザビリティを評価する堅牢なリソースがほかにも多数登場した」ことを理由に挙げました。

代わりにこれらを使用してください:

• PageSpeed Insights（ラボデータとフィールドデータ、モバイルタブ）。
• Lighthouse（Chrome DevTools、モバイルモード）。
• GSC Core Web Vitalsレポート（フィールドデータをモバイルで絞り込む）。
• GSC URL検査（Googlebotが特定ページをどうレンダリングするか確認）。
• リッチリザルトテスト（構造化データを検証）。
• CrUX Vis（cruxvis.withgoogle.com）。廃止済みのCrUX Dashboardに代わり、モバイルCWVの推移を確認できるGoogleの現行ツールです。

ボーナス: Bingは異なる — デスクトップファースト

多くのガイドが見落とす重要な違いです。Bingはモバイルファーストインデックスを採用していません。 主なクロール対象はページのデスクトップ版です。モバイルフレンドリー性は2015年からBingのランキングシグナルですが、インデックス方式ではありません。そのためBingでもモバイル版の同等性は重要ですが、理由はモバイルHTMLだけを認識するからではなく、順位評価に影響するからです。Bing Webmaster Toolsでモバイル関連のクロールエラーを監視し、サイトマップを送信し、構造化データを検証してください。

AIまとめ

Advancedタブの要点です。

• モバイルファーストインデックスは完了済み（2024年7月5日に最終移行）。Googleはデスクトップ検索を含むすべてのデバイスの検索で、モバイルHTMLを基準に順位付けします。
• 最重要ルールはコンテンツの同等性。 本文、タイトルとメタディスクリプション、見出し、画像と代替テキスト、内部リンク、robots metaタグ、構造化データを両版で揃えます。タブやアコーディオンは問題ありませんが、コンテンツの欠落は問題です。
• モバイルのCore Web Vitals： LCPは2,5秒以下、INPは200ms以下、CLSは0,1以下（75パーセンタイル）。3指標の合格率はモバイル約48%、デスクトップ約56%です。
• LCP画像を遅延読み込みしない。 特によくある重大なミスです。fetchpriority="high"を使います。Google自身も同様の不具合を出したことを認めています。
• INPは2024年3月12日にFIDを置き換えました。 ページ利用中の操作全体を評価するため、最初の操作だけを見るFIDより、遅いモバイルJavaScriptの影響を捉えやすい指標です。
• ユーザビリティ： 正しいビューポート（user-scalable=noを使わない）、48×48px以上のタッチターゲット、16px以上のフォント、モバイルに適した入力タイプ。
• インタースティシャルには例外がある。 Cookie同意、ペイウォールのログイン、小さなバナー、法的な年齢確認は許容されます。このシグナルはCWV指標ではありません。
• AMPは中立。 2021年6月以降、順位上の利点はありませんが、引き続き動作します。
• Googleはレスポンシブデザインを推奨。 動的配信やm-dotより同等性を保ちやすい方式です。
• 現行ツール： Lighthouse、PageSpeed Insights、URL検査、CWVレポート、リッチリザルトテスト、CrUX Vis。モバイルフレンドリーテストとGSCモバイルユーザビリティレポートは2023年12月に廃止済みです。
• Bingはモバイルファーストインデックスを採用していない。 デスクトップファーストで、モバイルフレンドリー性はランキングシグナルです。

公式ドキュメント

検索エンジンが提供する一次資料です。

Google

• モバイルファーストインデックスのベストプラクティス — コンテンツの同等性、ビューポート、画像と動画、robots metaタグ、3種類のサイト構成。
• モバイルファーストインデックスの最終段階（2024年6月） — 2024年7月5日の最終措置。
• モバイルファーストインデックスへの移行完了（2023年10月） — それ以前の大部分の移行完了発表。
• モバイルファーストインデックスと構造化データ（2018年12月） — 構造化データを両版で揃える要件。
• 邪魔なインタースティシャルとダイアログを避ける — 対象となる形式と例外。
• Google検索におけるページエクスペリエンス — CWVなどのページエクスペリエンス要素と順位の関係。
• Core Web VitalsとGoogle検索結果 — ランキングシステムでのCWVの利用。
• web.dev — Web Vitals — LCP／INP／CLSのしきい値と、モバイル・デスクトップ別の75パーセンタイル測定。
• web.dev — Largest Contentful Paintの最適化 — LCP画像の遅延読み込み回避とfetchpriority。

Bing／Microsoft

• Bingウェブマスターガイドライン — モバイルフレンドリー性をランキングシグナルとして扱う方針。Bingはデスクトップファーストです。

出典からの引用

Googleの公式声明です。各リンクは引用箇所または出典ページに移動します。

Google — コンテンツの同等性

• “Make sure that your mobile site contains the same content as your desktop site.” (翻訳) 「モバイルサイトにデスクトップサイトと同じコンテンツを含めてください。」 — Google Search Central。 引用へ
• “Make sure that the title element and the meta description are equivalent across both versions.” (翻訳) 「タイトル要素とメタディスクリプションを両方の版で同等にしてください。」 引用へ
• “Don’t lazy-load primary content upon user interaction.” (翻訳) 「ユーザー操作に応じて主要コンテンツを遅延読み込みしないでください。」 引用へ

Google — 構造化データの同等性

• “If you use structured data on the desktop versions of your pages, you should have the same structured data on the mobile versions of the pages, since with mobile-first indexing, we’ll only use the mobile version of your page for indexing.” (翻訳) 「デスクトップ版で構造化データを使う場合は、モバイル版にも同じ構造化データを用意してください。モバイルファーストインデックスでは、インデックス登録にモバイル版のみを使用するためです。」 — Google Search Central、2018年12月。 出典

Google — インタースティシャル

• “Don’t obscure the entire page with interstitials” (翻訳) 「インタースティシャルでページ全体を覆わないでください」。また、“Don’t redirect the user to a separate page for their consent or input.” (翻訳) 「同意や入力のためにユーザーを別ページへリダイレクトしないでください」。 出典

Google — ページエクスペリエンスのニュアンス

• “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results. However, they can make your website more satisfying to use.” (翻訳) 「Core Web Vitals以外のページエクスペリエンス要素は検索順位の上昇に直接寄与しませんが、サイトをより快適に使えるようにします。」 出典

Google — Core Web Vitals

• “Core Web Vitals are used by our ranking systems. We recommend site owners achieve good Core Web Vitals for success with Search.” (翻訳) 「Core Web Vitalsはランキングシステムで使用されます。検索で成果を上げるため、サイト所有者には良好なCore Web Vitalsの達成を推奨します。」 出典
• “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” (翻訳) 「適切な測定しきい値は、モバイルとデスクトップに分けたページ読み込みの75パーセンタイルです。」 — web.dev。 引用へ

Google (web.dev) — LCP と遅延読み込み

• “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (翻訳) 「LCP画像を遅延読み込みしないでください。不要なリソース読み込み遅延が必ず生じ、LCPに悪影響を及ぼします。」 出典

Martin Splitt、Google (Search Engine Journal 経由)

• “If you are using lazy loading on an image that is immediately visible, that is most likely going to have an impact on your largest contentful paint.” (翻訳) 「すぐに見える画像を遅延読み込みすると、Largest Contentful Paintに影響する可能性が高いです」。Google自身のCMSについては、“defaults all images to lazy loading, which is not great.” (翻訳) 「すべての画像を既定で遅延読み込みにしており、望ましくありません」と述べています。 報道を読む

Google — モバイルツールの廃止

• “Today we’re sunsetting Search Console’s Mobile Usability report, Mobile-Friendly Test tool and Mobile-Friendly Test API.” (翻訳) 「本日、Search Consoleのモバイルユーザビリティレポート、モバイルフレンドリーテスト、同APIを廃止します」。理由については、“In the nearly ten years since we initially launched this report, many other robust resources for evaluating mobile usability have emerged.” (翻訳) 「このレポートを公開してから約10年の間に、モバイルユーザビリティを評価する堅牢なリソースがほかにも多数登場しました」と説明しています。 報道を読む

John Mueller、Google (Ahrefs のモバイル SEO ガイド経由)

• “At some point all of these sites with separate mobile URLs should just move to a responsive design.” (翻訳) 「いずれ、個別のモバイルURLを持つサイトはすべてレスポンシブデザインへ移行すべきです。」 出典

モバイルSEOチェックリスト

上から順に確認してください。最初のグループは必須項目で、残りは品質を高める項目です。すべて合格しても、Googleが挙げる技術的な障害がなくなるだけで、順位、インデックス登録、検索結果での同一扱いを保証するものではありません。残る結果はコンテンツの品質と関連性で決まります。

コンテンツの同等性（最優先）

• モバイル版にデスクトップ版と同じ本文があり、簡略化したテンプレートで削除されていない。
• タイトルとメタディスクリプションが両版で同等である。
• モバイルHTMLに同じ見出し構造（H1／H2など）がある。
• 同じ画像が、同じ説明的な代替テキスト、キャプション、ファイル名で掲載されている。
• モバイル版にも同じ内部リンクがある。
• 構造化データがデスクトップ版と一致する（リッチリザルトテストで確認）。
• robots metaタグが両版で同一で、モバイル版だけに誤ったnoindexがない。
• ユーザー操作後に主要コンテンツを遅延読み込みする仕組みがない。

技術設定

• 可能な限りレスポンシブデザインを使う（動的配信やm-dotより優先）。
• robots.txtがモバイル版のレンダリングに必要なCSS／JSをブロックしていない。
• m-dotの場合、両版でデスクトップURLをcanonicalにし、デスクトップ版からモバイル版へrel="alternate"を設定する。エラーページのステータスコードを揃え、両方をGSCで確認する。

パフォーマンス／Core Web Vitals（モバイルのフィールドデータ）

• LCPは2,5秒以下で、LCP画像を遅延読み込みしていない（fetchpriority="high"を使用）。
• INPは200ms以下で、廃止済みのFIDではなくINPを監査している。
• CLSは0,1以下で、画像や埋め込みにwidth／heightを明示し、広告や後続コンテンツの領域を確保している。
• WebP／AVIFなどの新しい画像形式、レスポンシブなsrcset／sizes、安定した画像URLを使っている。

ユーザビリティ

• ビューポートにwidth=device-width, initial-scale=1を設定している。
• maximum-scale=1やuser-scalable=noを使わず、ピンチズームを妨げていない。
• タッチターゲットは48×48px以上、間隔は8px以上。
• 本文フォントは16px以上。
• フォームで適切な入力タイプ（tel、email、number）を使っている。
• 検索結果からの遷移直後に邪魔なインタースティシャルを表示しない（Cookie、年齢確認、ログインの例外を除く）。

ツール（現行のものだけを使用）

• Lighthouse（モバイルモード）とPageSpeed Insightsで監査する。
• GSC Core Web Vitalsレポートをモバイルで絞り込んで確認する。
• GSC URL検査でレンダリングを確認する。
• 2023年12月に廃止されたモバイルフレンドリーテストやGSCモバイルユーザビリティレポートに依存しない。

モバイルSEOチートシート

確認項目 → ツール → 合格基準

Core Web Vitalsのしきい値（モバイル、75パーセンタイル）

早わかり

• モバイルファーストインデックスは2024年7月5日に最終移行が完了し、モバイルHTMLがすべての検索で順位付けの基準になります。
• INPは2024年3月12日にFIDを置き換えました。
• モバイルフレンドリーテストとGSCモバイルユーザビリティレポートは2023年12月に廃止されました。
• AMPには2021年6月以降、順位上の利点がありません（トップニュースでも必須ではありません）。
• Bingはデスクトップファーストで、モバイルフレンドリー性はランキングシグナルであり、インデックス方式ではありません。

判断モデル

1. モバイル版が基準です。 「デスクトップサイトにモバイル体験を追加する」という発想をやめます。2024年7月以降、Googleがすべての検索でインデックス登録と順位付けに使うのはモバイルHTMLです。監査では常に「Googlebot Smartphoneがこのページで実際に認識するものは何か」を問います。

2. 同等性 → パフォーマンス → ユーザビリティの順で確認します。 モバイル版にコンテンツがなければ、速度をいくら改善しても、そのコンテンツをGoogleは順位付けできません。まず同等性を確保し、次にCore Web Vitalsを改善し、最後に指での操作性を磨きます。コンテンツが欠けたページでCWVだけを改善しても、対象とする層が違います。

3. 順位評価に使われるのはラボデータではなくフィールドデータです。 Lighthouseは管理環境でのラボスコアを示し、CrUXとGSCは実際の利用者による75パーセンタイルのフィールドデータを示します。ランキングシステムが使うのは後者です。ラボデータは診断に、フィールドデータは判定に使います。Lighthouseが良好でもフィールドCWVが悪ければ問題は残っています。

4. 廃止済みのツールを現行ツールへ置き換えます。 古いツールを推奨し続けると、モバイルSEO監査の信頼性が損なわれます。モバイルフレンドリーテストはLighthouse／PageSpeed Insightsへ、GSCモバイルユーザビリティレポートはCWVレポート＋URL検査へ、FIDはINPへ置き換えます。手順に矢印の左側が残っていれば更新が必要です。

5. ペナルティの例外まで確認します。 すべてのインタースティシャルが順位を下げるわけではなく、対象は邪魔な形式です。Cookie同意、ペイウォールのログイン、小さなバナー、法的な年齢確認は例外です。絶対的に見えるルールほど、誤解に基づいて設計を変える前に一次資料で例外を確認します。

毎月のモバイルSEOヘルスチェック

1. モバイルのフィールドデータを確認する。 Search ConsoleのCore Web VitalsレポートとPageSpeed Insightsを代表的なテンプレートで開きます。影響を受けるURLグループと変化した指標を記録します。完了条件は、新しい問題ごとに担当者または監視を続ける理由が記録されていることです。
2. コンテンツの同等性を抽出確認する。 モバイルとデスクトップのクロールについて、タイトル、robots、canonical、見出し、主要本文、内部リンク、画像、構造化データを比較します。完了条件は、重要な差異が意図したレイアウト変更または対応チケットとして説明できることです。
3. 変更したテンプレートをGooglebot Smartphoneとして検査する。 最近公開した各ページ種別からサンプルを選び、URL検査を使います。完了条件は、主要コンテンツとシグナルが操作なしでレンダリング後HTMLに現れることです。
4. 実機に近いユーザビリティ確認を行う。 一般的なスマートフォン幅で、ズーム、横方向のはみ出し、タッチターゲット、フォーム、ナビゲーション、インタースティシャルを確認します。完了条件は、重大な不具合を再現でき、担当者が決まっていることです。
5. パフォーマンス変化に注釈を付けて比較する。 Search Consoleのモバイルパフォーマンスをテンプレート別に分け、リリース、移行、キャンペーンを記録します。完了条件は、異常について無条件のサイト全体結論ではなく、範囲を限定した調査があることです。

避けるべきモバイル監査の誤り

廃止されたGoogleツールを監査計画として使用する

モバイルフレンドリーテストとSearch Consoleのモバイルユーザビリティレポートは廃止済みです。Lighthouse、PageSpeed Insights、URL検査、Core Web Vitalsレポート、実機での確認を使ってください。

視覚的なレイアウトのみを確認する

見た目がレスポンシブでも、モバイルHTMLから本文、リンク、ディレクティブ、画像、構造化データが抜けていることがあります。スクリーンショットだけでなく、インデックス登録の対象になる出力を比較してください。

LCP画像を遅延読み込みする

主要画像の読み込みを遅らせると、LCPを決めるリソースの表示も遅れます。初期マークアップで検出できるようにし、優先的に読み込んでください。

アコーディオンコンテンツを欠落コンテンツとして扱う

折りたたまれたコンテンツがDOM内に残っていれば問題ありません。モバイルテンプレートが削除するコンテンツや、操作後にしか読み込まないコンテンツを探してください。

サイト全体に単一のラボスコアを適用する

Lighthouseの1回の結果は診断値であり、代表的なフィールド性能ではありません。複数のページ種別を抽出し、ラボ結果とモバイルのフィールドデータを組み合わせて判断してください。

モバイルSEO監査でよくある問題

モバイルHTMLにデスクトップコンテンツが欠落している

症状： クロールの比較で、モバイル版の見出し、リンク、画像、スキーマ項目が少ない。原因候補： 個別テンプレートまたはユーザーエージェント規則に不整合がある。修正： 共通のコンテンツソースから要素を復元し、モバイル版の取得結果とURL検査で確認する。

Lighthouseは良好だがフィールドデータが悪い

症状： 管理環境でのラボテストは合格するが、モバイルのCore Web Vitalsグループは不合格。原因候補： 実際の端末、ネットワーク、操作、テンプレートが単一テストの条件と異なる。修正： 影響を受けるURLグループと指標の分布を特定し、代表的な端末で再現して、サンプルURLだけでなく共通のボトルネックを改善する。

一部のスマートフォンでページが水平方向にオーバーフローする

症状： ビューポートmetaタグがあるのに横スクロールが必要。原因候補： 固定幅の子要素、改行されない長い値、表、埋め込みメディア、変形した要素がコンテナを超えている。修正： 問題が起きる画面幅で、はみ出しているノードを特定する。メディアをレスポンシブな範囲に収め、ズーム時と横向き表示も再確認する。

モバイルSEO監査用プロンプト

モバイル／デスクトップのクロール差分を整理する

Review this crawl comparison with mobile and desktop columns for status, title,
robots, canonical, H1, word count, internal-link count, image count, and structured
data types. Identify material content-parity exceptions, separate likely layout-only
differences, group issues by template, and give a direct verification step for each
group. Do not infer missing content from count differences alone.

[paste CSV]

フィールドデータの結果を対応チケットに変換する

Turn these mobile Core Web Vitals findings into implementation tickets. For each URL
group, preserve the observed metric and evidence, distinguish field data from lab
diagnostics, list the most likely shared template causes as hypotheses, and define a
pass/fail validation step. Do not invent a cause or promise a ranking change.

[paste findings]

理解度テスト：モバイルSEO

モバイルファースト環境の監査について5問出題します。各問の答えを選び、解説を確認してください。

参照する価値のある資料

関連する私の記事

• テクニカルSEO初心者ガイド — モバイルSEOとテクニカルSEO全体の関係。
• モバイルSEO（Ahrefsブログ、Jamie Grant） — Mueller氏のレスポンシブ移行に関する発言を含む詳細解説。
• Core Web Vitals — LCP、INP、CLS、しきい値、フィールドデータとラボデータのまとめ。
• Largest Contentful Paint — LCPと遅延読み込みの問題の詳細。
• Interaction to Next Paint — INPの測定内容と、モバイルで悪化しやすい理由。
• モバイルファーストインデックス — インデックス登録の仕組みと確認済みの経緯。

公式資料

• Google — モバイルファーストインデックスのベストプラクティス。
• web.dev — Web VitalsおよびLCPの最適化。
• Bingウェブマスターガイドライン。

業界資料

• GoogleがMobile Usabilityレポート、Mobile-Friendly Test、APIを正式廃止（Search Engine Land、2023年12月） — 廃止とGoogleの声明。
• Google解説：遅延読み込みがLargest Contentful Paint（LCP）を遅らせる理由（Search Engine Journal） — Martin Splitt氏によるLCP画像の遅延読み込み解説とGoogle自身のCMSの例。
• モバイルSEO（Ahrefs、Jamie Grant） — 包括的なモバイルSEO解説。
• モバイルSEOチェックリスト（Nostra.ai） — モバイルトラフィックの背景を含むチェックリスト形式の資料。
• r/TechSEO — モバイルのクロール、レンダリング、同等性問題を扱うコミュニティ。

変更履歴