モバイルファーストSEOの本質｜スマホ版で確認する8項目

モバイルファーストSEOは、スマートフォンでレイアウトが崩れないかだけを確認する施策ではありません。検索に使われるスマホ版へ必要な情報がそろい、Googleが取得でき、利用者が読んで判断し、問い合わせや購入などの目的を完了できるかを確かめる公開品質の管理です。

Googleは検索向けのクロールとインデックス登録をGooglebot Smartphoneへ集約しています。したがって、PC版を完成させてからスマホ版を簡略化する考え方ではなく、公開する同じ情報と機能をスマホ版でも取得・理解・操作できる状態に保つ必要があります。本記事では、経営者やWeb担当者が制作会社と共有できるよう、確認範囲を8項目へ固定します。

結論：モバイルファーストSEOは8項目で判定する

検索側と利用者側を分けて確認する

一つの「スマホ対応済み」という印では、問題の所在を説明できません。Googlebot SmartphoneがURLへ到達し、本文や画像、メタ情報を取得できるかという検索側の確認と、人が実機で読み、比較し、ボタンを押し、フォームを送れるかという利用者側の確認を分けます。どちらか一方だけが合格しても公開完了にはしません。

8項目を公開条件として固定する

実装方式の違いを調べたい場合は、レスポンシブとアダプティブの違いへ役割を分けます。SEO全体の仕組みはSEO対策の基本で確認し、本記事ではスマホ版の公開品質へ集中します。

項目1：スマホ用クローラがURLと資源へ到達できるか

最初にHTTP状態とインデックス制御を見る

本文の改善前に、対象URLが正常な応答を返し、意図しない転送、認証、エラーページ、noindex、X-Robots-Tagで妨げられていないかを確認します。robots.txtはクロールの制御であり、検索結果から確実に除外する方法と同じではありません。ページ単位の設定とサーバー応答を分けて記録します。

HTMLだけでなくCSS・JavaScript・画像も対象にする

本文URLへアクセスできても、CSSやJavaScript、画像ファイルが拒否されると、Googleが利用者と同じ状態を再現できない場合があります。別ホスト、CDN、モバイル専用URLを使う構成では、資源ごとのURLと応答を確認します。スマホから完全に内容へアクセスできないサイトはインデックス登録できないというGoogleの案内を、公開条件の最低線として扱います。

robotsの指定は、Googleのrobotsメタタグ仕様と照合します。複数の指定が競合するときは、より制限的なルールが適用されるため、テーマ、SEOプラグイン、サーバー設定を一か所ずつ確認してください。

項目2：PC版とスマホ版で主要内容と見出しがそろうか

見た目ではなく判断材料を比較する

同等性は、段落の位置や装飾を同じにすることではありません。サービス内容、対象者、料金や納期の条件、実績の根拠、注意事項、会社情報、問い合わせ前に必要な説明が、どちらの端末にも存在する状態です。スマホ版だけ文章や表を削ると、検索と利用者の両方から判断材料が失われます。

アコーディオンは省略と区別する

長い説明をアコーディオンやタブへ整理しても、HTML上に同じ内容があり、利用者が名称から内容を予測して開けるなら、情報の省略とは異なります。ただし、クリック後にサーバーから初めて主要本文を読み込む構成は、Googleが操作しないことを考慮して検証します。

Googleのモバイルファーストのベストプラクティスでは、主要コンテンツと明確な見出しをPC版とスマホ版で同等にするよう案内しています。差分表には「違う」だけでなく、失われる判断材料を書きます。

項目3：メタ情報と構造化データが同じ主題を示すか

title・description・canonicalをURL単位で記録する

スマホ版の画面に同じH1があっても、title要素、meta description、canonicalが別ページの値なら、検索へ伝える主題と正規URLが食い違います。PC版とスマホ版の値を並べ、公開URL、正規URL、サイトマップ掲載URLが意図どおりかを確認します。

構造化データは種類だけでなく値とURLを見る

構造化データが出力されていることだけで合格にしません。名称、画像、パンくず、記事日付、組織情報など、ページに表示される内容と一致し、内部URLが正しいかを検証します。モバイル専用URLがある場合は、その構成に適したURLを使います。

項目4：リンク・ナビゲーション・CTAが目的へつながるか

メニューの有無ではなく到達経路で見る

PC版の大きなナビゲーションがスマホ版でハンバーガーメニューへ収まること自体は問題ではありません。メニューを開ける、項目名が読める、現在地が分かる、目的ページへ移動できる、戻っても状態が壊れないという一連の動作で確認します。

CTAは押下後までを確認する

電話、メール、問い合わせ、予約、購入などのCTAは、表示されるだけでなく、リンク先と目的が一致し、固定要素やCookie通知に隠れず、押下後の画面が利用できることを確認します。フォームなら入力、エラー修正、確認、送信、完了、受付通知までが対象です。

サイト全体で問い合わせに至らない原因を分ける場合は、ホームページから問い合わせにつながらないときの確認項目へ進みます。本記事では、そのうちスマホ端末で欠ける経路だけを扱います。

項目5：画像・動画・遅延読込が取得と理解を妨げないか

画像を減らすのではなく役割を残す

モバイル表示を軽くするために、施工例、商品差、人物、図解、証拠写真などを一律に外すと、ページの理解に必要な情報まで失われます。必要な画像を選び、適切な寸法と形式で配信し、PC版と同等の説明的なALT、キャプション、周辺文脈を用意します。

遅延読込は利用者の操作に依存させない

画面外の画像を遅延して読み込むこと自体は性能改善に役立ちます。ただし、クリック、スワイプ、入力などをしないと主要コンテンツが初めて取得される実装は避けます。Googleの遅延読込ガイドに沿い、表示領域へ来た時点で読み込まれ、URL検査のレンダリング結果とHTMLで確認できる状態にします。

項目6：390pxで読み、押し、入力できるか

横幅と文字拡大で情報が失われないか

390 CSS pxの確認では、横スクロールの有無だけでなく、固定幅の表、長いURL、コード、画像、動画、モーダルが画面外へはみ出さないかを見ます。W3Cのリフロー基準では、縦スクロール型コンテンツを320 CSS px相当で情報や機能を失わず、原則として二方向スクロールなしで扱えることを示しています。表など意味上二方向の配置が必要な要素は、その要素内だけを横スクロール可能にし、ページ全体を動かさない設計にします。

タップ対象の大きさと間隔を確認する

小さなリンクや隣接ボタンは、押し間違いを起こします。W3C WCAG 2.2の対象サイズでは、原則24×24 CSS px以上、または例外条件に合う間隔を求めています。見た目のアイコン寸法だけでなく、実際に反応する領域と隣の操作対象との距離を確認します。

フォームはラベルとエラー修正まで試す

入力欄には視覚的な見出しだけでなく、項目と関連づくラベルを用意します。入力方式に適したキーボードが出るか、必須条件を送信前に理解できるか、エラー箇所と直し方が伝わるか、拡大時にメッセージが隠れないかを実機で確認します。アクセシビリティの全体像はデジタル庁の導入ガイドブックも参照します。

項目7：表示性能とレイアウト安定性を実測する

ラボ値と実利用データを混同しない

開発時の一回の測定は、問題を再現し修正するラボデータです。実際の訪問者から集めたフィールドデータは、端末、通信、地域、ページ群を含む現実の傾向です。測定元、対象URLまたはURL群、期間、端末区分を記録し、異なる条件の数値を単純比較しません。

LCP・INP・CLSを役割別に確認する

GoogleのCore Web Vitals解説では、良好な利用体験の目標としてLCP 2.5秒以内、INP 200ミリ秒未満、CLS 0.1未満を示しています。LCPは主要内容の表示、INPは操作への応答、CLSは意図しない位置ずれを見る指標です。三つを一つの総合点に置き換えず、原因となる画像、JavaScript、フォント、広告、固定要素を分けて調べます。

この数値を満たせば順位や問い合わせが必ず上がるわけではありません。内容、取得可能性、操作性を含む8項目の一部として使い、悪化したページと更新内容を対応づけて改善します。

項目8：URL検査と実機確認を一つの公開判定にする

URL検査でGoogle側の見え方を確認する

Search ConsoleのURL検査ツールでは、インデックス登録済みの情報と公開URLテストを区別します。公開URLテストで取得可否、レンダリングされた画面、読み込まれた資源、HTMLを確認し、主要な本文、画像、リンク、メタ情報が見えているかをURL単位で記録します。

実機で利用者の完了経路を通す

URL検査の成功は、実際の利用者が操作できる証明ではありません。iOSとAndroidの代表端末、または実利用構成に近い端末で、検索から流入した想定で本文を読み、メニュー、電話、地図、フォーム、確認画面、完了画面まで操作します。端末名、OS、ブラウザ、日時、通信条件を残します。

二つの結果がそろってから公開完了にする

点検は対象URLと変更点を先に固定する

全ページを毎回確認する必要はない

日常の更新で、毎回サイト全体を保存したり全URLを同じ深さで確認したりする必要はありません。まず変更したURL、共通テンプレート、部品、フォーム、計測タグを記録します。記事本文だけの変更なら対象記事と共通表示、ヘッダー改修なら代表ページ群、フォーム部品ならその部品を使う全フォームというように、影響範囲から確認URLを決めます。

変更前の基準値を少量残す

対象URLの更新日時、本文ハッシュ、HTTP状態、主要メタ情報、スクリーンショットなど、競合と差分を判断する最小限の基準を残します。本文全体や画像を何度も複製するのではなく、変更対象の記事単位で一度記録し、公開直前に再取得して差がないか照合します。

不具合を検索・表示・操作・計測へ分ける

症状の分類で担当と修正範囲を絞る

「スマホSEOが悪い」という依頼では、何を直せばよいか決まりません。取得できないなら検索・配信、情報が欠けるなら内容、崩れるなら表示、押せない・送れないなら操作、成果が記録されないなら計測というように分類します。複数の症状がある場合も、一件ずつ切り分けます。

順位だけを受入条件にしない

検索順位は競合、需要、検索意図、地域、端末などの影響を受け、改修直後に固定できる値ではありません。受入条件は、本文が取得できる、正規URLが一致する、横崩れがない、フォームが完了する、イベントが一回記録されるなど、改修者と確認者が同じ方法で再現できる状態にします。

制作会社への修正依頼は再現条件と完了条件を書く

一件の依頼に一つの症状を置く

依頼には、対象URL、端末または画面幅、OS、ブラウザ、発生日時、再現手順、現在の結果、期待する結果、関連画像を記載します。「スマホを最適化してください」ではなく、「390px幅で料金表がページ外へはみ出し、CTAが画面外へ隠れる。表の領域内だけを横スクロールにし、CTAを表示したままにする」と書きます。

受入確認の担当者と証拠を決める

修正者の完了連絡だけで閉じず、依頼者または別の確認者が同じ再現手順で確かめます。検索側はURL検査、利用者側は実機、性能は同じ測定条件、フォームは完了と通知、計測はイベント受信を証拠にします。制作依頼後の承認や変更管理は、Web制作の合意ゲートへ分けます。

WordPressではテーマ・プラグイン・本文を分けて見る

同じ不具合が複数ページにあるか確認する

記事一件だけで発生するなら本文ブロックや個別設定、複数の記事で同じ位置に出るならテンプレートや共通CSS、全ページで出るならテーマ、キャッシュ、最適化プラグイン、配信設定が候補です。対象記事を直す前に、同じ部品を使う代表ページを一件だけ比較すると、影響範囲を過不足なく決められます。

プラグイン設定は公開前後で差を確認する

キャッシュ、画像最適化、遅延読込、SEO、フォーム、同意管理の設定は、スマホ版だけのHTMLや実行順を変えることがあります。設定名、変更前後、対象ページ、キャッシュ削除の有無を記録し、一度に複数の設定を変えません。原因を再現できなくなる変更は避けます。

過剰なモバイル専用化を避ける

同じURL・同じHTMLを基本にする

Googleは、同じURLと同じHTMLを画面幅に応じて表示するレスポンシブWebデザインを、実装と保守が容易な方式として推奨しています。事業上の理由がなければ、モバイル専用URLや端末ごとの別本文を増やさず、一つの情報源から表示を調整すると差分管理を減らせます。

モバイルだけ情報を短くしない

スマホ利用者は情報を必要としていないのではなく、小さな画面で探しています。重要度の低い装飾を減らし、見出し、要約、目次、折りたたみ、表の領域スクロールで読みやすくします。料金条件、対象範囲、注意点、根拠、問い合わせ前の説明まで削らないことが原則です。

更新のたびに8項目を再確認できる台帳を作る

再確認のきっかけを決める

新規ページ、主要本文の改稿、テンプレート変更、ナビ改修、フォーム変更、画像最適化、計測タグ変更、キャッシュやCDN設定変更を再確認のきっかけにします。変更がないURLまで毎回保存せず、影響する記事・テンプレート・部品を対象として記録します。

確認者と次回確認日を残す

台帳には、対象URL、変更ID、8項目の結果、未解決事項、確認者、確認日、証拠の場所、次回確認条件を残します。外部仕様やブラウザの変化を日付で追えるため、過去の「対応済み」を永久保証として扱わずに済みます。

検索と問い合わせの計測を混同しない

Search Consoleでは検索側の変化を見る

インデックス状況、クリック、表示回数、CTR、平均掲載順位は、検索結果での変化を確認する材料です。改修日と対象URLを記録し、短期間の一日値だけで判断せず、同じ期間・同じページ・同じ端末区分で比較します。URL検査の状態とパフォーマンスレポートも別の証拠です。

アクセス解析では利用者側の経路を見る

記事閲覧、内部リンク、CTA、フォーム開始、エラー、送信完了などを分けると、スマホでどの段階が止まるかを確認できます。イベント名、発火条件、重複、同意状態、完了ページを設計する作業は、GA4のコンバージョン設計へ分けます。

30分の一次点検は10分ずつ三段階で行う

最初の10分で取得と同等性を見る

対象URLを一件に絞り、HTTP状態、robots、title、canonical、H1、主要本文、画像、内部リンクをPC版とスマホ版で比較します。欠落があれば、その時点で公開保留とし、表示調整より先に情報を戻します。

次の10分で実機の完了経路を通す

390px相当と実機で、目次、メニュー、表、画像、CTA、フォームを操作します。ページ全体の横崩れ、固定要素の重なり、誤タップ、入力エラー、完了結果を記録します。

最後の10分でURL検査と依頼票を残す

公開URLテスト、レンダリング、主要HTMLと資源を確認し、実機結果と合わせて合否を決めます。不合格は対象URLと一つの症状に分け、担当者、期限、受入条件を入れた依頼票へ移します。時間が足りない項目を「問題なし」にせず、未確認として残します。

モバイル品質監査を依頼する前に渡す情報

対象と目的を一枚にまとめる

対象URL、主な訪問者、検索から期待する入口、最終行動、最近の変更、困っている端末、管理権限の有無を整理します。全サイトを漠然と依頼するより、優先ページと共通部品を先に決めると、必要な確認範囲と費用条件を比較しやすくなります。

マルチデバイス制作と監査を分けて相談する

新規制作や再設計を含む場合は、マルチデバイス対応の案内で対象範囲を確認してください。既存ページの8項目監査、修正依頼の整理、公開前後の確認方法については、お問い合わせから対象URLと困っている端末をお知らせください。

まとめ：スマホ版の取得と完了を同じ公開条件にする

モバイルファーストSEOは、スマホ表示へ切り替えたかを一度だけ確認する作業ではありません。アクセス・クロール、主要内容、メタ情報、導線、画像、読解・操作、性能、URL検査・実機確認の8項目を、変更したURLと影響範囲に合わせて再確認する運用です。

Googleが取得できることと、利用者が目的を完了できることを別々に検証し、両方の証拠がそろったときだけ公開完了とします。順位や問い合わせの保証ではなく、対象URL、再現条件、受入条件を残すことが、次の更新でも使えるモバイル品質管理になります。

制作メモ：本候補の本番反映、公開、予約、SNS送信は未承認・未実施です。投稿7012の単体基準値を保持し、全48件の候補と監査完了後に一度だけ本番承認を受けます。