google mobile friendly testの廃止後、モバイル対応をどのように確認するか？

Google は 2023 年 12 月に google mobile friendly test と Search Console の「モバイル ユーザビリティ」レポートを廃止しました。従来の「1 回のテストでモバイル対応かどうかを判定する」入口がなくなったからといって、モバイル対応がインデックス登録やランキングに影響しなくなったわけではありません。Google は引き続き主に Smartphone Googlebot を使用してウェブページをクロールし、モバイル版のコンテンツをインデックス登録と評価の基準としています。

本当に代替すべきなのは、緑色の「合格」マークではなく、次の 3 つの判断です。Google がモバイルページをクロールしてレンダリングできるか、実際のモバイルネットワーク環境でユーザーが正常に利用できるか、ページの速度とレイアウトの安定性が体験を損なっていないか。単一のツールでこの 3 点をカバーすることはできません。より確実な方法は、URL 検査、PageSpeed Insights、実機検証を組み合わせて利用することです。

まず URL 検査で確認：Google に表示されるページは正常か

Google Search Console の「URL 検査」にアクセスし、完全な URL を入力して、まずインデックス登録済みのバージョンを確認します。ここで確認すべきなのは、自分のパソコンでページを開けるかどうかではなく、Google が直近でクロールしたページがインデックス登録可能か、想定どおりの正規ページが選択されているか、また Smartphone Googlebot によってクロールされているかです。

ページを変更した直後で再クロールされていない場合や、Google の読み取り結果がブラウザと異なると疑われる場合は、「公開 URL をテスト」を使用できます。クロールとレンダリングの結果を重点的に確認してください。スクリーンショットに空白領域、メインコンテンツの欠落、ポップアップによる遮蔽、スタイル崩れ、エラーが表示される場合、問題は通常「画面サイズ」ではなく、リソースの読み込み、フロントエンドのレンダリング、またはアクセス制限にあります。

• JavaScript への依存：ファーストビューのメインコンテンツ、製品仕様、言語切替コンテンツが完全にスクリプトによる非同期読み込みに依存している場合、Google がレンダリング後に実際にこれらのコンテンツを取得できることを確認する必要があります。
• リソースのアクセス可能性：CSS、JavaScript、画像 CDN、フォントファイルが robots.txt、WAF、地域制限、ログイン認証によってブロックされると、Googlebot は不完全なページを取得することになります。
• レスポンシブ表示の一貫性：デスクトップ版とモバイル版で、CSS による非表示のために、重要な製品情報、本文、内部リンク、構造化データが失われないようにしてください。
• 異常なステータスコード：モバイルからのアクセスが誤ってリダイレクトされたり、4xx/5xx が返されたり、無関係なページに誘導されたりすると、正常なクロールに影響します。

URL 検査は「検索エンジンが閲覧できるか」という問いに適していますが、速度テストツールではなく、ユーザー操作テストの代わりにもなりません。検査結果が正常であっても、インデックス登録の経路に明らかな障害がないことを示すにすぎません。

PageSpeed Insights でモバイルのパフォーマンスとレイアウトの問題を把握する

PageSpeed Insights（PSI）は、日常的な確認の入口として使用すべきです。URL を入力した後、「実際のユーザーデータ」と Lighthouse のラボデータを区別して確認してください。前者は条件を満たす Chrome ユーザー エクスペリエンス データセットに基づき、すでに発生したアクセスでの体験を反映します。後者はシミュレートされたモバイル環境で実行され、現在のページで再現可能なパフォーマンス問題の特定に適しています。

モバイルでは特に、Core Web Vitals の 3 指標に注目すべきです。LCP は主要コンテンツの表示速度、INP はクリック、メニュー展開、フォーム送信などの操作応答、CLS はページ読み込み中に要素がずれるかどうかを示します。これらは「モバイル対応」のすべてではありませんが、ファーストビューの大きな画像が圧縮されていない、サードパーティのトラッキングスクリプトが多すぎる、Cookie バナーがコンテンツを圧迫する、画像や埋め込みコンテンツのサイズが確保されていないなど、問い合わせや閲覧に影響する問題を明らかにすることがよくあります。

PSI の診断提案は、ページの実際の機能に応じて判断すべきであり、機械的に満点を追求するべきではありません。貿易サイトでよく見られる多言語スクリプト、カスタマーサポートツール、フォーム検証、地図、動画はいずれも読み込みコストを増加させます。より価値のある対応順序は、まずファーストビューの重要コンテンツと問い合わせ導線が利用可能であることを確保し、次に画像を圧縮して非重要スクリプトを遅延読み込みし、最後に不要なサードパーティコンポーネントを削除すべきかを評価することです。

ブラウザのデバイスモードは初期確認に限られ、実機テストは依然として省略できない

Chrome DevTools のデバイスツールバーでは、画面幅、ピクセル密度、ネットワーク速度制限をすばやく切り替えられ、リニューアル時のブレークポイント確認に適しています。ナビゲーションが正しく折りたたまれるか、表が横方向にはみ出さないか、ボタンが切れていないか、固定された下部の連絡先情報がフォームを覆っていないかを確認できます。利点は効率の高さですが、異なる OS のブラウザ、キーボードの表示、権限ポップアップ、実際のネットワーク変動を完全に再現できないという制約があります。

問い合わせ、注文、資料ダウンロードに関わるページでは、少なくとも一般的なスマートフォンブラウザで完全な経路テストを実施する必要があります。検索のランディングページから入り、言語を切り替え、製品詳細を開き、WhatsApp、メール、フォームをクリックし、送信後に成功メッセージとメール通知が正常かを確認します。多くのページは見た目には「対応」していても、国番号の入力欄で数字キーボードを表示できない、認証コードがフローティングボタンに隠れる、添付ファイルのアップロードに失敗する、といった問題があります。この種の問題は、従来の mobile friendly test では自動的に検出されません。

「レスポンシブデザイン」を「モバイル対応」と誤認しない

レスポンシブ CSS が解決するのは、画面に応じてレイアウトを変化させる問題であり、モバイル体験を自動的に解決するものではありません。よくあるリスクには、デスクトップ用の大きな画像をそのまま縮小してファーストビューの読み込みが遅くなること、製品仕様表がスマートフォンで読みにくいこと、メニュー階層が深すぎること、小さな文字と密集したリンクによる誤タップ、ポップアップや広告が主要コンテンツを覆うこと、モバイル版に過剰なアニメーションや自動再生動画が残っていることなどがあります。

Google の自然検索流入に依存するページでは、モバイル版とデスクトップ版のコンテンツシグナルが一致しているかも確認する必要があります。モバイル版を「簡潔」にするために製品型番、用途説明、FAQ、パンくずリスト、関連製品リンクを削除すると、Google がモバイル版を使用してインデックスを作成する際に読み取れる情報も減少します。正しい方法は情報を単純に隠すことではなく、折りたたみセクション、アンカー ナビゲーション、短い段落、横スクロール可能な表を通じて読みやすさを改善しつつ、クロール可能な重要コンテンツを保持することです。

インデックス登録の異常後に対処するのではなく、確認を公開プロセスに組み込む

テーマの変更、ナビゲーションの改修、マーケティングスクリプトの導入、多言語ページの追加、CDN の調整を行うたびに、トップページ、主要製品ページ、コンテンツページ、フォームのランディングページを抽出して確認すべきです。まずブラウザのデバイスモードでレイアウトを確認し、次に PSI でモバイルのパフォーマンスとレイアウトシフトを確認し、最後に Search Console で重要な URL の公開 URL テストを実施します。ページがすでにインデックス登録されているにもかかわらず、トラフィックや表示に異常がある場合は、Search Console の「ページのインデックス登録」ステータス、クロール日時、正規ページ情報を組み合わせて問題の範囲を判断します。

google mobile friendly test の廃止後、チェック作業は一度限りの「合格/不合格」から継続的な検証へと変わりました。運用において最も重要なのは、完全に同じ代替ボタンを探すことではなく、レンダリング、パフォーマンス、コンバージョン経路という 3 種類の問題を区別することです。Google が見られない場合は、まずクロールとリソースを処理します。ページの表示が遅い場合は、まずファーストビューとスクリプトを処理します。ユーザーが操作を完了できない場合は、実機での手順に戻って項目ごとに修正します。