SEOガイド ステップ5: UX / ユーザーエクスペリエンス — 訪問者がサイトを体験することでランキングに影響を与える
SEOガイド ステップ5: UX / ユーザーエクスペリエンス
これは13ステップ SEOガイドのステップ5です。ユーザーエクスペリエンスは現在、直接的なランキング要因です — Googleは訪問者があなたのサイトとどのようにインタラクトするかを測定し、迅速で、アクセシブルで、快適な体験を提供するサイトを評価します。
コンテンツ戦略(ステップ3)はあなたが何を公開するかを決定します。リンクビルディング(ステップ4)はあなたの権威を証明します。しかし、訪問者がページにアクセスしてすぐに、遅い、モバイルで壊れている、またはアクセスできないために離れてしまうと、それらは全く意味がありません。Googleはこれらの信号を追跡し、ランキング調整に利用します。
2021年以降、GoogleのページエクスペリエンスアップデートによってUXは確認されたランキング要因となりました。2024年にはINP(Interaction to Next Paint)がFIDに代わってCore Web Vitalとなりました。2026年には、これらの信号はGoogleがユーザーの満足度を伝統的な信号よりも優先するようになるにつれて、さらに重要になります。
UXがSEOに含まれるもの
SEOにおけるUX最適化は6つの分野にわたります:
- Core Web Vitals — Googleの公式UXメトリクス(LCP, INP, CLS)
- モバイル最適化 — レスポンシブデザイン、タッチターゲット、ビューポート
- アクセシビリティ(WCAG) — 誰もが使えるサイト作り
- ページエクスペリエンス信号 — HTTPS、インタースティシャルなし、安全なブラウジング
- ナビゲーションパターン — ユーザーとクローラーを助けるサイト構造
- フォールド上の最適化 — スクロールなしでユーザーが見るもの
1. Core Web Vitals (CWV)
Core Web VitalsはGoogleの3つの測定可能なUXメトリクスです。Chrome User Experience Report (CrUX) のデータで追跡され、ランキングに直接影響します。
3つのメトリクス:
| メトリクス | 測定内容 | 良好 | 改善が必要 | 不良 | |------------|----------|------|------------|------| | LCP (Largest Contentful Paint) | 読み込み速度 | < 2.5秒 | 2.5秒 - 4.0秒 | > 4.0秒 | | INP (Interaction to Next Paint) | 応答性 | < 200ms | 200ms - 500ms | > 500ms | | CLS (Cumulative Layout Shift) | 視覚的安定性 | < 0.1 | 0.1 - 0.25 | > 0.25 |
LCP — Largest Contentful Paint
LCPはページの主要コンテンツがどれだけ早く表示されるかを測定します。「最大のコンテンツ」は通常、あなたのヒーロー画像、メイン見出し、または最も大きなフォールド上のブロックです。
一般的なLCPの問題と修正:
| 問題 | 影響 | 修正 | |------|------|------| | 最適化されていないヒーロー画像 | +2-5秒 | WebP形式、適切なサイズ、fetchpriority="high" | | レンダーブロッキングCSS/JS | +1-3秒 | 重要なCSSをインライン、非重要を遅延 | | サーバーレスポンスの遅さ (TTFB) | +1-4秒 | CDN、サーバーキャッシュ、エッジデプロイメント | | Webフォントがレンダリングをブロック | +0.5-2秒 | font-display: swap、重要なフォントを事前ロード | | サードパーティスクリプト | +1-3秒 | アナリティクス/チャットウィジェットを遅延、広告を遅延ロード |
LCP最適化の優先順位:
<!-- 1. LCP画像をプリロード -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<!-- 2. 重要なCSSをインライン(最初の14KB) -->
<style>/* フォールド上のスタイルのみ */</style>
<!-- 3. 非重要なCSSを遅延 -->
<link rel="stylesheet" href="/full.css" media="print" onload="this.media='all'">
<!-- 4. 明示的なサイズを指定したヒーロー画像 -->
<img src="/hero.webp" width="1200" height="600"
fetchpriority="high" decoding="async"
alt="説明的なaltテキスト">
クイックウィン: ホームページでPageSpeed Insightsを実行します。LCP要素が何であるかを確認します。それが画像であれば、WebPに変換し、明示的な幅/高さを設定し、fetchpriority="high"を追加します。これだけでLCPが1-2秒短縮されることがよくあります。
INP — Interaction to Next Paint
INPはユーザーがインタラクト(クリック、タップ、タイプ)したときにページがどれだけ早く応答するかを測定します。ページ訪問中の最も悪いインタラクションを追跡し、それをスコアとして使用します。
一般的なINPの問題と修正:
| 問題 | 影響 | 修正 | |------|------|------| | 長いJavaScriptタスク | +200-1000ms | 小さなタスクに分割し、requestIdleCallbackを使用 | | 重いイベントハンドラ | +100-500ms | デバウンス、スロットル、requestAnimationFrameを使用 | | レイアウトティスキング | +50-300ms | DOMの読み書きをバッチ処理し、will-changeを使用 | | サードパーティスクリプト | +100-500ms | 遅延、インタラクション後に読み込み、Web Workersを使用 | | 同期API呼び出し | +200-2000ms | Async/await、ローディングステート、楽観的UI |
INP最適化技術:
// 悪い: メインスレッドをブロックします
button.addEventListener('click', () => {
const data = heavyComputation(); // 400msブロック
updateDOM(data);
});
// 良い: メインスレッドに譲ります
button.addEventListener('click', async () => {
// 即時フィードバックを表示
button.textContent = '読み込み中...';
// 重い作業を小さなチャンクに分割
await scheduler.yield();
const data = heavyComputation();
await scheduler.yield();
updateDOM(data);
});
クイックウィン: Chrome DevToolsを開く > パフォーマンスタブ。サイトをクリックして、"長いタスク"(赤い三角形)を探します。これらがメインスレッドをブロックしています。最も大きな長いタスクは通常サードパーティスクリプトです — 遅延させるか、最初のインタラクション後に読み込んでください。
CLS — Cumulative Layout Shift
CLSは視覚的安定性を測定します — ページコンテンツが読み込まれるときにどれだけジャンプするか。ユーザーはボタンをクリックしてページがシフトしてしまい、別のものをクリックしてしまうことに最も苛立ちを感じます。
一般的なCLSの問題と修正:
| 問題 | CLS影響 | 修正 | |------|---------|------| | サイズ指定のない画像 | 0.1-0.5 | 常にwidthとheightを設定 | | 遅延して読み込まれる広告 | 0.1-0.3 | min-heightでスペースを確保 | | Webフォントによる再フロー | 0.05-0.2 | font-display: optionalまたはサイズ調整したフォールバック | | 動的コンテンツの挿入 | 0.1-0.4 | スペースを確保し、content-visibilityを使用 | | クッキーバナーによるコンテンツの押し下げ | 0.05-0.2 | オーバーレイデザイン(押し下げではない) |
CLS予防チェックリスト:
<!-- 常にメディアのサイズを指定 -->
<img src="photo.webp" width="800" height="600" alt="...">
<video width="1280" height="720"></video>
<iframe width="560" height="315"></iframe>
<!-- 動的コンテンツのためにスペースを確保 -->
<div style="min-height: 250px;">
<!-- 広告はここに読み込まれ、シフトはありません -->
</div>
<!-- レスポンシブメディアのためにアスペクト比を使用 -->
<div style="aspect-ratio: 16/9;">
<img src="..." style="width: 100%; height: 100%; object-fit: cover;">
</div>
クイックウィン: 上位10ページのすべてのおよびに明示的なwidthとheight属性を追加してください。この単一の変更が最も一般的なCLSの問題 — 画像が読み込まれ、コンテンツを押し下げるのを排除します。
2. モバイル最適化
Googleはモバイルファーストインデックスを使用します — あなたのモバイル体験がランキング体験です。あなたのサイトがモバイルで壊れている場合、デスクトップ版が完璧でも意味がありません。
モバイル最適化チェックリスト:
| 要素 | 要件 | 一般的な失敗 | |------|------|-------------| | ビューポートメタ | width=device-width, initial-scale=1 | 完全に欠落 | | タッチターゲット | 最小44x44px | 小さいリンク、狭いボタン | | フォントサイズ | 最小16pxの本文テキスト | 12pxはモバイルで不可読 | | コンテンツ幅 | 水平スクロールなし | 固定幅の要素 | | タップ間隔 | 目標間8px以上の最小間隔 | 隣接するリンクが接触 | | レスポンシブ画像 | 適切なサイズのsrcset | モバイルでデスクトップサイズの画像 |
レスポンシブデザインパターン:
/* モバイルファーストアプローチ */
.container {
padding: 16px;
font-size: 16px;
}
/* タッチフレンドリーなターゲット */
.button, .link {
min-height: 44px;
min-width: 44px;
padding: 12px 16px;
}
/* レスポンシブタイポグラフィ */
h1 { font-size: clamp(1.5rem, 4vw, 3rem); }
p { font-size: clamp(1rem, 2vw, 1.125rem); }
/* 水平オーバーフローなし */
img, video, iframe {
max-width: 100%;
height: auto;
}
Googleが確認するモバイルSEOの信号:
- ズームなしで読めるテキスト
- リンク/ボタンが近すぎない
- コンテンツがビューポート幅に収まる(水平スクロールなし)
- Flashやサポートされていない技術がない
- インタースティシャルが入場時にコンテンツをブロックしない
- ページが4G/3G接続で迅速に読み込まれる
クイックウィン: あなたの電話でサイトを開いてください。すべてのボタンとリンクをクリックしてみてください。ターゲットが近すぎて誤って別のものをクリックしたり、テキストを読むためにピンチズームする必要がある場合 — それらはあなたの優先修正です。
3. アクセシビリティ (WCAG)
アクセシビリティは単なる倫理的な選択ではなく、SEOの信号です。Googleのアルゴリズムは、スクリーンリーダー、キーボードのみのナビゲーション、または視覚障害を持つユーザーにとって利用可能なサイトを優遇します。WCAG(ウェブコンテンツアクセシビリティガイドライン)準拠は、より良いランキングと相関しています。
重要なアクセシビリティ要件:
| 要素 | 要件 | SEOへの影響 | |------|------|-------------| | 画像のaltテキスト | 意味のあるすべての画像に説明的なテキスト | 直接(画像SEO + アクセシビリティ) | | 見出しの階層 | H1 → H2 → H3をスキップせずに | 直接(コンテンツ構造) | | 色のコントラスト | 通常のテキストで4.5:1、大きなテキストで3:1 | 間接(使いやすさ) | | キーボードナビゲーション | すべてのインタラクティブ要素がTabで到達可能 | 間接(使いやすさ) | | ARIAラベル | テキストなしのアイコン、ボタンにラベル | 間接(スクリーンリーダーUX) | | フォーカスインジケータ | キーボードナビゲーションの際に視覚的なフォーカスリング | 間接(使いやすさ) | | フォームラベル | すべての入力に関連付けられたがある | 間接(使いやすさ) | | リンクテキスト | 説明的な("ここをクリック"ではなく) | 直接(アンカーテキストSEO) |
アクセシビリティテストプロセス:
- 自動スキャン — Lighthouse、axe-core、またはWAVEを実行します(約30-50%の問題を捕捉)
- キーボードテスト — Tab、Enter、Escapeのみを使用してサイト全体をナビゲート
- スクリーンリーダーテスト — CoreテストのためにVoiceOver(Mac)またはNVDA(Windows)を使用
- 色のコントラスト — すべてのテキストを背景とチェック(DevToolsのコントラストチェッカーを使用)
- ズームテスト — 200%にズーム — すべてはまだ機能しますか?
一般的なアクセシビリティ修正:
<!-- 画像: 説明的なaltテキスト -->
<img src="chart.png" alt="2026年1月から3月にかけてのオーガニックトラフィックの40%増加を示す棒グラフ">
<!-- ボタン: 明確なラベル -->
<button aria-label="ナビゲーションメニューを閉じる">
<svg>...</svg> <!-- アイコンのみのボタンにはaria-labelが必要です -->
</button>
<!-- フォーム: 関連するラベル -->
<label for="email">メールアドレス</label>
<input type="email" id="email" name="email" required>
<!-- リンク: 説明的なテキスト -->
<a href="/guide">完全なSEOガイドを読む</a>
<!-- NOT: <a href="/guide">ここをクリック</a> -->
<!-- キーボードユーザーのためにナビゲーションをスキップ -->
<a href="#main-content" class="skip-link">主要コンテンツにスキップ</a>
クイックウィン: ホームページでLighthouseを実行し、アクセシビリティカテゴリで評価します。最初に「失敗」とされたすべてを修正してください — これらは通常、altテキストの欠如、フォームラベルの欠如、低コントラストのテキストです。これらの修正は通常30分で済み、スコアを20ポイント以上改善します。
4. ページエクスペリエンス信号
Core Web Vitalsに加えて、Googleはランキングに影響を与えるいくつかのその他のページエクスペリエンス信号を評価します。
ページエクスペリエンス要因:
| 信号 | 要件 | チェック | |------|------|-------| | HTTPS | サイト全体がHTTPSで提供される | 混在コンテンツが破損します | | 侵入的なインタースティシャルなし | 到着時にコンテンツをブロックしない | モバイルで30%以上を覆うポップアップ | | 安全な閲覧 | マルウェア、フィッシング、欺瞞的コンテンツがない | Googleの安全な閲覧ステータス | | モバイルフレンドリー | モバイルフレンドリーテストを通過 | Googleモバイルフレンドリーテスト | | 誤解を招く広告なし | 広告がコンテンツに似ていない | 隠れたダウンロードボタン |
インタースティシャルガイドライン(許可されるものとペナルティされるもの):
| 許可される | ペナルティ | |------------|------------| | 年齢確認(法的に必要) | ページに入る際の全画面ポップアップ | | クッキー同意(法的に必要) | コンテンツ全体を覆うメールサインアップ | | 有料コンテンツのためのログイン壁 | 「アプリをダウンロード」のためにコンテンツをブロック | | 画面の30%未満を使用する小さなバナー | コンテンツアクセス前のカウントダウンタイマー | | ユーザーがスクロール/インタラクトした後 | ユーザーがコンテンツを見える前 |
HTTPSチェックリスト:
- [ ] SSL証明書は有効で期限切れでない
- [ ] すべてのページがHTTP → HTTPSにリダイレクト(301)
- [ ] 混在コンテンツなし(HTTPSページのHTTPリソース)
- [ ] HSTSヘッダーが有効(includeSubDomains付き)
- [ ] 内部リンクはHTTPSを使用(HTTPではなく)
- [ ] サイトマップはHTTPS URLを使用
- [ ] カノニカルタグはHTTPSを使用
クイックウィン: 混在コンテンツを確認します — 重要なページでDevToolsコンソールを開いてください。「混在コンテンツ」警告がある場合、HTTPSページでHTTPリソースを読み込んでいます。それらのURLをHTTPSに更新してください。これは最も一般的なページエクスペリエンスの問題の1つです。
5. ナビゲーションパターン
良いナビゲーションは、ユーザーと検索エンジンの両方に役立ちます。ユーザーは必要なものをすぐに見つけることができ、Googleクローラーはあなたのサイト構造を理解し、PageRankを効率的に分配します。
ナビゲーションのベストプラクティス:
| パターン | 利点 | 実施 | |----------|------|------| | フラットアーキテクチャ | ホームから3クリック以内のページ | ハブページ、パンくずリスト | | パンくずリスト | ユーザーが自分の位置を知る | スキーママークアップ + 可視的なトレイル | | 論理的なURL構造 | 予測可能なパス | /category/subcategory/page | | フッターナビゲーション | 二次ページにアクセス可能 | 法律、アバウト、コンタクト、サイトマップ | | 内部検索 | ユーザーが特定のコンテンツを見つけられる | サジェスチョン付き検索ボックス | | 関連コンテンツ | バウンスを減少させ、深さを増やす | 「関連記事」セクション |
理想的なサイトアーキテクチャ:
ホームページ(すべての重要なものから1クリック)
├── /products/ (カテゴリーのハブ — すべての製品へのリンク)
│ ├── /products/category-a/
│ │ ├── /products/category-a/product-1
│ │ └── /products/category-a/product-2
│ └── /products/category-b/
├── /blog/ (コンテンツハブ — すべての投稿へのリンク)
│ ├── /blog/topic-cluster-1/ (ピラーページ)
│ │ ├── /blog/subtopic-1a
│ │ └── /blog/subtopic-1b
│ └── /blog/topic-cluster-2/
├── /tools/ (ユーティリティページ)
└── /about/ (信頼のページ)
パンくずリストの実施:
<!-- 可視のパンくずリスト -->
<nav aria-label="パンくずリスト">
<ol>
<li><a href="/">ホーム</a></li>
<li><a href="/blog/">ブログ</a></li>
<li aria-current="page">SEOガイド ステップ5</li>
</ol>
</nav>
<!-- スキーママークアップ(BreadcrumbList) -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://example.com/" },
{ "@type": "ListItem", "position": 2, "name": "ブログ", "item": "https://example.com/blog/" },
{ "@type": "ListItem", "position": 3, "name": "SEOガイド ステップ5" }
]
}
</script>
ナビゲーションの赤信号:
- ホームページから4クリック以上のページ(深すぎる)
- パンくずリストがない(ユーザーとGoogleは状況を失う)
- JavaScriptのみのナビゲーション(クローラーがリンクを見逃す場合がある)
- 孤立ページ(それに対して指し示す内部リンクがない)
- 200以上のリンクがあるメガメニュー(リンクごとの価値を薄める)
クイックウィン: 重要なコンバージョンページをチェックしてください — ホームページから何クリックですか? 3回以上の場合、ホームページまたはカテゴリハブから直接リンクを追加してください。深くなるごとに、ユーザーの訪問とクロールの頻度が減少します。
6. フォールド上の最適化
ユーザーがスクロールする前に見るものは、彼らが滞在するかどうかを決定します。フォールド上のコンテンツは、価値を即座に伝え、ユーザーをそこに連れた検索クエリと一致しなければなりません。
フォールド上の必須要素:
| 要素 | なぜ | 一般的な失敗 | |------|------|--------------| | 明確な見出し (H1) | クエリへの関連性を確認 | 一般的または欠落 | | 価値提案 | なぜ滞在すべきなのか? | フォールドの下に埋もれている | | 主なCTA | 次に何をするべきか? | 隠れているまたは不明瞭 | | ヒーロー画像/メディア | 視覚的な関与 | 遅延読み込み、LCPの問題を引き起こす | | 信頼信号 | なぜ信じるべきか? | ロゴ、レビュー、または資格がない |
フォールド上のレイアウトパターン:
デスクトップ (1440px ビューポート):
┌─────────────────────────────────────┐
│ ナビゲーションバー │
├─────────────────────────────────────┤
│ │
│ H1: クエリに一致した明確な見出し │
│ サブタイトル: 価値提案 │
│ │
│ [主なCTAボタン] │
│ │
│ 信頼信号: ロゴ、統計、バッジ │
│ │
├─────────────────────────────────────┤
│ ↓ コンテンツはフォールドの下に続く │
└─────────────────────────────────────┘
モバイル (375px ビューポート):
┌────────────────────┐
│ ナビ (ハンバーガー) │
├────────────────────┤
│ │
│ H1: 見出し │
│ (モバイルで短い) │
│ │
│ [CTAボタン] │
│ (フルワイド、44px+) │
│ │
│ 信頼バッジ │
│ │
├────────────────────┤
│ ↓ スクロールしてもっと │
└────────────────────┘
フォールド上の重要ルール:
- H1はスクロールなしで見えるべき(検索クエリと一致)
- CTAはスクロールなしで見えるべき(バウンスを減少させる)
- フォールド上のコンテンツにレイアウトシフトがないこと(CLSの元凶)
- ヒーロー画像は迅速に読み込むべき(通常はLCP要素)
- モバイルではフォールド上のコンテンツを減少させる(ビューポートスペースが少ない)
クイックウィン: モバイルでホームページのスクリーンショットを撮ってください(375px幅)。H1は見えますか? CTAボタンは見えますか? 2秒以内にサイトの内容が分かりますか? どれか一つでも「いいえ」と答えた場合、ユーザーがスクロールする前に訪問者を失っています。
UX監査チェックリスト
あなたの上位ページに対してこれを実行してください:
- [ ] LCPが2.5秒未満(ヒーロー画像が最適化され、重要なCSSがインライン)
- [ ] INPが200ms未満(インタラクションをブロックする長いJavaScriptタスクなし)
- [ ] CLSが0.1未満(すべての画像にサイズがあり、遅延読み込みシフトなし)
- [ ] モバイルフレンドリー(44pxのタッチターゲット、16px以上のテキスト、水平方向のスクロールなし)
- [ ] アクセシブル(altテキスト、見出しの階層、色のコントラスト、キーボードナビゲーション)
- [ ] どこでもHTTPS(混在コンテンツなし、HSTSが有効)
- [ ] 侵入的なインタースティシャルなし(同意オーバーレイはOK、コンテンツをブロックするポップアップはNG)
- [ ] パンくずリストがある(BreadcrumbListスキーマ付き)
- [ ] 重要なページまで4クリック未満のナビゲーションの深さ
- [ ] フォールド上が最適化されている(H1が見え、CTAが見え、LCPが早い)
LANGRはあなたのUXをどのようにスキャンするか
LANGRのUX関連スキャンモジュールには以下が含まれます:
- Core Web Vitalsモジュール — LCP、INP、CLSをChrome User Experience Reportから測定(実ユーザーデータ)
- PageSpeedモジュール — フルLighthouseパフォーマンス監査、モバイルおよびデスクトップスコア
- モバイルモジュール — ビューポート設定、タッチターゲットサイズ、テキストの可読性
- アクセシビリティモジュール — WCAG準拠チェック、ARIA使用、色のコントラスト
- レイアウトスキャンモジュール — AI駆動のモバイルおよびデスクトップレイアウト評価
- ページエクスペリエンスモジュール — インタースティシャル検出、HTTPSステータス、安全なブラウジング
これらのモジュールはすべてのスキャンで実行され、訪問者があなたのサイトをどのように体験するかの完全な概要と、ランキングを向上させるために正確に修正すべきことを提供します。
一般的なUXの誤り(影響度順)
- モバイルを無視する — 60%以上の検索はモバイル;壊れたモバイル = 壊れたランキング
- 最適化されていない画像 — 遅いLCPの第一の原因(ほとんどの場合、最も簡単な修正)
- 明示的な画像サイズがない — レイアウトシフトがCLSスコアを破壊
- サードパーティスクリプトの肥大 — チャットウィジェット、アナリティクス、広告がINPをブロック
- アクセシビリティの基本が欠けている — altテキストなし、見出しの階層なし、コントラストなし
- コンテンツをブロックするインタースティシャル — ユーザーがコンテンツを見る前の全画面ポップアップ
- 深いサイトアーキテクチャ — 重要なページがホームページから5クリック以上埋もれている
- フォールド上の価値がない — ユーザーはスクロールせずにサイトの内容が分からない
次は何?
ステップ6: モニタリング & ランキング — 測定しないと改善できません。 キーワードの位置、スコア追跡、変更の報告、アップタイムのモニタリング。
このガイドはLANGRの13ステップSEOシリーズの一部です。無料監査を実行すると、あなたのサイトが13の分野全体でどのように立っているかを確認してください。