Webサイトの統合設計ガイド：SEO・UX・表示速度を一つの改善計画へ

2026年10月8日にGoogle SearchのSEO Starter・Article structured data・page experience、W3C見出し、web.dev Web Vitals/LCP、MDNのpicture・scriptを再確認した。Core Web VitalsはLCP・INP・CLSを端末区分ごとの75パーセンタイルで読み、ラボと現場を分ける。LCP候補画像のlazy回避、資源発見、CSS/JS、サーバー処理、見出し・リンク・任意のArticleデータ、pictureのsource/fallback、deferとJSON-LDを別の実装論点として扱い、速度・構造・SEO・売上を一項目へ統合しない。

30秒で要点

• SEO・UX・表示速度を、同じページで利用者がしたいことに結び付けます。「検索で見つかる」「内容を理解できる」「待たずに操作できる」を別々の担当指標で終わらせません。
• 現在のCore Web VitalsはLCP・INP・CLSです。端末区分ごとの75パーセンタイルで確認し、開発中のラボ測定と実ユーザーの値を区別します。
• 改善にはトレードオフがあります。画像、JavaScript、説明の量を一律に減らすのではなく、残す機能と比較条件を決めて変更前後を確認します。

検索向けに説明を増やしたら、必要な情報が探しにくくなった。見栄えのよい動きを追加したら、入力が遅くなった。速度の点数を上げるために画像を削ったら、商品の違いが伝わらなくなった。こうした問題は、各分野の改善が、ページの目的とつながっていないときに起きます。

この記事は、Webサイトの設計・改修を進める担当者が、SEO・UX・表示速度の作業を一つの計画へまとめるためのガイドです。方針と診断を先に説明し、後半では意味のあるHTML、画像、CSS、JavaScript、構造化データの小さな実装例を示します。コードを読まない場合も、表と確認項目から依頼内容を整理できます。

個別の点数より、利用者が終えたいことを決める

SEOは検索エンジンに見つけてもらい、内容を理解してもらうための整備です。UXは利用者が理解し、迷わず行動できる体験です。表示速度は、その体験の待ち時間や応答性を支える要素です。三つは関係しますが、同じ指標ではありません。

たとえばサービスの比較ページなら、「対象条件を確認し、自分に合うプランを選ぶ」というタスクを置けます。SEOではページの主題が伝わるタイトルやリンク、UXでは違いと条件の説明、速度では比較表や操作が使えるまでの待ち時間を確認します。

表が収まらない場合は、横にスクロールできます

GoogleはCore Web Vitalsをランキングシステムで使うと説明していますが、良い値を得れば上位表示できるとは説明していません。関連性や内容を含めた判断であり、速度の改善率から順位や売上の上昇率を換算することはできません。ページ体験とGoogle検索

設計前にそろえる三つの前提

最初の成果物は、見た目の案だけではありません。ページの対象、成功条件、制約を短く記録します。これがないと、SEO担当、デザイナー、実装担当が別のゴールを最適化してしまいます。

表が収まらない場合は、横にスクロールできます

対象ページを一つ決め、現状の画面、内容、実装、計測期間を残します。比較対象をそろえずに「前より良くなった」と判断しないためです。繁忙期、広告の変更、商品構成、計測の定義が変わった場合は、それも記録します。

成功条件は、問い合わせ数だけにしない方が原因を追えます。比較条件を読み取れるか、フォームの途中で困らないか、必要な要素が表示されるかなど、途中の状態を観察します。利用者の理解は、自動ツールの点数だけでは分かりません。

診断はSEO・UX・性能を同じページで行う

SEO：発見と内容の対応を見る

ページにアクセスできるか、タイトルが内容を表しているか、見出しが主題を整理しているか、関連するページからリンクされているかを確認します。検索流入の入口と実際の内容がずれていないかも見ます。

同じ語句の割合を増やすこと自体を改善目標にはしません。読者が知りたい条件、根拠、次に調べる内容を用意します。Googleのスターターガイドは、内容に沿ったタイトル、分かりやすいリンク、画像の説明などを案内しています。SEOスターターガイド

UX：読み取る・選ぶ・操作する順序を見る

対象の利用者が、必要な条件を見つけ、意味を理解し、次の操作を選べるかを確認します。メニューが存在することと、探せることは同じではありません。

見出しは、文字を大きくするためだけに使うものではありません。内容のまとまりを示し、支援技術などでの移動にも使われます。大見出しの下に対応する小見出しを置き、見た目の都合で階層を飛ばさないようにします。W3Cの見出しチュートリアル

キーボードで移動できるか、フォーカスの位置が見えるか、入力エラーを理解できるか、リンクの行き先が分かるかも確認します。これらの一部を点検しただけで、アクセシビリティ全体への適合を宣言しないでください。

性能：指標と測定環境を分ける

2026年10月4日に確認した公式資料では、Core Web Vitalsは次の三つです。FIDを現在の指標として使い続けないようにします。

表が収まらない場合は、横にスクロールできます

評価はモバイル・デスクトップに分けた75パーセンタイルで、三つとも基準を満たすかを見ます。平均値や、開発者の端末での1回の測定値に置き換えないでください。Web Vitals公式資料

実ユーザーのデータは、端末、回線、訪問、操作の違いを含みます。ラボ測定は条件を固定して原因を探すのに役立ちますが、現場を代替しません。通常のLighthouseの読み込みテストには利用者の操作がないため、INPそのものは測れず、TBTなどを手掛かりにします。

観測結果を実装の優先順位へ変える

三つの診断を別の表にしたまま終えず、「何ができずに困るか」「どの変更で改善しそうか」「何を壊す可能性があるか」を並べます。

表が収まらない場合は、横にスクロールできます

初期表示、操作中、ページ下部で必要になるものは違います。重要な画像を遅延させながら、使われない第三者スクリプトを先に実行する、といった逆転を避けます。

観測値を整理する完結した例

次の review-page.mjs は、既に取得した観測値から確認候補を並べる教材です。Node.jsで node review-page.mjs として実行できます。HTMLの自動解析、CrUXへの通信、実ユーザー計測は行いません。入力の数値は架空で、四つの真偽値も人が与える観測です。

import assert from 'node:assert/strict';

function reviewPage(observation) {
  if (!observation || typeof observation !== 'object') throw new TypeError('observation required');
  const flags = ['titleMatchesContent', 'headingsFollowContent', 'taskCompleted', 'keyboardUsable'];
  for (const key of flags) {
    if (typeof observation[key] !== 'boolean') throw new TypeError(key);
  }
  if (!['mobile', 'desktop'].includes(observation.device)) throw new TypeError('device');
  const { lcpMs, inpMs, cls } = observation.p75 ?? {};
  if (![lcpMs, inpMs, cls].every(n => Number.isFinite(n) && n >= 0)) {
    throw new TypeError('finite nonnegative p75 values required');
  }
  const issues = [];
  if (!observation.titleMatchesContent) issues.push('SEO: title/content');
  if (!observation.headingsFollowContent) issues.push('Structure: headings');
  if (!observation.taskCompleted) issues.push('UX: task');
  if (!observation.keyboardUsable) issues.push('UX: keyboard');
  if (lcpMs > 2500) issues.push('Performance: LCP');
  if (inpMs > 200) issues.push('Performance: INP');
  if (cls > 0.1) issues.push('Performance: CLS');
  return issues;
}

const sample = {
  device: 'mobile', titleMatchesContent: true, headingsFollowContent: true,
  taskCompleted: false, keyboardUsable: true,
  p75: { lcpMs: 3100, inpMs: 180, cls: 0.05 },
};
assert.deepEqual(reviewPage(sample), ['UX: task', 'Performance: LCP']);
assert.deepEqual(reviewPage({ ...sample, taskCompleted: true,
  p75: { lcpMs: 2500, inpMs: 200, cls: 0.1 } }), []);
assert.throws(() => reviewPage({ ...sample, p75: { lcpMs: NaN, inpMs: 1, cls: 0 } }), TypeError);
console.log(reviewPage(sample));

この結果が空でも、サイト全体が良いと判定したことにはなりません。ここで入力した項目だけが判定対象です。問い合わせの質、認可、検索への登録状態、未観測のページなどは別に確認します。

意味のあるHTMLを土台にする

次の page.html は一つのファイルで読める、説明ページの最小例です。CSSもJavaScriptもファイル内にあり、外部の解析サービスへ通信しません。JavaScriptが動かなくても、通常のリンクで各説明へ移動できます。文面は教材用で、実サービスの案内ではありません。

<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>相談の範囲と準備 | 設計教材</title>
  <meta name="description" content="相談の対象、準備する情報、次の手順を確認する教材ページです。">
  <style>
    body { margin: 0; font-family: sans-serif; line-height: 1.8; color: #172c36; background: #fff; }
    header, main, footer { max-width: 48rem; margin-inline: auto; padding: 1rem; }
    nav ul { display: flex; flex-wrap: wrap; gap: 1rem; padding-left: 1.2rem; }
    a { color: #005d65; text-underline-offset: 0.2em; }
    a:focus-visible { outline: 3px solid #005d65; outline-offset: 4px; }
    section { margin-block: 2rem; scroll-margin-top: 1rem; }
    .skip { display: inline-block; margin: 0.5rem; }
  </style>
</head>
<body>
  <a class="skip" href="#main">本文へ移動</a>
  <header>
    <nav aria-label="ページ内">
      <ul><li><a href="#scope">相談の範囲</a></li><li><a href="#prepare">準備する情報</a></li></ul>
    </nav>
  </header>
  <main id="main">
    <h1>相談の範囲と準備</h1>
    <p>必要な情報を確認してから、相談するか判断できます。</p>
    <section id="scope">
      <h2>相談の範囲</h2>
      <p>この教材では、既存ページの説明と導線の見直しを扱います。</p>
      <p>契約・料金・納期は、実際の案内では別途具体的に示します。</p>
    </section>
    <section id="prepare">
      <h2>準備する情報</h2>
      <ul><li>対象のページ</li><li>利用者が困っている操作</li><li>変更できない条件</li></ul>
      <p><a href="#scope">対応する相談の範囲をもう一度確認する</a></p>
    </section>
    <p id="status" aria-live="polite"></p>
  </main>
  <footer><p>これは公開依頼を受け付けない設計教材です。</p></footer>
  <script>
    const status = document.querySelector('#status');
    document.querySelectorAll('nav a').forEach(link => {
      link.addEventListener('click', () => {
        status.textContent = link.textContent + 'へのリンクを選びました。';
      });
    });
  </script>
</body>
</html>

追加の表示は説明用で、リンクの標準動作を取り消していません。アニメーションや独自メニューを付ける場合も、基本の移動と操作を先に成立させます。実装後には支援技術やキーボードを含む実環境で確認してください。静的な構造確認だけでは読み上げ方やフォーカス移動の品質は分かりません。

短いCSSを同梱すると追加取得を減らせますが、すべてのCSSをHTMLへ埋め込む方針にはしません。HTMLが大きくなり、別ページでのキャッシュ再利用ができない場合があるためです。大きな共通CSSは使っていない規則や初期表示との関係を調べます。

画像は役割・寸法・読込時点をセットにする

画像の最適化は圧縮率だけで決まりません。どの画面でどれくらいの寸法で見せるか、写真の細部が判断に必要か、初期表示に必要かを先に決めます。写真と図で適する形式も異なるため、WebPなどへの変換は画質・容量・対応する表示環境を比較して採用します。

LCPの候補となる主画像を loading="lazy" にすると、発見や取得が遅れます。初期表示の候補には遅延読込を付けず、必要なら fetchpriority="high" を検討します。全画像を高優先度にするのではなく、対象を絞って確認します。LCP最適化の公式ガイド

表示幅に応じて図の構図を切り替える例

次の三つを同じフォルダーへ保存します。自作SVGは教材用の長方形であり、実商品の画像ではありません。picture.html は広い画面では横長の図、狭い画面では正方形の図を選ぶ構造です。実ブラウザでの選択や描画速度は、本記事のローカル検証には含めていません。

wide.svg：

<svg xmlns="http://www.w3.org/2000/svg" width="720" height="360" viewBox="0 0 720 360">
  <rect width="720" height="360" fill="#eaf3f0"/>
  <rect x="60" y="60" width="600" height="240" rx="16" fill="#176c72"/>
</svg>

square.svg：

<svg xmlns="http://www.w3.org/2000/svg" width="360" height="360" viewBox="0 0 360 360">
  <rect width="360" height="360" fill="#eaf3f0"/>
  <rect x="40" y="40" width="280" height="280" rx="16" fill="#176c72"/>
</svg>

picture.html：

<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>構図の切替教材</title>
  <style>
    body { margin: 1rem; }
    picture { display: block; max-width: 720px; }
    img { display: block; width: 100%; height: auto; aspect-ratio: 1; }
    @media (min-width: 600px) { img { aspect-ratio: 2; } }
  </style>
</head>
<body>
  <h1>画面幅に応じた構図</h1>
  <picture>
    <source media="(min-width: 600px)" srcset="wide.svg" width="720" height="360" type="image/svg+xml">
    <img src="square.svg" width="360" height="360" fetchpriority="high" alt="淡い背景に配置した緑の長方形の教材図">
  </picture>
</body>
</html>

これは構図の切替例であり、写真の圧縮効果を実証する例ではありません。同じ構図で解像度だけを変える場合は、幅の異なる画像と srcset、表示幅に合う sizes を用意する方法があります。画像の寸法を確保し、代替テキストはキーワードの列挙ではなく、その場で伝えている内容に合わせます。

画像の切替条件はMDNのpicture要素の説明でも確認できます。

初期画面より下で必要になる画像は遅延読込の候補になります。ただし、実際のスクロールやレイアウトで初期画面に入らないかを確認してから適用します。

JavaScript・CSS・配信方法のトレードオフ

機能を増やすと、取得だけでなく解析・実行や、実行中に操作を待たせるコストが増える場合があります。ファイルの容量だけを見ず、どの処理が初期表示や操作を妨げているかを調べます。

表が収まらない場合は、横にスクロールできます

deferは外部の通常スクリプトに使い、インラインスクリプトへ付けても効果はありません。モジュールはもともと遅延実行されるため、区別します。script要素の公式リファレンス

たとえば、初期HTMLに主画像があっても、巨大なCSSや長いJavaScript処理で表示を待つことがあります。LCPを、サーバー応答、資源取得開始までの待ち、取得時間、描画までの待ちに分けると、別の原因を画像圧縮だけで直そうとする誤りを減らせます。

前掲の公式LCPガイドも、SSRによる資源発見の利点と、サーバー処理時間とのトレードオフを説明しています。採用技術だけで速いと判断せず、対象ページと更新・運用の条件をそろえて比較します。

構造化データと内部リンクを、本文に対応させる

構造化データは、表示されている内容を機械に説明する補助情報です。以下は記事ページ向けのHTML内のデータ例です。JavaScriptとして実行するコードではありません。article-data.html として構造を確認でき、通信はしません。

<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <title>料金の読み方 | 教材</title>
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "料金の読み方",
    "author": { "@type": "Organization", "name": "教材編集部" },
    "datePublished": "2026-01-10",
    "dateModified": "2026-01-12"
  }
  </script>
</head>
<body>
  <article>
    <h1>料金の読み方</h1>
    <p>著者：教材編集部。公開2026年1月10日、更新2026年1月12日。</p>
    <p>見積もりに含まれる範囲と、追加になる条件を分けて確認します。</p>
  </article>
</body>
</html>

名称と日付は教材用の架空値です。公開時は実際の著者・内容・日付へ合わせ、記事ではないサービスページへ単にこの型を付けないでください。GoogleのArticle資料は理解や表示の手掛かりを説明するもので、検索表示の保証ではありません。Article構造化データ

内部リンクでは「こちら」だけでなく、「料金に含まれる範囲」「予約変更の手順」など、行き先を判断できる文言を使います。関連性のあるページへつなぎ、リンク切れや古い条件を残さないようにします。見出し・本文・リンク先の内容が一致しているかを、サイトの更新時にも確認します。

ECと企業サイトでの、統合した改善計画

EC：商品を比較して購入するまでを見る

ECでは、商品画像、比較情報、在庫、送料、返品条件、購入操作が一続きです。画像を軽くしても、条件が見つからなければ判断できません。ボタンを増やしても、操作の応答が遅ければ迷いが増えます。

次は計算を説明するための架空の前後比較です。実在サイトの成果や、速度改善による因果効果を示す数値ではありません。

表が収まらない場合は、横にスクロールできます

「15ポイント減」と「15%減」は異なります。母数が違う場合は件数も並べ、率だけで比較しません。実際の調査では、端末、観測期間、流入、商品の構成、販促、計測の定義を残します。同時に条件を変えた前後比較だけでは、何が効いたかは分かりません。

企業サイト：対象に合う相談までを見る

企業サイトでは、検索で見つけた人が提供範囲を読み、他社と比較し、問い合わせるまでを確認します。タイトルや説明の整備、見出しの整理、事例の条件、読み込み、フォームの操作を、同じ対象ページで点検します。

目標は自然検索の増加だけにせず、問い合わせの対象適合、記入の負担、返信できる体制まで含めます。相談が増えても対象外ばかりなら、文面や検索からの入口のずれを見直します。速度と内容を変える場合は変更日と変更箇所を記録し、改善率を先に約束しないでください。

数字を独立に確かめる

compare.mjs をNode.jsで実行すると、上の架空値の差を確認できます。これは統計的な有意差や因果効果を求めるコードではありません。

import assert from 'node:assert/strict';
function relativeChange(before, after) {
  if (!Number.isFinite(before) || before <= 0 || !Number.isFinite(after) || after < 0) {
    throw new RangeError('positive baseline and nonnegative result required');
  }
  return (after - before) / before * 100;
}
const close = (a, b) => assert.ok(Math.abs(a - b) < 1e-9);
close(relativeChange(4.5, 1.8), -60);
close(relativeChange(40, 25), -37.5);
close(relativeChange(2.5, 4.2), 68);
close(25 - 40, -15);
close(4.2 - 2.5, 1.7);
assert.throws(() => relativeChange(0, 1), RangeError);
console.log('架空の差分計算を確認しました');

5分の確認から、公開後の見直しへ

最初は重要な一ページで、次の問いを確認してください。すべてに答えられなくても、未確認の項目が次の作業になります。

1. 利用者が終えたいことを一文で言えるか。
2. タイトル、見出し、本文、リンク先がその目的に対応しているか。
3. 内容を読んで、適用条件や対象外を判断できるか。
4. 初期表示と操作で必要な資源が、後回しになっていないか。
5. 変更前後を、同じ単位と条件で観測する方法があるか。

実装前には基準となる内容と計測を保存し、実装後には必要な操作が残っているか、性能に悪化がないか、データが取れているかを確認します。公開後も、利用者の構成やコンテンツが変われば再確認が必要です。

この掲載例ではローカルのコード、HTML構造、図の内容を検証しています。実ブラウザでの表示や操作、検索順位、実ユーザーの性能は確認していません。自社への適用時は、PC・スマートフォン・キーボードなどでの操作確認と、現場の計測を別に行ってください。

制作の全体計画はWeb制作ガイド、性能の原因を深く調べる場合はWebパフォーマンスガイド、画面幅に応じた設計はレスポンシブ設計を参照できます。