レスポンシブデザインとは：SEOとモバイル対応の確かめ方

この記事の要点：

• レスポンシブデザインとは、すべての端末に同じURL・同じHTMLを返し、CSSで画面の幅に合わせて表示を変える作り方です。
• SEOのために必須ではありませんが、Googleは「最も実装と管理がしやすい」としてこの作り方を勧めています。レスポンシブにしたこと自体で順位が上がるわけではなく、大切なのはスマートフォンで内容がそろい、読みやすいことです。
• 基本は3つです。viewportのmetaタグ、画面の幅で切り替えるCSS（メディアクエリ）、幅に合わせて縮む画像と表です。
• モバイルフレンドリーテストは2023年12月に終了しました。今は、開発者ツールで幅を変えて見る、横スクロールの原因を探す、Lighthouse・URL検査・実機で確かめる、という手順で点検します。
• 別々のURL（例：m.example.com）からレスポンシブに移るときは、スマートフォン用のURLを1対1で301転送し、関連付けのタグを外します。

レスポンシブデザインとは：SEOに必要かの結論

レスポンシブデザイン（レスポンシブ ウェブデザイン）とは、パソコンでもスマートフォンでも同じURLで同じHTMLを返し、CSSで画面の幅に合わせて並び方や大きさを変える作り方です。たとえば、パソコンでは横に3列並ぶ記事の一覧が、スマートフォンでは縦に1列になります。

SEOに必要かという問いへの答えは、「必須ではないが、特別な理由が無ければ選ぶのがよい」です。Googleは、スマートフォン向けのサイトの作り方として、レスポンシブ、動的な配信、別々のURLの3つをどれもサポートしています。そのうえで、レスポンシブを「最も実装と管理がしやすい」方法として勧めています。

一方で、レスポンシブにしたこと自体が順位を押し上げるわけではありません。Googleはページのスマートフォン版の内容をもとにインデックスに登録します（モバイルファーストインデックス）。問われるのは、スマートフォンで見たときに内容がそろっているか、読みやすく操作しやすいかです。レスポンシブは、それを少ない手間で保ちやすい作り方だと考えるのが正確です。

Googleがレスポンシブを勧める理由と、ほかの作り方との違い

3つの作り方は、URLとHTMLを端末ごとに分けるかどうかで違います。

Googleの説明から読み取れる、レスポンシブの利点は次のとおりです。

• 内容の食い違いが起きにくい：HTMLが1つなので、スマートフォン版だけ本文や構造化データが欠ける、という問題が起きにくくなります。
• URLが1つにまとまる：共有やリンクが1つのURLに集まり、どちらを正規とするかの指定もいりません。Googleは、別々のURLが検索エンジンにも利用者にも混乱を生んできたとして、新しいサイトでは1つのURLを勧めています。
• クロールが1回で済む：同じページを端末ごとに取りに行く必要がありません。

動的な配信や別々のURLを使っているサイトが、それだけで不利になるわけではありません。ただ、どちらも内容をそろえ続ける手間がかかるため、作り直しの機会があればレスポンシブへの移行を検討する価値があります。

レスポンシブにする基本の書き方

WordPressの多くのテーマはレスポンシブに対応していますが、自作の部分や古いテンプレートでは、次の3点を確かめます。

viewportのmetaタグを入れる

viewportは、ページを表示する領域の幅の指定です。これが無いと、スマートフォンのブラウザはパソコン向けの幅でページを描き、全体を縮めて表示します。HTMLのheadに次の1行を入れます。

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

web.devの解説では、maximum-scaleやuser-scalable=noで拡大を禁じると、文字を大きくして読みたい人が困るとして、使わないよう勧めています。

メディアクエリで画面の幅ごとに切り替える

メディアクエリは、画面の幅などの条件でCSSを切り替える書き方です。まず狭い画面向けの表示を書き、広い画面で並び方を変える書き方にすると、スマートフォンで余計な指定を読まずに済みます。

/* 例：狭い画面では1列、幅が 768px 以上なら3列 */
.cards { display: grid; grid-template-columns: 1fr; gap: 16px; }
@media (min-width: 768px) {
  .cards { grid-template-columns: repeat(3, 1fr); }
}

切り替える幅（ブレークポイント）に決まった正解はありません。端末の機種に合わせるより、内容が窮屈になったり間延びしたりする幅で切り替えるほうが、新しい端末にも対応しやすくなります。

画像と表を、画面の幅からはみ出させない

/* 画像は親の幅を超えない */
img { max-width: 100%; height: auto; }

/* 幅の広い表は、表だけを横にスクロールさせる */
.table-wrap { overflow-x: auto; }

<!-- 例：端末に合った大きさの画像を選ばせる -->
<img src="hero-800.jpg"
     srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
     sizes="(min-width: 768px) 50vw, 100vw"
     width="800" height="450" alt="作業の流れを示す図">

srcsetとsizesを使うと、スマートフォンでは小さい画像、高精細の画面では大きい画像をブラウザが選びます。widthとheightを書いておくと、画像の読み込み中も場所が確保され、表示のずれ（CLS）を防げます。画像の扱いは「画像の最適化」で詳しく説明しています。

SEOで気をつけたい5つの点

レスポンシブでも、作り方によっては検索や読者に不利な状態になります。よくある点を順に確かめます。

JavaScriptで表示する内容が検索にどう扱われるかは「JavaScript SEO」で説明しています。表示の速さはスマートフォンで差が出やすいため、コアウェブバイタルの基準と改善方法もあわせて確かめます。

モバイル対応の確かめ方：モバイルフレンドリーテスト終了後の手順

Googleの「モバイル フレンドリー テスト」と、Search Consoleの「モバイル ユーザビリティ」レポートは、2023年12月1日に提供を終えました。以前のように1つの道具で「合格」を確かめる方法は無くなったため、次の順で点検します。

1. 開発者ツールで幅を変えて見る：Chromeでページを開き、デベロッパー ツールのデバイス ツールバーをオンにします。幅を少しずつ変えながら、文字が小さすぎないか、ボタンが近すぎないか、画像や表がはみ出していないかを見ます。例：幅 360px・768px・1280px のように、狭い・中くらい・広いの3つで見ると崩れを見つけやすくなります。
2. 横スクロールの原因を探す：スマートフォンで横に揺れるページは、どこかの要素が画面の幅を超えています。下のコードをConsoleに貼ると、はみ出している要素を一覧にできます。
3. Lighthouseでモバイルを選んで診断する：表示速度や、viewportの設定などの基本的な点を確かめます。診断の項目はLighthouseの版によって変わることがあります。
4. URL検査でGoogleからの見え方を確かめる：Search Consoleの「公開URLをテスト」で、スマートフォン用のGooglebotが取得した結果のスクリーンショットとHTMLを見ます。
5. 実機で操作する：メニューの開閉、フォームの入力、表のスクロールなど、開発者ツールでは分かりにくい操作を実際のスマートフォンで確かめます。

// 画面の幅を超えている要素を一覧にする（Consoleに貼り付けて実行）
const w = document.documentElement.clientWidth;
console.table([...document.querySelectorAll('body *')]
  .filter(el => el.getBoundingClientRect().right > w + 1)
  .map(el => ({ tag: el.tagName, class: el.className, right: Math.round(el.getBoundingClientRect().right) })));

一覧に出た要素のうち、いちばん外側のものが原因であることが多いです。固定の幅（例：width: 800px）、長いURLや英数字の連続、横に並んだ大きな画像などがよくある原因です。

点検のチェックリスト

新しいテンプレートを入れたときや、大きくデザインを変えたときは、次の表で一通り確かめます。

別々のURLや動的な配信から、レスポンシブに移るとき

スマートフォン用のURL（例：m.example.com）を使っているサイトがレスポンシブに移るときは、URLの変更を伴う移転と同じように扱います。

1. 対応表を作る：スマートフォン用のURLと、移った後のURLを1対1で対応させます。
2. 301で転送する：スマートフォン用のURLから、対応するURLへ恒久的な転送（301）を設定します。すべてをトップに転送すると、元のページの代わりと見なされにくくなります。書き方は301リダイレクトの書き方にあります。
3. 関連付けのタグを外す：パソコン版に書いていた rel="alternate" media="…" と、スマートフォン版のcanonicalは不要になります。
4. サイト内のリンクとサイトマップを直す：内部リンク、XMLサイトマップ、hreflang、構造化データのURLを新しいURLにそろえます。
5. 移った後に確かめる：URL検査で転送とスマートフォンでの見え方を確かめ、Search Consoleで表示回数とエラーの推移を見ます。

動的な配信からの移行では、URLは変わりません。端末ごとに返していたHTMLを1つにまとめ、Vary: User-Agentのヘッダーが不要になったら外します。まとめるときは、スマートフォン版にしか無かった内容、パソコン版にしか無かった内容の両方が残っているかを確かめます。

当サイト（seoagent.jp）でモバイルの表示を軽くした例

当サイト（seoagent.jp）では、モバイルのLighthouseの点数が85、LCPが4.1秒でした。モバイルでは大きなヒーロー画像を読み込まないようにし、800px幅の画像を追加し、画像のキャッシュの期間を延ばしました。その結果、点数は100、LCPは約1.5秒になりました。いずれもLighthouseのラボ値で、実際の利用者のデータではありません。

この例のように、レスポンシブのサイトでも、パソコン向けの大きな画像をスマートフォンにそのまま配っていると重くなります。表示を軽くするときは、本文・見出し・リンクのような内容は削らず、画像の大きさや読み込み方で調整するのが安全です。

よくある質問

レスポンシブにすれば、モバイルファーストインデックスへの対応は終わりですか？

多くの場合、内容の食い違いは起きにくくなります。ただし、CSSやJavaScriptでスマートフォンだけ内容を隠したり、読み込みを省いたりしていれば、スマートフォン版の内容が欠けます。本文・見出し・リンク・構造化データがそろっているかは確かめます。

スマートフォンで一部の内容をアコーディオンで畳んでも大丈夫ですか？

畳んだ内容がHTMLに含まれていれば、Googleは読み取れます。押してから読み込む作りの場合は、読み取られない可能性があります。

パソコンからの訪問がほとんどのBtoBサイトでも、レスポンシブは必要ですか？

Googleは、どの端末からの訪問が多いかに関係なく、スマートフォン版の内容でインデックスに登録します。スマートフォンで内容がそろい、読める状態にしておく必要があります。

使っているWordPressのテーマがレスポンシブに対応しているか、どう確かめますか？

テーマの説明に対応の記載があるかを見たうえで、ページのソースにviewportのmetaタグがあるか、開発者ツールで幅を狭めたときに並び方が変わるかを確かめます。自作した部分やプラグインが出す部分だけ崩れることもあるため、主な種類のページを一通り見ます。

Lighthouseの点数が低いと、順位は下がりますか？

Googleが検索の順位付けで使うと説明しているのは、実際の利用者のデータにもとづくコアウェブバイタルで、Lighthouseのラボでの点数ではありません。点数は改善点を探す手がかりとして使い、実際の利用者のデータはSearch Consoleの「ウェブに関する主な指標」で確かめます。

SEOAGENTでできること

SEOAGENTでは、実際の利用者のデータ（CrUX）による判定と計測ツールの点数を分けて、表示速度を確認できます。公開後の検索データも記事ごとに確認できます。テンプレートやCSSの修正そのものは、サイトの側で行います。

• AI検索・表示速度の診断
• SEO分析・効果測定

レスポンシブデザインと関わるテクニカルSEOの記事は「テクニカルSEOの記事一覧」にまとめています。

参考情報

• Google 検索セントラル：モバイル ファースト インデックスに関するおすすめの方法
• Google 検索セントラル：Google 検索結果におけるページ エクスペリエンスについて
• Google 検索セントラル：煩わしいインタースティシャルやダイアログを避ける
• web.dev：レスポンシブ ウェブデザインの基本
• Search Console ヘルプ：URL 検査ツール