モバイルフレンドリーテスト:Googleのツール終了後にサイトを確認する方法

要点: Googleは2023年12月1日に、モバイルフレンドリーテスト、Mobile-Friendly Test API、Search Consoleのモバイルユーザビリティレポートを終了しました。モバイルの重要性が下がったわけではありません。Googleはスマートフォン用クローラーのみでサイトをクロール・インデックスしており、スマートフォンでアクセスできないコンテンツはインデックス登録されません。現在サイトをテストするには、簡易チェッカーとLighthouseで基本項目(viewportタグ、拡縮する画像、読みやすいテキスト、タップ要素)を確認し、実機でページを見て、モバイル版にもPC版と同じコンテンツがあることを確かめましょう。

長年、「モバイルフレンドリーテスト」といえば、GoogleのツールにURLを貼り付けて緑色の「ページはモバイルフレンドリーです」という表示を得ることでした。そのツールはもう存在しませんが、今も多くのガイドがリンクを張っています。この記事では、何が起きたのか、Googleがモバイルページに今何を求めているのか、今も使えるツール(無料のモバイルフレンドリーテストを含む)でどうテストするか、そして各問題の直し方を説明します。

Googleのモバイルフレンドリーテストに何が起きたのか

2023年4月のページエクスペリエンスに関する投稿で、Googleはこう発表しました。「Also starting December 1, 2023, we'll be retiring Search Console's 'Mobile Usability' report, the Mobile-Friendly Test tool and Mobile-Friendly Test API.」理由はモバイルが重要でなくなったからではありません。「Chrome の Lighthouse を含め」、モバイルユーザビリティを評価できる優れたリソースが数多く登場したためだと説明しています。

つまり2023年12月以降、モバイルフレンドリーかどうかをGoogleが公式に合否判定することはありません。サードパーティのチェッカー、Lighthouse、そして自分自身でのテストがその穴を埋めます。

モバイルが今もインデックスを左右する理由

終了したツールよりも重要な発表が2つあります。

1. モバイルファーストインデックスは完了した。 2023年10月、Googleは「the trek to Mobile First Indexing is now complete」と書きました(発表)。ベストプラクティスのページではその意味が定義されています。「Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking.」
2. 検索でのPCクロールは終了した。 2024年6月、Googleは「After July 5, 2024, we'll crawl and index these sites with only Googlebot Smartphone」「If your site's content is not accessible at all with a mobile device, it will no longer be indexable」と述べました(発表)。

実務上の結論は、モバイル版に表示されている内容こそがGoogleにとってのあなたのページだということです。モバイルで非表示のテキスト、欠けているセクション、モバイル用テンプレートだけ異なるタイトルが、そのままインデックスされます。

ページエクスペリエンスはさらにもう一層を加えます。Googleのページエクスペリエンスのガイダンスは「Does your content display well on mobile devices?」と問いかけ、コアランキングシステムは「look to reward content that provides a good page experience」としつつ、単一のページエクスペリエンスシグナルは存在しないと強調しています。

実際の「モバイルフレンドリー」とは

公式のチェックリストはもうありませんが、Googleのドキュメントとweb.devで主要な点はカバーされています。

Googleは、レスポンシブWebデザインを「because it's the easiest design pattern to implement and maintain」として推奨しています。1つのURL、1つのHTML、適応するCSS。これで同等性の問題はほぼなくなります。

今日のモバイルフレンドリーのテスト方法

ツールごとに見える範囲が違うので、複数を併用しましょう。

1. 基本の簡易チェック。 無料のモバイルフレンドリーテストは、viewportタグ、レスポンシブ画像、favicon、ページの言語を約20秒でチェックします(詳細は後述)。
2. ChromeのLighthouse。 DevToolsからモバイル設定で実行します。Lighthouse 13(2025年10月)以降、viewportのチェックは「Optimize viewport for mobile」インサイトにあり、従来の判読可能なフォントサイズの監査は代替なしで削除されました。
3. Chrome DevToolsのデバイスモード。 幅を320pxから広げながら、横スクロールバー、要素の重なり、ボックスからはみ出すテキストを確認します。
4. 実機。 小さめのAndroidスマートフォンとiPhoneを最低1台ずつ使い、メニュー、フォーム、チェックアウトを親指で操作してみましょう。
5. Search ConsoleのURL検査。 ライブテストでは、Googlebot Smartphoneが描画したページのスクリーンショットとレンダリング後のHTMLが表示され、重要なコンテンツがあるか確認できます。
6. 実ユーザーの速度データ。 Chrome UXレポートによる、スマートフォン訪問者向けのCore Web Vitalsです。読み方はCore Web Vitalsガイドで解説しています。

Searviaのモバイルフレンドリーテストの仕組み

無料のモバイルフレンドリーテストはサイト全体の監査(38項目)を実行し、4つのモバイル項目を先頭に表示します。ドメインまたはページのアドレスを入力すると、そのページ(ドメインのみの場合はトップページ)をリダイレクトをたどりながら取得し、JavaScriptを実行せずにサーバーが返すHTMLを読み取ります。

判定について、いくつか補足します。

• viewportのチェックがWarningではなくFailになるのは、viewportタグのないページはあらゆるスマートフォンで壊れており、「少し悪い」程度ではないからです。
• faviconでは、/favicon.icoへのフォールバックは、HTMLのエラーページではなく実際のファイルが返る場合にのみ有効とみなされます。
• 言語チェックはコードの先頭2文字を表示するため、en-GBは「en」と表示されます。

完全なレポートには速度セクションも含まれます。そこのCore Web Vitalsチェックでは、Chromeの実ユーザーデータからスマートフォン訪問者の75パーセンタイルのLCP、INP、CLSを読み取ります。入力したページにChromeの十分なデータがあればそのページ、なければサイト全体の値です。

できないこともあります。スマートフォンサイズのブラウザでページを描画しないため、横方向のはみ出し、フォントサイズ、タップ要素の間隔、ポップアップは検出できません。それはLighthouse、デバイスモード、実機の役割です。チェッカーは5分でできるトリアージ、手動テストは精密検査と考えてください。

結果の読み方

• viewportがFail: 最優先で直しましょう。レイアウトが画面に収まらない限り、ページの他の要素は意味を持ちません。
• レスポンシブ画像のWarning: スマートフォンがPCサイズの画像をダウンロードしています。壊れてはいませんが、特にモバイル回線では遅くなります。
• faviconや言語のWarning: 小さく、すぐ直せる修正で、Google検索結果での見え方やスクリーンリーダーの扱いが改善します。
• 「Too few images to judge」: 中立です。画像が3枚未満では、割合はあまり意味を持ちません。

各問題の修正方法

「ページにモバイルviewportタグがありません」

1. すべてのテンプレートの<head>内に次の行を追加します。

<meta name="viewport" content="width=device-width, initial-scale=1">

1. user-scalable=noや小さいmaximum-scaleは追加しないでください。web.devは「because they can prevent the user from zooming」としてこれらを避けるよう勧めています。
2. viewportタグが1つだけであることを確認します。テーマとプラグインの両方が出力する場合があり、後のものが先のものを上書きすることがあります。
3. スマートフォンで再読み込みします。極小表示ではなく窮屈なPCレイアウトが表示されるなら、viewportは機能しており、CSSにレスポンシブ対応のルールが必要です(下記参照)。

レイアウトをレスポンシブにする

viewportタグはブラウザに画面幅を使うよう伝えるだけです。CSSの側も適応させる必要があります。

• 画像と動画にはmax-width: 100%; height: auto;を指定し、はみ出さないようにします。
• コンテナの幅は固定ピクセルではなく、柔軟な幅(パーセント、fr、min())にします。
• メディアクエリは特定のデバイス幅ではなく、デザインが崩れる箇所に追加します。web.devいわく「Design the content to fit on a small screen size first, then expand the screen until a breakpoint becomes necessary.」
• 幅の広いテーブルはスクロール可能なコンテナで囲み、ページ全体が横にスクロールしないようにします。

「N of M images use srcset」

MDNで説明されているように、複数のサイズを用意してブラウザに選ばせます。

<img
  src="/img/boots-800.jpg"
  srcset="/img/boots-480.jpg 480w, /img/boots-800.jpg 800w, /img/boots-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Brown leather hiking boots on a wet rock"
  width="800" height="600">

srcsetはファイルとその幅を列挙し、sizesは画面上で画像がどれくらいの幅になるかをブラウザに伝えます。ロゴのような固定サイズの画像にはx記述子(logo.png, logo@2x.png 2x)を使います。WordPressはエディタで挿入した画像に自動でsrcsetを追加し、多くの画像CDNはサイズを自動生成できます。widthとheightも追加して、ブラウザが領域を確保し、レイアウトがずれないようにしましょう。

「No favicon was found」

1. 正方形のアイコンを作成します。Googleは1:1の比率、8×8px以上を必須とし、48×48pxより大きいサイズを推奨しています(faviconのガイドライン)。
2. トップページのheadに追加します。

<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

1. URLは変えず、robots.txtでファイルをブロックしないようにしてください。Googleはトップページとアイコンの両方をクロールする必要があります。Googleがサポートするのはホスト名ごとに1つのfaviconです。

「The page does not declare its language」

ルート要素に言語を設定します。

<html lang="ja">

en、en-GB、pt-BR、trのような有効なBCP 47コードを使います。lang属性はスクリーンリーダーがテキストを正しく読み上げるのに役立ち、WCAGの「Language of Page」基準で必須です(MDN)。補足として、Googleはページの言語をlangではなくテキスト自体から判定するとしているため、これはランキング対策というよりアクセシビリティとブラウザ向けの修正です。

4つのチェックの先へ

基本項目に合格したら、自動チェッカーでは完全にカバーできない部分に取り組みましょう。

• コンテンツの同等性。 同じURLでモバイルとPCを比較します。本文、見出し、同じaltテキストの画像、構造化データ、タイトル、メタディスクリプション、robotsメタタグです。Googleのモバイルファーストのベストプラクティスにはこれらがすべて挙げられています。
• 遅延読み込み。 Googleは「Don't lazy-load primary content upon user interaction.」と警告しています。Googlebotは「続きを読む」をタップしたり、カルーセルをスワイプしたりしません。
• タップ要素。 ボタンとリンクは約48×48pxで、間に余白を設けます。Lighthouseは、隣接する要素と重なっている48×48pxより小さい要素にフラグを立てます。
• テキストサイズ。 ズームしなくても読める本文サイズにします。Lighthouseはもうフォントサイズを監査しないため、実機で確認しましょう。
• ポップアップ。 小さい画面でコンテンツを覆うCookieバナーやニュースレターフォームは、Googleの煩わしいインタースティシャルの問いに該当します。
• スマートフォンでの速度。 スマートフォンのCPUや回線は低速です。モバイルのフィールドデータはPCとは別に確認しましょう。

モバイル専用サイトを運用している場合

古いサイトの中には、m.example.comのような別アドレスからスマートフォンに配信したり、同じURLでスマートフォンに異なるHTMLを返したり(動的配信)しているものがあります。Googleは今も両方をサポートしていますが、同等性の維持が難しくなるため、ベストプラクティスには別URLの場合の追加ルールがあります。

• エラーステータスは両バージョンで同じにします。PCで404を返すページがモバイルで200を返してはならず、その逆も同様です。
• モバイル版ではコンテンツにURLフラグメント(#)を使わないようにします。
• robots.txtのルールを一致させ、Googlebotが両ホストで同じセクションをクロールできるようにします。
• PCページはrel="alternate"でモバイル版を指し、モバイルページはrel="canonical"でPC版を指し返します。
• hreflangは各バージョンで個別に設定する必要があります。

いずれにせよリニューアルを予定しているなら、1つのURLでのレスポンシブデザインに移行すれば、この種の問題はまとめて解消します。当社の無料チェッカーは、サーバーが自社のクローラーに返すバージョンを読み取るため、動的配信のサイトでは、スマートフォン版をLighthouseまたはURL検査で別途テストしてください。

具体例(仮想)

以下は仮想の例であり、実際のデータではありません。架空のベーカリー「Cobble & Crumb」は、2016年に手作業でコーディングしたサイトを運営しており、訪問の大半がスマートフォンからなのに注文はほとんど入りません。モバイルフレンドリーテストの結果は次のとおりです。

• モバイルviewport:Fail。viewportタグなし。
• レスポンシブ画像:14枚中1枚だけがsrcsetを使用。
• Favicon:合格。
• ページの言語:Warning。lang属性なし。

オーナーはviewportタグとlang="en"を追加してスマートフォンでサイトを開きます。テキストは通常サイズになりましたが、幅960px固定のコンテナのせいで横スクロールが発生します。開発者は固定幅をmax-width: 960px; width: 100%に置き換え、画像にmax-width: 100%を追加し、3カラムのメニューを600px未満で1カラムに積み替え、注文ボタンの高さを48pxに拡大します。商品写真には480、800、1600pxのsrcsetを付けました。2回目の実行ではviewportと言語が合格し、レスポンシブ画像も14枚中13枚で合格、Lighthouseのviewportインサイトも問題なしです。残る作業はコンテンツで、モバイルレイアウトで隠れていた営業時間をページに戻します。

30分でできるモバイルチェックリスト

1. モバイルフレンドリーテストを実行し、まずviewportタグの欠落を直します。
2. 上位5ページを実機のスマートフォンで開きます。横スクロール、小さすぎる文字、押しにくいボタンを探しましょう。
3. 同じページでLighthouseをモバイルモードで実行します。
4. ページテンプレートごとにモバイルとPCのコンテンツを比較します。
5. 大きな画像にsrcsetを、あわせてfaviconとlang属性を追加します。
6. スマートフォンのCore Web Vitalsを確認し、最も遅いテンプレートを修正します。

Searviaでモバイル対応を維持する方法

無料のモバイルフレンドリーテストは、トップページまたは入力した任意のページの基本項目を、登録不要で約20秒でチェックします。検索での見え方、クロール、AI検索への対応、速度、セキュリティにわたる他の34項目も同時に確認できます。

継続的なモニタリングには、無料のSearviaアカウントでページ速度のトラッキングが利用できます。訪問数の多いページのラボスコアとChromeの実ユーザーデータを毎週再チェックし、短縮できると見込まれる時間の順に修正を並べます。サイト監査は全ページをクロールし、タイトルの欠落、リンク切れ、薄いコンテンツなど、モバイルでもPCでも悪影響を及ぼす問題を検出します。テクニカルSEOのチェックリストの残りについては、テクニカルSEO監査ガイドをご覧ください。