会社情報
採用情報
お問い合わせ
Article

モバイルSEO対策の基礎：モバイルフレンドリーなサイトに必要なこと

高田晃太郎
モバイルSEO対策の基礎：モバイルフレンドリーなサイトに必要なこと

モバイルが全ウェブトラフィックの約60%を占めるという統計は、もはや前置きではありません¹。Googleは2024年にモバイルファーストインデックスの移行完了を公表し、評価はスマートフォン版コンテンツを前提に行われます²。さらに2024年3月、Core Web Vitalsの指標はINPへ置き換えられ³、INP（操作から次の描画までの応答）200ms以下、LCP（最大要素の初回表示）2.5秒以下、CLS（レイアウトのずれ）0.1未満といったしきい値が「良好」の目安として広く用いられています⁴。公開データでは、モバイルでのページ読み込みが1秒から3秒に遅延すると直帰率が32%増加する傾向も示されています⁵。技術選定と運用体制を司る立場として、モバイルSEOは単なるフロントの最適化ではなく、収益・LTV（顧客生涯価値）・獲得単価（CAC）に波及する経営課題です。この記事では、基礎に立ち返りつつ、実装でつまずきやすい要点を押さえます。

モバイルSEOの現在地：評価軸とKPIの再定義

モバイルSEOを「速度だけ」に矮小化すると、検索意図の適合や情報アーキテクチャ（情報の構造設計）が後景に退きます。実務では、検索意図との整合、ページ体験（Core Web Vitalsと利便性）、コンテンツの網羅性、内部・外部リンク構造という四層で評価するのが現実的です⁶。特にモバイルは視野が狭く操作コストが高いため、同じ情報量でも提示設計が成果に直結します。たとえば一覧カードをスワイプ前提で積み上げるより、ファセット検索（条件での絞り込み）を上部固定して目的到達を早めるだけで、平均滞在が伸びつつ直帰が下がるケースは珍しくありません。技術側のKPIは、検索流入に効く指標（INP・LCP・CLS、インデックスカバレッジ、内部リンクのクロール容易性）と、事業KPI（CVR、自然検索のCAC、LTV）を同時にモニタリングする構えが実務に適します⁶。

Core Web Vitalsをモバイル基準で読む

2024年以降、INPは体感の中心指標です³。タップやフォーム送信などユーザー操作の処理完了までの最悪ケースが200ms以下であれば、体感は十分に機敏と言えます⁴。INP低下の主因は、長いタスク、メインスレッドの同期処理、重い第三者タグ、複雑なコンポーネント階層です。LCPは最大コンテンツ要素（画像・動画・大きなテキスト）の初回描画まで⁷。プリロードと優先度制御、CDN・画像最適化、初期レンダリングの早期完了が決め手になります。CLSは要素サイズの確定とフォントロード戦略で大半を制御できます。いずれもラボ値だけでなく、実ユーザー計測（RUM：Real User Monitoring）で監視して初めて運用に耐えます。

モバイルファーストインデックスとコンテンツパリティ

評価対象はスマートフォン版です²。構造化データ、メタデータ、内部リンク、主要コンテンツはモバイルとデスクトップで同等（コンテンツパリティ）に用意します⁸。アクセシビリティ配慮は検索体験にも波及しやすく、ビューポートの正設定、適切なタップターゲット（おおむね48px相当）⁹、コントラスト基準の担保はCVRの底上げと直帰抑制に寄与します。モバイルだけFAQや仕様表、比較ブロックを省略するとクロールや理解を阻みやすく、情報の非対称は避けるべきです。

実装の基礎：モバイルフレンドリーを形にする

モバイルフレンドリーは、土台のHTML・ネットワーク戦略、メディア最適化、JavaScriptとレンダリング戦略の三位一体で成立します。奇策よりも、ボトルネックに効く確実な手当てを漏れなく積み上げることが、最短での成果に直結します。

HTMLとネットワーク優先度を正しく設計する

最初に着手すべきはビューポート、接続の事前確立、クリティカルリソースの優先読込です。以下のようなヘッド定義は、多くのアプリでそのまま移植可能です（preconnect/dns-prefetchで接続確立を前倒し、preloadで初期表示に必要なCSS/画像を先取り、fetchpriorityでLCP要素の優先度を明示）。

<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <link rel="preconnect" href="https://cdn.example.com" crossorigin>
  <link rel="dns-prefetch" href="//cdn.example.com">
  <link rel="preload" as="style" href="/assets/app.css" />
  <link rel="preload" as="image" href="/images/hero@2x.avif" fetchpriority="high" imagesrcset="/images/hero.avif 1x, /images/hero@2x.avif 2x" imagesizes="100vw" />
  <link rel="stylesheet" href="/assets/app.css" />
  <script type="module" src="/assets/app.mjs" defer></script>
</head>
<body>...</body>
</html>

HTTP/2/3では多重化が効きますが、依然として優先度ヒントは重要です。最大コンテンツ要素の事前ヒント、CSSの早期適用、JSはモジュール化して遅延実行とする構えがLCPとINPの両立に効きます⁷。

画像・フォントの最適化でLCPとCLSを同時に抑える

モバイルのLCPは多くの場合、画像が要因です⁷。AVIFやWebPをデフォルトにし、アートディレクションにはsrcsetとsizesで過不足ない転送量に整えます¹⁰。CSS・HTMLではアスペクト比を明示して視覚の安定を確保します。

<img
  src="/images/card.avif"
  srcset="/images/card.avif 1x, /images/card@2x.avif 2x"
  sizes="(max-width: 600px) 92vw, 600px"
  width="600" height="400" style="aspect-ratio: 3 / 2; object-fit: cover;"
  loading="lazy" decoding="async" alt="製品カード" />

フォントは可読性とCLSの両立が肝要です。font-displayのswapまたはoptionalを使い、可変フォントならウエイト統合で転送を削りつつ初回描画を速めます。

@font-face {
  font-family: "NotoSansJP-Var";
  src: url("/fonts/NotoSansJP-VF.woff2") format("woff2-variations");
  font-weight: 200 900;
  font-display: swap;
}
:root { --base: clamp(14px, 1.6vw, 16px); }
body { font-family: "NotoSansJP-Var", system-ui, -apple-system, sans-serif; font-size: var(--base); }

JavaScriptとレンダリング：INP時代の最適解

INPはメインスレッド占有時間と強く相関します³。初期表示はSSR（サーバーサイドレンダリング）やSSG（静的生成）で直描画し、インタラクションは分割読み込みとアイドル時間活用で滑らかにします。モジュール分割、第三者タグの遅延、イベントハンドラの軽量化は必須です。

// app.mjs
import { hydrateRoot } from "react-dom/client";
import("./bootstrap.js").then(({ App }) => {
  const root = document.getElementById("root");
  hydrateRoot(root, App());
});

// bootstrap.js
import React, { lazy, Suspense } from "react";
const HeavyWidget = lazy(() => import("./HeavyWidget.js"));
export function App() {
  return (
    <Suspense fallback={null}>
      <HeavyWidget />
    </Suspense>
  );
}

ユーザー入力の遅延を避けるため、パッシブイベント（スクロールなどでブラウザの最適化を阻害しない）や遅延ロジックを徹底します。IntersectionObserverによる遅延ロード、長いタスクの分割、requestIdleCallbackの活用はINP改善の定番です。

// in-page.js
const abort = new AbortController();
addEventListener("touchstart", () => {}, { passive: true, signal: abort.signal });
const io = new IntersectionObserver((entries) => {
  for (const e of entries) if (e.isIntersecting) {
    import("./above-the-fold.js");
    io.disconnect();
  }
});
io.observe(document.querySelector("#fold"));

ネットワークとキャッシュもINP・LCPの両輪です。HTTPキャッシュと圧縮を正しく設定し、画像・フォント・JSは長期キャッシュ、HTMLは短寿命に分離します。

# nginx.conf (抜粋)
location ~* \.(avif|webp|jpg|png|css|js|woff2)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}
location = /index.html {
  add_header Cache-Control "no-cache";
}
gzip on; gzip_types text/css application/javascript font/woff2; gzip_min_length 1024;

PWAの採用は必須ではありませんが、回線不安定な環境の多いモバイルでは安定性に寄与します。過剰なキャッシュは更新難を招くため、ナビゲーションプリロードや戦略的キャッシュにとどめるのが無難です。

// service-worker.js
self.addEventListener("install", (e) => self.skipWaiting());
self.addEventListener("activate", (e) => clients.claim());
self.addEventListener("fetch", (e) => {
  const url = new URL(e.request.url);
  if (url.pathname.startsWith("/images/")) {
    e.respondWith(caches.open("img-v1").then(async (c) => {
      const hit = await c.match(e.request);
      if (hit) return hit;
      const res = await fetch(e.request, { cache: "no-store" });
      c.put(e.request, res.clone());
      return res;
    }));
  }
});

計測と継続運用：RUM、CI、バジェット管理

施策の効果は計測設計で決まります。ラボ計測（LighthouseやWebPageTest）は再現性が高く、RUM（実ユーザー計測）は実環境の真実を映します。両者を組み合わせ、Core Web Vitalsの実測値、エラーレート、遷移ごとのCVRを同一ダッシュボードで見せると意思決定が速くなります。web-vitalsライブラリを使えば、数行でRUMを組み込めます。

// rum.js
import { onINP, onLCP, onCLS } from "web-vitals";
function send(metric) {
  navigator.sendBeacon("/rum", JSON.stringify({
    name: metric.name, value: metric.value, id: metric.id, url: location.pathname,
  }));
}
onINP(send); onLCP(send); onCLS(send);

CI（継続的インテグレーション）にはLighthouse CIを組み込み、スコアや指標のしきい値に違反したらPRをブロックします。ラボのブレはあるため、絶対値より回帰検知を重視する構成が実務的です。

npx lhci autorun --collect.url=https://staging.example.com --assert.preset=lighthouse:recommended

アセットサイズのバジェットは、回線品質と端末性能を前提に決めます。実務では、初期JSの転送量を軽量に抑えるほどINPの健全性を保ちやすく、目安としては150KB前後（gzip換算）を上限に設計する例が多いのが実情です。第三者タグは収益との相関を検証し、計測タグはサーバーサイド計測や遅延読み込みを積極的に採用します。障害時の回復やフェイルセーフも現場の体験の一部であり、たとえば検索フォームが失敗したらキャッシュからのサジェストを代替表示するなど、UXとしての耐障害性は結果としてSEOの指標にも波及します。

UX・コンテンツ・スキーマ：検索意図と体験の接点を磨く

モバイルではスクロール量と可読性が命です。セクションの見出しは情報要求に沿って設計し、折りたたみは乱用せず、長文は要約と見出しリンクで回遊を促します。視覚の安定はCLSに直結するため、広告枠や動的ウィジェットにもあらかじめ高さを確保します。インタースティシャルの乱用は評価と体験の双方を損ない、サイト離脱とブランド毀損を招きます。ローカルやナレッジ系の検索では構造化データの整備が可視性を高めます⁸。以下は記事の構造化の一例です。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "モバイルSEO対策の基礎",
  "datePublished": "2025-08-30",
  "author": { "@type": "Person", "name": "高田晃太郎" },
  "mainEntityOfPage": { "@type": "WebPage", "@id": "https://example.com/articles/mobile-seo-basics" }
}

E-E-A-T（経験・専門性・権威性・信頼性）の観点では、執筆者情報、実データや検証プロセスの開示、更新履歴の明記が信頼蓄積に役立ちます。技術記事ならベンチマーク条件を明示し、再現性のある手順や設定を公開すると、被リンクや指名検索の増加に寄与します。社内外のナレッジを関連記事として相互に結び、クロール効率を高める導線も重要です。たとえばCore Web Vitalsの詳細解説、Next.jsのSSR最適化、画像最適化の実践といった形で、意図別に深掘り先を示しておくと、ユーザーとクローラ双方が迷いません。

事業インパクトを可視化して優先度を固定する

技術ロードマップに落とすには、施策の事業効果を数値化して合意を形成するのが近道です。公開データでも、読み込みが遅いほど直帰率が高まる傾向は一貫して示されています¹¹。LCPやINPの改善が直帰の低減やCVRの改善と相関するかを、RUMの実測とA/Bテストで検証し、勝ち筋をテンプレート化する。こうした反復で、自然検索のCVRが数ポイントでも上向けば、同じ広告費でもLTVベースの投資余力は変わります。影響が確認できた施策から順に標準化し、横展開するのが再現性の高い運用です。

まとめ：小さく速く、継続的に勝つ

モバイルSEOは一度作って終わりではなく、端末性能・ブラウザ仕様・Googleの評価軸が動く前提での継続運用が前提です。まずは最大要素の表示を早め、視覚の安定を確保し、入力の応答を滑らかにする、この三点に集中します。ビューポートと優先度ヒントの正設定、画像とフォントの最適化、SSRとコード分割、第三者タグの統制、RUMとCIの回帰検知という順で手を打てば、最短距離で成果が出ます。次に、実測値とCVRを同じダッシュボードで観察し、施策と売上の相関を言語化してチームで共有してください。あなたのプロダクトの検索体験は、今日の一手で確実に良くできます。まずはPageSpeed Insightsと実ユーザー計測を並べて開き、最大コンテンツ要素と最長のインタラクションを特定するところから、今すぐ着手してみませんか。

参考文献

  1. Statista — Share of website traffic coming from mobile devices
  2. Google Search Central — Mobile-first indexing best practices
  3. Google Search Central Blog — Introducing Interaction to Next Paint (INP)
  4. web.dev — Defining the Core Web Vitals metrics thresholds
  5. Think with Google — Find out how you stack up to new industry benchmarks for mobile page speed
  6. Google Search Central — Links help Google find your content (Crawlable links)
  7. web.dev — Largest Contentful Paint (LCP)
  8. Google Search Central — Mobile-first indexing best practices — Structured data
  9. Google Support — Make Android apps more accessible — Tap target size
  10. web.dev — Performance: Optimize graphical content (AVIF/WebP)
  11. Smart Insights — Mobile visitors are 90% likely to bounce from pages loading in 1–5 seconds