意味と範囲
Googleは、モバイルファーストのシステムで、インデックス登録と検索順位の決定にコンテンツのモバイル版を使います。レスポンシブデザインなら、同じURLとHTMLを配信しながらレイアウトを切り替えられます。ただし、重要なテキスト、title、メタデータ、画像、代替テキスト、構造化データを残す実装は必要です。デスクトップ幅では問題なく見えるページでも、実際のモバイル操作で失敗することがあります。
実務の進め方
まず、代表的なルートの一覧表を作り、幅の狭いモバイルのビューポートで確認します。強制的にズームしなくても文字が読めるか、タップ対象の大きさと間隔が十分か、横方向にはみ出していないか、主要なコンテンツが見えているか、ナビゲーションが動くか、フォームが安定しているかを見ます。次に、リソースとレンダリングをブロックする挙動を調べます。速度の症状は、サーバーのレスポンス、アセットのサイズ、ページ構造のどれからも生じ得て、直し方が異なります。
確認する点
モバイル版とデスクトップ版のHTML、canonicalタグ、robotsディレクティブ、主要なコンテンツを比べます。実際のブラウザーをモバイル幅にしてテストし、コンソールのエラー、失敗したリクエスト、操作時の状態を記録します。フィールドデータやラボのパフォーマンスデータは、取得できたかどうかの状態とあわせて使います。データがないことは合格ではなく、1つのスコアからすべてのUXの問題を診断することはできません。
限界とよくある間違い
インデックス登録に必要な情報を削った簡易版のモバイルページを作ったり、端末の思い込みだけでユーザーをリダイレクトしたりしてはいけません。レスポンシブなレイアウトだけでは、監査の全体にはなりません。役立つリリース前のチェックでは、公開上の目的、コンテンツ、技術的なシグナルが小さい画面でも保たれていることを確かめます。
実際の退行を見つけるモバイルのルートテスト
重要なテンプレートごとに、ルートを1つ選びます。ホーム、カテゴリ、商品またはサービス、記事、検索または絞り込み、フォームです。幅の狭いビューポートで、最初の読み込み、ナビゲーション、操作できるコントロール、戻る動線をテストします。同意画面に隠されずにH1と主要なコンテンツが見えるか、横スクロールが出ないか、タップするコントロールが重なっていないか、画像がスペースを確保しているかを記録します。これは、1枚のレスポンシブのスクリーンショットではなく、ルートの一覧表による確認です。
次に、モバイルとデスクトップのソースの項目を比べます。最終URL、HTTPステータス、canonical、robotsディレクティブ、title、主要な見出し、表示される本文、画像のalt属性、構造化データです。レイアウトは見た目が整っていても、モバイルのレスポンスで商品説明が抜けていたり、robotsのmetaタグが違っていたりすることがあります。検索上の目的がその情報に依存するページでは、そうした同等性の変化を、リリースを止める問題として扱います。
<meta name="viewport" content="width=device-width, initial-scale=1">実際のモバイルのビューポートで、ブラウザーのコンソールの出力と、失敗したネットワークリクエストを確認します。ブロックされたフォント、画像、APIリクエスト、レンダリングの例外は、デスクトップのキャッシュでは表れないことがあります。速度については、オリジンのレスポンスの遅さと、画像やスクリプトの過大なサイズ、レイアウトの処理を区別します。Lighthouseの1つのスコアでは、担当者も正しい修正も特定できません。フィールドデータが得られない場合や一部だけの場合は、そのように書きます。
運用上の強い必要がなく、canonical、alternate、コンテンツの同等性のロジックを維持できない限り、モバイル専用の別URLは避けます。レスポンシブデザインなら、1つのURLがすべての端末に対応するため、通常はこのリスクが減ります。それでもテストは必要です。コンポーネントライブラリ、同意の流れ、キャッシュ層、ナビゲーションのテンプレートを変更した後は、同じ一覧表で確認をやり直します。
フォームや同意のインターフェースもテストに含めます。読者がコンテンツにたどり着く前に、ルートを塞いでしまうことがあるためです。フォーカスの順序、エラーメッセージ、キーボード操作、ズームの挙動、スクリプトの失敗で送信の経路が隠れないかを確認します。端末の幅とブラウザーの状態を記録しておけば、別のレビュアーがモバイルの条件を再現できます。縮小したデスクトップのスクリーンショットで判断してはいけません。