Canonical: https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/ Description: Googleはモバイルフレンドリーテストを終了しました。代わりになる無料ツール、PageSpeed Insights APIの使用例、合格の基準値をまとめます。 Published: 2025-12-15T00:00:00.000Z Modified: 2026-09-06T00:00:00.000Z [← ブログ](https://www.strataigize.com/ja/insights/) ![](https://www.strataigize.com/blog/real/cover-check-mobile-friendliness-website.webp) # モバイルフレンドリーテスト2026: 無料ツールとPSI API 著者 [**Ian McGavin**](https://www.strataigize.com/ja/about/team/ian/), 創業者兼CMO · 公開 2025年12月15日 · 更新 2026年9月6日 · 2 分で読める 2026年にモバイルフレンドリーかどうかを確認するには、URLをGoogle PageSpeed Insightsで測定し、Chrome DevToolsのLighthouseで監査し、DevToolsのデバイスモードでブレークポイントを確認し、Search ConsoleのCore Web Vitalsレポートを見て、最後に実機のスマートフォンですべてを確かめます。Googleは単体のモバイルフレンドリーテストを2023年12月に終了しており、これらがその代わりになったツールです。 この記事の内容 1. [2026年も使えるモバイルフレンドリーのチェックツール](https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/#2026%E5%B9%B4%E3%82%82%E4%BD%BF%E3%81%88%E3%82%8B%E3%83%A2%E3%83%90%E3%82%A4%E3%83%AB%E3%83%95%E3%83%AC%E3%83%B3%E3%83%89%E3%83%AA%E3%83%BC%E3%81%AE%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%83%84%E3%83%BC%E3%83%AB) 2. [PageSpeed InsightsとLighthouseでモバイル監査を行う](https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/#pagespeed-insights%E3%81%A8lighthouse%E3%81%A7%E3%83%A2%E3%83%90%E3%82%A4%E3%83%AB%E7%9B%A3%E6%9F%BB%E3%82%92%E8%A1%8C%E3%81%86) 3. [モバイルフレンドリーテストAPIの代わりはある?](https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/#%E3%83%A2%E3%83%90%E3%82%A4%E3%83%AB%E3%83%95%E3%83%AC%E3%83%B3%E3%83%89%E3%83%AA%E3%83%BC%E3%83%86%E3%82%B9%E3%83%88api%E3%81%AE%E4%BB%A3%E3%82%8F%E3%82%8A%E3%81%AF%E3%81%82%E3%82%8B) 4. [Lighthouseをローカルで実行する](https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/#lighthouse%E3%82%92%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%AB%E3%81%A7%E5%AE%9F%E8%A1%8C%E3%81%99%E3%82%8B) 5. [Chrome DevToolsのデバイスエミュレーションの手順](https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/#chrome-devtools%E3%81%AE%E3%83%87%E3%83%90%E3%82%A4%E3%82%B9%E3%82%A8%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E6%89%8B%E9%A0%86) 6. [Search ConsoleでCore Web Vitalsのモバイルデータを読む](https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/#search-console%E3%81%A7core-web-vitals%E3%81%AE%E3%83%A2%E3%83%90%E3%82%A4%E3%83%AB%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92%E8%AA%AD%E3%82%80) 7. [よくあるモバイルの不具合と直し方](https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/#%E3%82%88%E3%81%8F%E3%81%82%E3%82%8B%E3%83%A2%E3%83%90%E3%82%A4%E3%83%AB%E3%81%AE%E4%B8%8D%E5%85%B7%E5%90%88%E3%81%A8%E7%9B%B4%E3%81%97%E6%96%B9) 8. [私たちが行う監査の手順](https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/#%E7%A7%81%E3%81%9F%E3%81%A1%E3%81%8C%E8%A1%8C%E3%81%86%E7%9B%A3%E6%9F%BB%E3%81%AE%E6%89%8B%E9%A0%86) 9. [WordPressやShopifyを使っている場合](https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/#wordpress%E3%82%84shopify%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B%E5%A0%B4%E5%90%88) 10. [よくある質問](https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/#%E3%82%88%E3%81%8F%E3%81%82%E3%82%8B%E8%B3%AA%E5%95%8F) 11. [1つのバッジが4つのツールに置き換わった](https://www.strataigize.com/ja/insights/check-mobile-friendliness-website/#1%E3%81%A4%E3%81%AE%E3%83%90%E3%83%83%E3%82%B8%E3%81%8C4%E3%81%A4%E3%81%AE%E3%83%84%E3%83%BC%E3%83%AB%E3%81%AB%E7%BD%AE%E3%81%8D%E6%8F%9B%E3%82%8F%E3%81%A3%E3%81%9F) [Googleで優先ソースとして追加](https://www.google.com/preferences/source?q=strataigize.com) 関連する当社記事をより多く検索体験に表示する、無料のGoogle設定です。いつでも変更できます。 Googleは単体のモバイルフレンドリーテストを2023年12月に終了しましたが、モバイルでの使いやすさは今も無料で確認できます。パフォーマンスの診断にはPageSpeed InsightsとLighthouse、レイアウトの確認にはChrome DevTools、ナビゲーションとフォームの確認には実機のスマートフォンを使います。これらのチェックは、それぞれ別の問いに答えます。速いページでも押せないボタンがあることはあり、使いやすいページでも読み込みが遅いことはあります。 > 20秒で結果を知りたい場合は、無料の[モバイルフレンドリーテスト](https://www.strataigize.com/tools/mobile-friendly-test/)をお使いください。URLを貼り付けるだけで、ビューポート、固定幅、小さすぎる文字、ページの重さ、クロールの各項目が採点され、それぞれの直し方も表示されます。メールアドレスは不要です。 ![Core Web Vitalsのフィールドデータ評価とLighthouseのパフォーマンススコアを表示したPageSpeed Insightsのモバイルレポート。Googleが終了したモバイルフレンドリーテストに代わるチェックです](https://www.strataigize.com/blog/real/pagespeed-result.webp) ## 2026年も使えるモバイルフレンドリーのチェックツール 「Googleのモバイルフレンドリーテストを実行しましょう」という助言は、もう通用しません。Googleは[Search Consoleのモバイルユーザビリティレポート、モバイルフレンドリーテストツール、モバイルフレンドリーテストAPIを2023年12月1日から順次終了する](https://developers.google.com/search/blog/2023/04/page-experience-in-search)と発表し、終了は[2023年12月4日](https://searchengineland.com/google-officially-drops-mobile-usability-report-mobile-friendly-test-tool-and-mobile-friendly-test-api-435377)に公に確認されました。その発表でGoogleが挙げた理由は、モバイルでの使いやすさは引き続きページエクスペリエンスのガイダンスの一部だが、2015年以降にほかのリソースが登場したというもので、そこには「including Lighthouse from Chrome」とあります。 Googleは[2023年12月1日に検索ヘルプからこのツールへの言及をすべて削除し](https://www.seroundtable.com/google-search-consoles-mobile-usability-report-mobile-friendly-tests-are-gone-36497.html)、Search Consoleのモバイルユーザビリティ関連のURLをプロパティの概要ページへリダイレクトしました。[2023年4月の発表](https://developers.google.com/search/blog/2023/04/page-experience-in-search)では、代わりとして[Lighthouse](https://developer.chrome.com/docs/lighthouse/overview)を案内しています。終了したツールを今も使える選択肢として紹介しているガイドは、情報が古くなっています。 独立したチェックツールとしては、[BingのMobile Friendliness Test Tool](https://www.bing.com/webmaster/tools/mobile-friendliness)が残っています。ビューポートの設定、コンテンツの幅、読みやすさ、タップ対象の間隔など、Bingがモバイルでページをどう見ているかを確認します。この判定は、GoogleやAIアシスタントがそのページをどう評価し、引用するかを示すものではありません。 | ツール | 費用 | 測定する内容 | 制約 | | --- | --- | --- | --- | | PageSpeed Insights | 無料 | Lighthouseのモバイルのラボ測定と、実際のユーザーのCore Web Vitals | フィールドデータには一定のトラフィックが必要。共有用のレポートリンクはスナップショットとして[最長30日間](https://developers.google.com/speed/docs/insights/release_notes)保存されます | | Chrome DevToolsのLighthouse | 無料 | モバイルをエミュレートしたパフォーマンス、ユーザー補助、おすすめの設定、SEO、タップ対象 | ラボのみ。結果はお使いのマシンの負荷で変わります | | Chrome DevToolsのデバイスモード | 無料 | 実際のビューポートサイズでのレイアウト、はみ出し、固定要素 | エミュレーションであり、実機や実際のタッチ操作ではありません | | Search ConsoleのCore Web Vitals | 無料 | URLグループ単位でまとめた、サイト全体のモバイルのフィールドデータ | 28日間の移動期間。タップ対象やビューポートのチェックはありません | | Bing Mobile Friendliness Test | 無料 | ビューポート、コンテンツの幅、読みやすさ、タップの間隔、プラグイン | Bingの判定であり、Googleのランキング要素ではありません | | 実機またはBrowserStack | 無料プランと有料プラン | 実際のタッチ操作、ジェスチャー、ブラウザごとの表示のくせ | 多くの端末を揃えるには費用と時間がかかります | | Googleのモバイルフレンドリーテスト | 終了 | なし | 2023年12月1日に終了 | ### モバイルでの使いやすさとモバイルファーストインデックスは別のチェック Googleは、ページのコンテンツのモバイル版をインデックス登録とランキングに使います。[モバイルファーストインデックスのガイダンス](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing)は、レスポンシブデザイン、動的な配信、モバイル用の別URLのいずれにも対応しています。実装と保守がしやすいため、推奨されているのはレスポンシブデザインです。 まず、Googlebotがモバイルでコンテンツ、画像、メタデータにアクセスできるかを確認します。次に、人がそれをどれだけ簡単に使えるかを確認します。モバイルページがブロックされているならクロールの問題で、ボタンが窮屈ならユーザビリティの問題です。Lighthouseのスコアもタップ対象の測定も、それだけではページがインデックスされるかどうかはわかりません。 > 監査ツールのタブを増やすより、専門家にサイトを見てほしい場合は、[ウェブサイト最適化サービス](https://www.strataigize.com/ja/services/website-optimization/)をご覧ください。 ## PageSpeed InsightsとLighthouseでモバイル監査を行う まずは[PageSpeed Insights](https://pagespeed.web.dev/)から始めます。URLを貼り付けて実行し、「パソコン」タブより先に「モバイル」タブを読みます。 レポートは、よく混同される2つの部分に分かれています。 - 上部の**フィールドデータ**: Chrome UX Reportによる実際のChromeユーザーの測定値で、[28日間の移動期間](https://developer.chrome.com/docs/crux/methodology/tools)で毎日更新されます。Googleのページエクスペリエンスのシグナルが実際に使うのはこちらです。 - 下部の**ラボデータ**: Googleのサーバー上で行う、1回だけのLighthouseのシミュレーション測定です。診断には役立ちますが、実際のユーザーについての判定ではありません。 3つの指標すべてを含むCore Web Vitalsの評価に合格するには、[3つの指標すべてで75パーセンタイルの値](https://web.dev/articles/vitals)が「良好」の基準を満たす必要があります。フィールドデータがない場合、レポートはこの完全な評価を出せませんが、それはページが不合格だったという証拠ではありません。Lighthouseは、1回のナビゲーション測定ではフィールドのINPを測れません。 | 指標 | 良好 | 不良 | | --- | --- | --- | | Largest Contentful Paint (LCP) | 2.5秒以下 | 4.0秒超 | | Interaction to Next Paint (INP) | 200ミリ秒以下 | 500ミリ秒超 | | Cumulative Layout Shift (CLS) | 0.1以下 | 0.25超 | 出典: [web.devのCore Web Vitalsの基準値](https://web.dev/articles/defining-core-web-vitals-thresholds)(2026年時点)。INPは[2024年3月12日にFirst Input Delay (FID)に代わってCore Web Vitalsの指標になりました](https://web.dev/blog/inp-cwv-march-12)。今もFIDの最適化を勧めるチェックリストは無視してかまいません。 ### 基準を動かしたPageSpeed Insightsの2つの変更 [2024年12月5日、PageSpeed InsightsはCPU(プロセッサ)をどれだけ遅くするかの設定を調整し](https://developers.google.com/speed/docs/insights/release_notes)、その結果、モバイルのラボ測定ではTotal Blocking Timeが全体的に増えました。フィールドとパソコンの結果は影響を受けていません。何もリリースしていないのにモバイルのラボスコアが下がったなら、これが原因として考えられます。 PageSpeed Insights (PSI)とそのAPIは、[2025年10月20日にLighthouse 13.0へ移行しました](https://developers.google.com/speed/docs/insights/release_notes)。バージョンによって表示される診断項目が変わることがあるため、結果ごとにLighthouseのバージョンを記録してください。実際のユーザーを継続的に監視するには、Googleは[CrUX APIまたはCrUX History API](https://developers.google.com/speed/docs/insights/v5/get-started)を推奨しています。GoogleはPSI APIにCrUXのフィールドデータを含めるのをやめる予定です。 ## モバイルフレンドリーテストAPIの代わりはある? 旧モバイルフレンドリーテストAPIは、ツールと一緒に終了しました。**PageSpeed Insights API**でモバイルのLighthouse測定を自動化することはできますが、以前のモバイルフレンドリーの合否は再現できません。レイアウトと操作のチェックは引き続き必要です。 次のリクエストは、モバイルのパフォーマンス、ユーザー補助、SEOの診断を要求します。例のURLを、テストしたい公開ページに置き換えてください。 ``` curl --get \ 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \ --data-urlencode 'url=https://example.com/' \ --data-urlencode 'strategy=mobile' \ --data-urlencode 'category=performance' \ --data-urlencode 'category=accessibility' \ --data-urlencode 'category=seo' ``` Googleの[スタートガイド](https://developers.google.com/speed/docs/insights/v5/get-started)では、キーなしでAPIを試すことが認められており、自動で頻繁にリクエストする場合はキーの使用が推奨されています。まとめて実行する予定を組む前に、プロジェクトの現在の割り当てを確認してください。HTTP 429が返ってきた場合は、テストしたページの結果として扱わず、割り当てを調べてください。パラメータとレスポンスのフィールドは[APIリファレンス](https://developers.google.com/speed/docs/insights/v5/reference/pagespeedapi/runpagespeed)に記載されています。 カテゴリごとのスコアは`lighthouseResult.categories`、個々の結果は`lighthouseResult.audits`で読みます。スコアは0から1の尺度で、0.92は100点中92点にあたります。後で比較するときに測定内容がわかるよう、テストしたURLと一緒に`fetchTime`と`lighthouseVersion`を保存してください。レスポンスを監査結果として扱う前に、HTTPエラーと`runtimeError`を処理してください。 フィールドのパフォーマンスには、[CrUX API](https://developer.chrome.com/docs/crux/api)または[CrUX History API](https://developer.chrome.com/docs/crux/history-api)を使います。URLによっては実際のユーザーのデータが足りないことがあります。その状態は結果が悪いこととは分けて扱い、ラボのスコアをフィールドのCore Web Vitals合格として報告しないでください。 ## Lighthouseをローカルで実行する LighthouseはChrome DevToolsに組み込まれています。ページを開いて右クリックし、「検証」を選び、**Lighthouse**パネルを開いて**モバイル**を選択し、「レポートを生成」をクリックします。Lighthouseは[インストール済みのChromeで動作し、結果をリモートのサーバーに送ることはありません](https://github.com/GoogleChrome/lighthouse)。そのため、PSIが届かないステージング環境やパスワードで保護されたビルドも監査できます。 モバイルのプリセットは当て推量ではありません。Lighthouseは[CPUを4倍遅くする係数](https://github.com/GoogleChrome/lighthouse/blob/main/docs/throttling.md)をかけてパソコンのCPUをミドルクラスのスマートフォン並みに落とし、さらに4G接続の下位4分の1に相当する「Slow 4G」のネットワークプリセットを加えます。デバイスのエミュレーションには、Lighthouse自身の`constants.js`によると、[412×823のビューポートとデバイススケール係数1.75](https://github.com/GoogleChrome/lighthouse/blob/main/core/config/constants.js)のMoto G Powerのプロファイルが使われ、モバイルとタッチが有効になります(この記事の以前の版では2.625と記載していましたが、それはLighthouseが廃止した旧Moto G4プロファイルのスケール係数で、現在の値ではありません)。 [Lighthouse 13では、多くのパフォーマンス監査がDevToolsに合わせたインサイトに置き換えられ](https://developer.chrome.com/blog/lighthouse-13-0)、`unsized-images`と`non-composited-animations`は診断項目として残りました。以前のフォントサイズの監査も削除されています。診断項目がなくなったからといって、読めない文字が許されるわけではありません。実際のページの文字をスマートフォンで確認してください。 ## Chrome DevToolsのデバイスエミュレーションの手順 スコアは速さを教えてくれます。エミュレーションは、ページが使えるかどうかを教えてくれます。両方行いましょう。 1. Chromeでページを開き、「検証」のショートカットを押して、**デバイスツールバー**を切り替えます。 2. まず幅の狭いビューポートを選びます。360×800と390×844で試してから、タブレットの幅まで段階的に広げます。 3. スロットリングを**Mid-tier mobile**に設定するか、Lighthouseのプロファイルに合わせてSlow 4GとCPU 4倍を手動で適用します。 4. 横向きに回転させます。それぞれの向きで、メインのナビゲーション、フォーム、購入手続きまたは問い合わせのステップを開きます。 5. サイズを変えながらElementsパネルを見て、どのコンテナがはみ出しているかを見つけます。 スコアでは決して見つからず、エミュレーションで見つかるもの: - 隣の要素に詰め込まれた小さなタップ対象。[Lighthouseのタップ対象の監査](https://developer.chrome.com/docs/lighthouse/seo/tap-targets)が扱うケースも含みます - 固定幅の表、埋め込み、大きすぎる画像による横方向のはみ出し - 縦の短い画面でビューポートの半分を占める固定ヘッダーやCookieバナー - 閉じるボタンが画面外に押し出されたモーダル - フォーカスしたときに間違ったキーボードが出たり、拡大されたりする入力欄 押しやすいタッチ操作のためには、レイアウトが許す範囲で48×48 CSSピクセルを目安にしてください。Lighthouseの文書化されたルールは、対象の大きさと近くの対象との重なりの両方を考慮しており、小さな要素をすべて不合格にするわけではありません。別の基準である[WCAG 2.2 AAのターゲットサイズの達成基準](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html)は、間隔などの例外つきで24×24 CSSピクセルを使います。どちらも、Googleのランキングに共通する基準値ではありません。 限界も知っておきましょう。エミュレーションは、パソコンのブラウザのサイズを変え、遅いCPUを擬似的に再現するだけです。実際のタッチの遅延、iOSのSafariのくせ、親指の届く範囲、発熱で性能が落ちたミドルクラスのAndroidが重いスクリプトをどう処理するかは再現できません。どの監査も、最後は実機のスマートフォンで締めくくってください。 ## Search ConsoleでCore Web Vitalsのモバイルデータを読む 以前のモバイルユーザビリティレポートはなくなりました。実際のユーザーのパフォーマンスにはSearch ConsoleのCore Web Vitalsレポートを使い、レイアウトと操作は別に確認します。 [Search Console](https://search.google.com/search-console)を開き、「ウェブに関する主な指標」に進んで、モバイルのレポートを確認します。Googleは[概要をデバイス別に分け、似た体験を提供するURLをグループにまとめ、各グループに最も成績の悪い指標のステータスを割り当てます](https://support.google.com/webmasters/answer/9205520)。つまり、あるテンプレートで指標が1つ悪いだけで、そのテンプレートのURLがすべて「不良」になります。 私たちの読み方: - モバイルのグラフの横にある**レポートを開く**をクリックし、「不良」「改善が必要」「良好」のタブを切り替えます。 - 「URLが良好と見なされない理由」の表を読みます。不合格の指標と、超えた基準値が示されます。 - URLではなくテンプレートを直します。ステータスがグループ単位なので、テンプレートを1つ直せば多くのページが動きます。 - 修正をリリースしたら**トラッキングを開始**を使います。Googleは[28日間のモニタリングを行い、期間中ずっと問題が出なかった場合にだけ修正済みとします](https://support.google.com/webmasters/answer/9205520)。 注意点が2つあります。データは28日間の移動集計なので、火曜日にリリースした修正が水曜日に反映されることはありません。また、Googleははっきりと[PageSpeed InsightsのデータはCore Web Vitalsレポートと異なる場合がある](https://support.google.com/webmasters/answer/9205520)と述べています。一方は1つのデバイスプロファイルでのラボ測定で、もう一方は数千件の実際のセッションだからです。両者が食い違うときはフィールドデータを信頼し、ラボ測定で原因を探します。[ラボとフィールドの違いはweb.devで詳しく解説されています](https://web.dev/articles/lab-and-field-data-differences)。同じ指標は、私たちの[ウェブサイト最適化](https://www.strataigize.com/ja/services/website-optimization/)の進め方にも組み込まれています。 ## よくあるモバイルの不具合と直し方 上記のツールが見つけるための不具合と、それぞれに使われる基準値やルールです。 | 不具合 | 検出するツール | 基準値またはルール | 直し方 | | --- | --- | --- | --- | | viewportのmetaタグがない、または設定が誤っている | DevToolsのエミュレーション、Bingのテスト | パソコン用のレイアウトがスマートフォンに押し込まれる | ``を追加する | | LCPのメイン画像が遅い | PSIのフィールドとラボ、Search Console | LCPはp75で2.5秒以下 | 圧縮し、最新の形式で配信し、LCP要素をプリロードし、遅延読み込みを外す | | サイズ指定のない画像や埋め込み | Lighthouseの`unsized-images`診断 | CLSはp75で0.1以下 | すべてのメディア要素に幅と高さ、またはaspect-ratioを指定する | | 重いサードパーティのJavaScript | ブロッキング処理にはLighthouse、INPにはCrUXまたはリアルユーザー監視 | フィールドのINPはp75で200ミリ秒以下が良好 | 長いタスクを分割し、同意取得と必要な機能を保ったままスクリプトを見直す | | タップ対象が小さすぎる、または近すぎる | Lighthouseのタップ対象の監査と実機での確認 | 大きさと近くの対象との重なりの両方が重要 | 操作要素を大きくして間隔を空ける。48pxが押しやすい目安 | | 画面より幅の広いコンテンツ | DevToolsのデバイスモード、Bingのテスト | 360pxのビューポートで横スクロールが出ない | 可変幅の表、メディアに`max-width: 100%`、固定ピクセルのコンテナを使わない | | 煩わしいインタースティシャル | 実機での手動確認 | 読み込み時にコンテンツが隠れる | 全画面のポップアップを遅らせる、小さくする、または削除する | | 遅れて読み込まれるフォントや差し込まれるバナー | Search ConsoleのCLSのグループ | p75のCLS | フォントをプリロードし、バナーや広告の場所をあらかじめ確保する | どのツールが何を検出するかに注目してください。1つのチェックツールですべてを網羅できるものはありません。だからこそ、以前の合否のバッジだけでは決して十分ではなかったのです。 ## 私たちが行う監査の手順 自社サイトとクライアントのサイトで使っている順番です。 1. **URLは1つではなく3つ選びます。** ホームページ、主要なサービスまたは製品ページ、ブログ記事です。テンプレートごとに不具合の出方が違います。 2. **最初にSearch Console。** ウェブに関する主な指標のモバイル表示で、どのURLグループが「不良」または「改善が必要」になっているか、どの指標が挙がっているかを書き留めます。実際のユーザーのデータなので、これで優先順位が決まります。 3. **不合格のグループごとに1つのURLをPSIで測定します。** フィールドデータとラボデータを比べます。フィールドが「不良」でラボは問題なしなら、サードパーティのスクリプト、ログイン後の状態、遅いオリジンサーバーなど、きれいなラボ測定では見えないものを探します。 4. **同じ3つのURLをローカルのLighthouseで測定します。** モバイルのプリセットで、タップ対象と`unsized-images`の診断、コントラストの問題についてはユーザー補助のパネルを読みます。 5. **DevToolsのデバイスモードで360×800。** ナビゲーション、フォーム、主要なコンバージョンのステップを開き、回転させて、はみ出しや隠れたコンテンツを探します。 6. **BingのMobile Friendliness Test**を同じURLで実行し、ビューポート、幅、読みやすさ、タップの間隔について2つ目のクローラーの判定を得ます。 7. **実機のスマートフォンを1台。できればミドルクラスのAndroid。** オフィスのWi-Fiではなくモバイル回線で読み込み、コンバージョンの操作を最初から最後まで行います。 8. **テンプレートの修正をリリースし、Search Consoleでトラッキングを開始します。** 検証が完了するまで28日かかると見込んでください。 ### フィールドデータとラボデータが食い違う理由 Googleは[PageSpeed InsightsのデータはCore Web Vitalsレポートと異なる場合がある](https://support.google.com/webmasters/answer/9205520)と明言しています。ラボデータは1つのデバイスプロファイルでの1回のシミュレーションです。フィールドデータは、実際のChromeユーザーの28日間の移動集計です。[web.devのラボデータとフィールドデータのガイド](https://web.dev/articles/lab-and-field-data-differences)は、よくある原因として次を挙げています。実際の端末と回線はラボよりばらつきが大きいこと、サードパーティのスクリプトは実際のユーザーに対して違う動きをすること、キャッシュとバックフォワードキャッシュが再訪問を変えること、CrUXは十分なトラフィックのあるURLしか報告しないことです。食い違うときは、フィールドデータを判定として、ラボ測定を診断として扱います。 サイトを見直すときは、まずSearch Consoleのフィールドデータを確認し、次にPSIとLighthouseで要素やスクリプトを特定します。Google自身の最適化ガイドが手引きになります。 - LCPが遅い: [Largest Contentful Paintを最適化する](https://web.dev/articles/optimize-lcp)。メイン画像を圧縮し、最新の形式で配信し、LCP要素をプリロードし、遅延読み込みにしないこと。 - INPが高い: [Interaction to Next Paintを最適化する](https://web.dev/articles/optimize-inp)。長いタスクを分割し、メインスレッドをブロックするサードパーティのJavaScriptを遅らせるか削除すること。 - CLSが高い: [Cumulative Layout Shiftを最適化する](https://web.dev/articles/optimize-cls)。画像と埋め込みに幅、高さ、またはaspect-ratioを指定し、読み込み時にレイアウトがずれないようにすること。 Search Consoleは[似た体験を提供するURLをグループにまとめ、各グループに最も成績の悪い指標のステータスを割り当てます](https://support.google.com/webmasters/answer/9205520)。共通のカードコンポーネントで画像サイズを指定するといった、テンプレートの修正1つで多くのURLが一度に動くことがあります。リリース後は**トラッキングを開始**を使い、Googleが問題を修正済みとするまで28日間の期間をすべて待ってください。 テーマの変更、プラグインやアプリの導入、タグマネージャーのあらゆる公開の後には、この8つの手順を繰り返し、さらに四半期に一度の定期チェックも行ってください。サードパーティのスクリプトは、[GoogleのINPのガイダンス](https://web.dev/articles/optimize-inp)でINPのリスクとして記載されています。手順3でフィールドデータときれいなラボ測定を比べるのはそのためです。このモバイルチェックに関わるクロール、インデックス、ページ上の施策については、[検索エンジン最適化](https://www.strataigize.com/ja/services/website-optimization/search-engine-optimization/)のサービスをご覧ください。 ## WordPressやShopifyを使っている場合 どちらのプラットフォームも、コードではなく設定でほとんどのことができます。 - 採用を決める前に360pxで試した、レスポンシブなテーマ - LCPの画像以外はすべてネイティブの遅延読み込み - CSS(カスケーディングスタイルシート)で縮小したパソコン用の画像ではなく、正しいサイズで配信する最新の画像形式 - Shopify Online Store 2.0のテンプレートと、セクション単位での画像サイズ指定 - インストール済みのアプリとプラグインの監査。それぞれが表示をブロックするJavaScriptを追加することが多いためです テーマやアプリを変えるたびに、Lighthouseを実行し直してください。モバイルのスコアが気づかないうちに下がるのは、まさにそこです。テーマそのものが限界なら、パフォーマンスとSEOを最初から組み込んだ最新のフレームワークで作り直すのが解決策で、それを実現するのが私たちの[ウェブサイト開発サービス](https://www.strataigize.com/services/development-services/website-development/)です。 ## よくある質問 ### Googleのテストがなくなった今、モバイルフレンドリーかどうかはどう確認すればよいですか? Chrome DevToolsのLighthouseをモバイルのプリセットで実行し、PageSpeed Insightsの「モバイル」タブを確認し、Search ConsoleのCore Web Vitalsのモバイルレポートを読み、最後に実機のスマートフォンで確かめます。合否の判定がほしい場合は、BingのMobile Friendliness Testが今も出してくれます。 ### モバイルフレンドリーとレスポンシブの違いは何ですか? モバイルフレンドリーとは、スマートフォンでページが使えることを意味します。レスポンシブデザインは、可変のレイアウトとCSSのメディアクエリで、同じページをさまざまなビューポートに合わせます。Googleは[保守が簡単なレスポンシブデザインを推奨していますが](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing)、動的な配信やモバイル用の別URLにも対応しています。 ### モバイル専用のサイトは別に必要ですか? いいえ。レスポンシブなURLが1つなら保守が簡単で、重複コンテンツの扱いも不要になり、SEOと[生成エンジン最適化](https://www.strataigize.com/ja/insights/what-is-generative-engine-optimization/)に向けたシグナルも1つにまとまります。 ### Googleはモバイルフレンドリーでないサイトにペナルティを科しますか? コンテンツへのアクセスとユーザー体験は分けて確認してください。インデックス登録のために、Googleはモバイルのコンテンツにアクセスしてレンダリングできる必要があります。Core Web Vitalsはランキングに使われますが、[ページエクスペリエンスが十分でなくても、Googleは関連性の高いコンテンツを探します](https://developers.google.com/search/docs/appearance/page-experience)。モバイルのスコアが悪いことだけでは、インデックスからの削除、ペナルティ、特定の順位低下の証明にはなりません。 ### PageSpeed InsightsとSearch Consoleの結果が食い違うのはなぜですか? Googleは、両者が異なる場合があると述べています。PSIのラボデータは、1つのデバイスプロファイルでの1回のシミュレーションです。Search Consoleは、URLグループ全体について、実際のChromeユーザーの28日間の移動集計を報告します。[GoogleのCore Web Vitalsレポートのドキュメント](https://support.google.com/webmasters/answer/9205520)と[web.devのラボとフィールドの記事](https://web.dev/articles/lab-and-field-data-differences)はどちらも、フィールドデータを判定、ラボデータを診断として扱うよう説明しています。 ## 1つのバッジが4つのツールに置き換わった 合否のバッジはなくなり、戻ってくることはありません。代わりに登場したものの方が優れています。実際のユーザーのフィールド測定、ステージング環境でも実行できるラボ監査、レイアウトのためのビューポートのエミュレーション、そしてBingによる2つ目のクローラーの判定です。この4つを軸にプロセスを組み、Search Consoleが示す実際のユーザーの体験で優先順位を決め、個々のURLではなくテンプレートを直しましょう。 私たちはバンクーバーを拠点に、これを[ウェブサイト最適化](https://www.strataigize.com/ja/services/website-optimization/)として提供しています。モバイルのパフォーマンスが順位やコンバージョンを損なっているなら、まずは[グロース監査](https://www.strataigize.com/ja/audit/)から始めてください。 著者 **Ian McGavin** 次のステップ トラフィックは十分なのにスマホでのコンバージョンが弱い場合に。ページがそもそもスマホ向けに表示されているかを20秒で確認できます。 [ページをテストする →](https://www.strataigize.com/tools/mobile-friendly-test/) お問い合わせ ### それを運用するチームと話す どこを見るべきか教えてください。24時間以内に着手点をお返事します。価値が見えるまで売り込みはありません。 [Googleで優先ソースとして追加](https://www.google.com/preferences/source?q=strataigize.com) 関連する当社記事をより多く検索体験に表示する、無料のGoogle設定です。いつでも変更できます。 [サイトとCROの全記事 →](https://www.strataigize.com/ja/insights/topics/cro-lifecycle/) ## 私たちにお任せください 無料の30分相談をご予約ください。価値を確認するまでピッチはありません。 [グロース相談を予約 →](https://www.strataigize.com/ja/audit/) [評価 **5.0** （Clutch）](https://clutch.co/profile/strataigize-marketing)