Web制作・コーディング

Web制作にSEOを組み込む方法【2026年版】企画から運用まで全工程を解説

更新: 2026.07.26
Web制作にSEOを組み込む方法【2026年版】企画から運用まで全工程を解説

Web制作のプロジェクトで、SEOを後回しにしていませんか。「デザインとコーディングが終わってからSEO対策を考える」という進め方は、実は最も手戻りが大きく、コストがかさむアプローチです。URL構造やレンダリング方式のように、サイトの根幹に関わる決定ほど後から変更するのが難しく、公開後の後付けでは全ページの修正やリダイレクト設定に追われることになります。

本記事では、Web制作プロジェクトの企画から運用まで全5フェーズにSEOを組み込む具体的な方法を、コード例・チェックリスト・当サイト自身の運用実体験とともに解説します。2026年はAI OverviewsやAI Modeといった生成AI検索の存在感が増していますが、Googleは「生成AI検索のための特別な最適化は不要で、従来のSEOのベストプラクティスが土台になる」と公式に明言しています。つまり、制作段階から正しいSEO基盤を作る価値は、AI検索時代にむしろ高まっています。

なぜWeb制作の段階からSEOが必要なのか — 後付けSEOの限界

Web制作とSEOは本来、切り離せない関係にあります。しかし多くの企業では「まずサイトを作り、あとからSEO対策をする」というアプローチを取りがちです。この進め方がなぜ問題になるのかを、具体的に見ていきましょう。

後付けSEOのコストが膨らむ理由は、Webサイトの根幹に関わる部分ほど後からの変更が困難だからです。たとえばURL構造の変更は全ページのリダイレクト設定を伴い、サイト構造の見直しはナビゲーション全体の再設計につながります。セマンティックHTMLへの書き換えはテンプレート単位での修正が発生し、テスト工数も膨らみます。企画段階で決めておけば数行のルールで済むことが、公開後には全ページ規模の作業になる——これが「後付けは高い」と言われる正体です。

後付けSEOが特に問題となるのは、技術的負債が蓄積されるケースです。クライアントサイドレンダリング（CSR）のみで構築されたSPAサイトでは、検索エンジンのクローラーがコンテンツを正しく取得できないことがあります。この場合、SSR（サーバーサイドレンダリング）やSSG（静的サイト生成）への移行が必要となり、フレームワークの変更を含む大規模な改修が避けられません。

scale-basics.comの構築・運用でも、SEOを全フェーズに組み込む方針を採用してきました。実際に2026年7月にはサイト基盤をNext.js（SSG）からWordPressへ移行し、記事URLを/blog/記事名/から/記事名/へ変更しましたが、旧URLから新URLへ301リダイレクトを全記事分設定することで、インデックス面の問題を起こさずに移行を完了しています。この移行で計測したパフォーマンスの実測値や検証手順は、SEOに強いコーディングの実測レポートで公開しています。以下では、この経験も踏まえながら各フェーズの施策を具体的に解説します。

SEO対策の実施タイミングによる作業量の違い
対策項目 企画・設計段階から組み込む場合 公開後に後付けする場合 手戻りの大きさ
URL構造の最適化 設計時に命名規則を決めるだけ 全ページのURL変更＋301リダイレクト設定 大（サイト全体に影響）
セマンティックHTML コーディング規約に含める 全テンプレートの書き換え＋再テスト 大（テンプレート単位）
構造化データ テンプレートに組み込む 既存ページへの個別追加＋検証 中（ページ種別ごと）
Core Web Vitals対策 技術選定・設計時に考慮 パフォーマンスチューニング＋リファクタリング 大（設計に依存）
内部リンク構造 サイトマップ設計時に決定 ナビゲーション再設計＋実装 中（構造の再設計）

この表からわかるのは、どの項目も企画・設計段階なら軽微なルール決めで済むのに対し、後付けではサイト全体やテンプレート単位の改修になるという点です。だからこそ、Web制作プロジェクトの初期段階からSEOを織り込む意義があります。ここからは「企画」「設計」「実装」「公開」「運用」の5フェーズに分け、それぞれで実施すべきSEO施策を詳しく解説していきます。

フェーズ1：企画 — SEO戦略の土台を作る

Web制作プロジェクトの最初のフェーズである企画段階は、SEO戦略全体の方向性を決める最も重要な工程です。ここでの意思決定が、その後のすべてのフェーズに影響を与えます。企画段階で行うべきSEO施策は、大きくキーワードリサーチとサイト構造設計、そして競合分析の3つです。

キーワードリサーチとサイト構造設計

キーワードリサーチは、SEO戦略の出発点です。ターゲットユーザーがどのような言葉で検索しているかを把握し、それに基づいてサイト全体の構造を設計します。ここで重要なのは、単にキーワードの検索ボリュームを調べるだけでなく、検索意図（サーチインテント）を正確に理解することです。

たとえば「Web制作 SEO」で検索するユーザーは、Web制作プロジェクトにSEOをどう組み込むかという実践的な情報を求めています。一方、「SEO対策 やり方」で検索するユーザーは、SEO全般の基礎知識を求めている可能性が高いでしょう。同じSEO関連のキーワードでも検索意図が異なるため、それぞれに適したコンテンツとページ構成が必要です。

キーワード選定の完全マニュアルで解説しているとおり、具体的にはまずメインキーワードを決定し、そこから関連キーワードを洗い出していきます。ツールとしてはAhrefsやGoogleキーワードプランナーが定番です。2026年現在では、検索意図の分析をAIで補助するツールも増えており、より精度の高いキーワード戦略を立てやすくなっています。

キーワードリサーチの結果をもとに、サイト構造を設計します。ここで意識すべきは「トピッククラスター」の考え方です。メインとなるピラーページを中心に、関連するサブトピックのページを内部リンクでつなぐ構造を設計します。scale-basics.comの構築時にも、「SEO」という大テーマをピラーとし、「テクニカルSEO」「コンテンツSEO」「内部対策」「外部対策」といったサブトピックをクラスターとして配置しました。この設計により、サイト全体のトピックオーソリティが高まり、個々のページの評価にも好影響を与えます。クラスター内の導線をどう引くかは、SEO内部リンク戦略の設計と実装で具体的に解説しています。

サイト構造設計で失敗しやすいのが、階層を深くしすぎるパターンです。理想的には、トップページからどのページにも3クリック以内で到達できる構造が望ましいとされています。ディレクトリの深さは最大でも3階層（例：/category/subcategory/page/）に留めるのが目安です。これにより、クローラーが効率的にサイトを巡回でき、リンクによるページ評価も適切に分配されます。

競合分析の実施方法

競合分析は、自サイトが戦うべきフィールドと差別化ポイントを明確にするために欠かせない工程です。ここでの「競合」とは、ビジネス上の競合企業だけでなく、ターゲットキーワードの検索結果で上位に表示されているサイトすべてを指します。

競合分析でまず確認するのは、上位表示されているページのコンテンツの質と量です。どのような切り口で情報を提供しているか、どの程度の情報量か、どのような補足コンテンツ（図表・動画・インフォグラフィック）を使っているかを調べます。次に、競合サイトのページ表示速度、モバイル対応、構造化データの実装有無などの技術的側面を、PageSpeed InsightsやScreaming Frogで分析します。技術的に劣っている部分があれば、それだけで差別化のチャンスになります。

また、被リンクのプロファイルも重要な分析対象です。競合がどのようなサイトからリンクを獲得しているかを調べることで、自サイトのリンクビルディング戦略の参考になります。競合分析の結果はスプレッドシートなどにまとめ、各サイトの強みと弱みを一覧化しておくと、自サイトが注力すべきポイントが明確になります。

フェーズ2：設計 — SEOを織り込んだ情報設計

企画フェーズでSEO戦略の方向性が決まったら、次は具体的な設計に落とし込みます。設計フェーズでは、URL設計、ワイヤーフレームへのSEO要素の組み込み、そして技術選定という3つの重要なタスクがあります。

URL設計のベストプラクティス

URL設計はSEOにおいて見落とされがちですが、検索エンジンとユーザーの双方にとって重要な要素です。適切に設計されたURLは、ページの内容を端的に伝え、クリック率の向上にも寄与します。GoogleのSEOスターターガイドでも、シンプルなURL構造が推奨されています。

URL設計の基本原則は「短く、わかりやすく、意味のある」URLを心がけることです。具体的には、英単語をハイフンで区切る（アンダースコアではなくハイフン）、パラメータやセッションIDなど不要な文字列を含めない、日本語URLは文字化けのリスクがあるため英語（ローマ字）表記を基本とする、カテゴリ構造とURLのディレクトリ構造を一致させる、といった点を意識します。

悪い例は「example.com/page?id=123&cat=4」のような動的パラメータが露出したURLや、「example.com/2026/03/15/post-title」のように日付がURLに含まれるブログ形式（エバーグリーンコンテンツには不向き）です。良い例は「example.com/web-seo/」のように、コンテンツの内容を端的に表す構造です。

また、URLの正規化も設計段階で決定しておくべきです。www有無、末尾スラッシュの有無、httpとhttpsの統一など、正規URLのルールを策定し、canonicalタグやリダイレクトの方針を決めておきます。これを後から統一しようとすると大量のリダイレクト設定が必要になり、まさに後付けSEOのコスト増の典型例になります。ケース別の判断基準はcanonicalタグによるURL正規化の詳細ガイドで掘り下げています。

ワイヤーフレームにSEO要素を組み込む

ワイヤーフレームの段階でSEO要素を組み込むことは、デザインとSEOの両立を図るうえで非常に効果的です。デザインが固まってから「ここにh1タグを入れたい」「パンくずリストを追加したい」と言っても、レイアウト変更が必要になるケースがあります。

ワイヤーフレームに必ず含めるべきSEO要素として、まずh1タグの配置位置があります。h1はページ最上部、ファーストビュー内に配置するのが基本です。次にパンくずリストの配置です。パンくずリストはユーザビリティとSEOの両面で効果があり、ヘッダー直下に配置するのが一般的です。

さらに、メインコンテンツエリアとサイドバーの区分けも重要です。検索エンジンはメインコンテンツとサブコンテンツを区別してページを評価するため、HTML構造上もmain要素とaside要素を適切に使い分ける必要があります。内部リンクの配置エリア（関連記事セクションなど）もワイヤーフレームの段階で設計しておくことで、後工程での手戻りを防げます。CTAボタンやフォームの配置もユーザーの滞在時間やエンゲージメントに影響し、間接的にSEO評価に関わります。

技術選定とSEOの関係（SSG/SSR/CSR比較）

2026年現在のWeb制作において、フロントエンドの技術選定はSEOに直接的な影響を与えます。特にレンダリング方式の選択は、検索エンジンがコンテンツをどのように取得・評価するかに関わる重要な意思決定です。基盤となるテクニカルSEOの考え方はテクニカルSEO完全ガイドにまとめています。

レンダリング方式のSEO比較（2026年版）
項目 SSG（静的サイト生成） SSR（サーバーサイドレンダリング） CSR（クライアントサイドレンダリング）
SEO適性 非常に高い 高い 低い（改善可能）
表示速度 最速（CDN配信） 速い（サーバー処理あり） 初回表示は遅い
Core Web Vitals LCP・INP・CLSすべて優秀 LCPはサーバー性能に依存 LCP・INPが課題になりやすい
クローラビリティ 完全なHTMLを提供 完全なHTMLを提供 JSの実行が必要
動的コンテンツ対応 ISRやOn-Demand Revalidationで対応可 リアルタイムに対応 リアルタイムに対応
代表的なフレームワーク Next.js (SSG), Astro, Hugo Next.js (SSR), Nuxt.js React SPA, Vue SPA
適しているサイト種別 コーポレートサイト、ブログ、LP ECサイト、会員制サイト 管理画面、ダッシュボード

scale-basics.comでは現在、WordPressをベースにキャッシュ最適化とCDN配信を組み合わせた構成を採用しています。選定理由は3つあります。第一に、コンテンツ中心のサイトのためキャッシュを効かせれば動的CMSでも高いパフォーマンスを確保できること。第二に、CDN配信により高速な表示が可能であること。第三に、WordPressの豊富なエコシステムを使えば記事の追加や構造化データの自動生成にも柔軟に対応できることです。当サイトの実測（2026年7月計測）ではTTFB平均0.19秒（curlによる3回計測）を記録しており、動的CMSでもキャッシュとCDNを組み合わせれば十分に速い応答が得られることを確認しています。

一方、CSRのみのSPAサイトを選択した場合、Googlebotはレンダリングキューに入ってからJavaScriptを実行するため、インデックスまでに時間がかかることがあります。また、Google以外の検索エンジンやSNSのクローラーはJavaScriptの実行能力が限定的な場合があり、コンテンツが正しく取得されないリスクがあります。さらにGoogleが2026年3月に公開したクロールの解説では、Googlebotが取得するHTMLはHTTPヘッダー込みで先頭2MBまでで、それを超えた部分はインデックス処理に渡されないことが明らかにされました。JavaScriptで後から描画されるコンテンツや、肥大化したHTMLは検索エンジンに届かないリスクがあるということです。詳細はGooglebotの「2MBの壁」を解説したニュース記事を参照してください。技術選定の段階で、コンテンツが確実にHTMLとして届く方式を選ぶことが、クローラビリティの土台になります。

フェーズ3：実装 — SEOに強いコードを書く

設計フェーズで策定した方針を、実際のコードに落とし込むのが実装フェーズです。ここでは、SEOに強いコーディングを実現するための具体的な手法を、コード例とともに解説します。

セマンティックHTMLの実装

セマンティックHTMLとは、HTMLタグが持つ意味（セマンティクス）を正しく活用したマークアップのことです。検索エンジンはHTMLの構造を解析してページの内容を理解するため、適切なセマンティックHTMLは検索エンジンの理解度を高めます。SEO対策に必須のHTMLタグを正しく使うことはSEOの基本ですが、実際の制作現場ではdivタグの多用やセマンティクスを無視したマークアップが後を絶ちません。以下に、よくある問題パターンとその改善例を示します。

【Before：セマンティクスを無視したマークアップ】

<!-- 悪い例：すべてdivで構成 -->
<div class="header">
  <div class="logo">サイト名</div>
  <div class="nav">
    <div class="nav-item"><a href="/">ホーム</a></div>
    <div class="nav-item"><a href="/about">会社概要</a></div>
    <div class="nav-item"><a href="/service">サービス</a></div>
  </div>
</div>
<div class="main">
  <div class="title">ページタイトル</div>
  <div class="content">
    <div class="section">
      <div class="section-title">セクション見出し</div>
      <div class="text">本文テキスト...</div>
    </div>
  </div>
  <div class="sidebar">
    <div class="widget">サイドバーコンテンツ</div>
  </div>
</div>
<div class="footer">
  <div class="copyright">&copy; 2026 Company</div>
</div>

【After：セマンティックHTMLを活用したマークアップ】

<!-- 良い例：セマンティックHTMLを適切に使用 -->
<header>
  <a href="/" class="logo">サイト名</a>
  <nav aria-label="メインナビゲーション">
    <ul>
      <li><a href="/">ホーム</a></li>
      <li><a href="/about">会社概要</a></li>
      <li><a href="/service">サービス</a></li>
    </ul>
  </nav>
</header>
<main>
  <article>
    <h1>ページタイトル</h1>
    <section>
      <h2>セクション見出し</h2>
      <p>本文テキスト...</p>
    </section>
  </article>
  <aside aria-label="サイドバー">
    <section>
      <h2>関連情報</h2>
      <p>サイドバーコンテンツ</p>
    </section>
  </aside>
</main>
<footer>
  <p><small>&copy; 2026 Company</small></p>
</footer>

After版では、header、nav、main、article、section、aside、footerといったセマンティック要素を適切に使用しています。これにより検索エンジンはページ構造を正確に理解でき、各セクションの役割を判別できます。navにaria-label属性を付与することで、アクセシビリティとSEOの両方を向上させています。

見出しタグ（h1〜h6）の使い方にも注意が必要です。h1はページ内で1つのみ使用し、h2、h3と論理的な階層構造を維持します。見出しレベルを飛ばす（h2の直下にh4を置くなど）のは避けましょう。見出しの階層構造は、検索エンジンがコンテンツの構造を理解するための重要な手がかりです。

マークアップの品質は、W3CのNu HTML Checkerのような検証ツールで機械的に確認できます。参考として、当サイトの実測（2026年7月計測）では、Nu HTML Checkerで検出されたエラー10件はすべてWordPressテーマ由来で、記事コンテンツ由来のエラーは0件でした。また、コピペで使えるSEO対策済みHTMLテンプレートを活用すれば、プロジェクトの初期段階から正しいセマンティック構造を確保でき、チーム全体のコーディング品質を統一できます。

構造化データの実装

構造化データは、ページの内容を検索エンジンに明示的に伝えるための仕組みです。JSON-LD形式で記述し、Googleのリッチリザルト（検索結果の拡張表示）を獲得するために活用します。2026年現在、構造化データやセマンティックなマークアップは、AI OverviewsやAI Modeといった生成AI検索が情報を理解・引用する土台としても機能します。

ただし、注意したい前提があります。Googleは2026年5月の公式ガイドで、生成AI検索のために特別なファイルやタグ（llms.txtの設置やコンテンツのチャンク化など）を用意する必要はなく、従来のSEOのベストプラクティスがそのまま土台になると明言しています。つまり、本記事で扱う構造化データやセマンティックHTMLといった基本のマークアップこそが、AI検索でも評価される近道です。この点の詳細はGoogleの生成AI検索最適化ガイド公開を報じた解説記事で整理しています。

Web制作サイトで実装すべき主な構造化データには、Organization（組織情報）、BreadcrumbList（パンくずリスト）、Article（記事ページ）、FAQPage（よくある質問）、LocalBusiness（地域ビジネス）などがあります。以下は、実際のBefore/After形式での実装例です。

【Before：構造化データなしのページ】

<head>
  <title>Web制作会社のサービス紹介 | 株式会社Example</title>
  <meta name="description" content="Web制作会社のサービス紹介ページです。">
</head>
<body>
  <nav>
    <a href="/">ホーム</a> &gt; <a href="/service/">サービス</a> &gt; Web制作
  </nav>
  <h1>Web制作サービス</h1>
  <p>当社のWeb制作サービスについて紹介します。</p>
</body>

【After：構造化データを追加したページ】

<head>
  <title>Web制作会社のサービス紹介 | 株式会社Example</title>
  <meta name="description" content="Web制作会社のサービス紹介ページです。">
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Organization",
    "name": "株式会社Example",
    "url": "https://example.com",
    "logo": "https://example.com/images/logo.png",
    "sameAs": [
      "https://twitter.com/example",
      "https://www.facebook.com/example"
    ]
  }
  </script>
  <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/service/"
      },
      {
        "@type": "ListItem",
        "position": 3,
        "name": "Web制作"
      }
    ]
  }
  </script>
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Service",
    "name": "Web制作サービス",
    "provider": {
      "@type": "Organization",
      "name": "株式会社Example"
    },
    "description": "SEOに強いWeb制作サービスを提供します。",
    "areaServed": "JP"
  }
  </script>
</head>
<body>
  <nav aria-label="パンくずリスト">
    <ol>
      <li><a href="/">ホーム</a></li>
      <li><a href="/service/">サービス</a></li>
      <li>Web制作</li>
    </ol>
  </nav>
  <h1>Web制作サービス</h1>
  <p>当社のWeb制作サービスについて紹介します。</p>
</body>

After版では、Organization、BreadcrumbList、Serviceの3種類の構造化データをJSON-LD形式で追加しています。構造化データマークアップの実装方法について詳しく学びたい方は、別記事で体系的に解説しています。実装後は、Googleのリッチリザルトテストツールで正しくマークアップされているかを検証し、エラーや警告がないことを確認してから本番環境に反映しましょう。

Core Web Vitals最適化

Core Web Vitalsは、Googleが定めるユーザー体験の指標であり、2021年から検索ランキング要因として組み込まれています。2026年時点の最新指標は、LCP（Largest Contentful Paint）、INP（Interaction to Next Paint）、CLS（Cumulative Layout Shift）の3つです。なお、FID（First Input Delay）は2024年3月にINPへ正式に置き換えられ、現在は評価に使われていません。各指標の目標値と最適化手法はweb.devのCore Web Vitals解説が一次情報です。

LCPはページのメインコンテンツが表示されるまでの時間で、2.5秒以内が良好とされます。LCP改善には画像の最適化が最も効果的です。次世代フォーマット（WebP/AVIF）の採用、適切なサイズ指定、そしてlazy loadingの活用（ただしファーストビューの画像には適用しない）が基本的な対策です。以下に画像最適化のBefore/After例を示します。

【Before：最適化されていない画像実装】

<!-- 悪い例 -->
<img src="/images/hero-image.png">

【After：SEOとパフォーマンスを考慮した画像実装】

<!-- 良い例 -->
<picture>
  <source srcset="/images/hero-image.avif" type="image/avif">
  <source srcset="/images/hero-image.webp" type="image/webp">
  <img
    src="/images/hero-image.jpg"
    alt="Web制作プロジェクトのワークフロー図"
    width="1200"
    height="630"
    loading="eager"
    fetchpriority="high"
    decoding="async"
  >
</picture>

After版では、AVIF・WebPフォーマットをpicture要素で提供し、width/height属性を明示してレイアウトシフト（CLS）を防止しています。ファーストビューのヒーロー画像のため、loading属性をeager、fetchpriority属性をhighに指定して優先的に読み込ませています。alt属性にはキーワードを自然に含めた説明文を設定し、画像SEOにも配慮しています。

INPはユーザーの操作（クリック、タップ、キー入力）に対するレスポンスの速さを計測する指標で、200ミリ秒以内が良好とされます。改善には、メインスレッドをブロックする重いJavaScript処理の最適化が鍵です。具体的には、長時間実行タスクの分割、不要なサードパーティスクリプトの削減、イベントハンドラの最適化が効果的です。CLSはページ読み込み中のレイアウトのズレを計測する指標で、0.1以下が良好とされます。主な原因はサイズ未指定の画像・動画、動的に挿入されるコンテンツ、Webフォントの読み込みによる再描画です。画像・動画にはwidth/height属性を必ず指定し、動的コンテンツには事前にスペースを確保しておくのが対策の基本です。

これらの最適化は、設計・技術選定の段階で基盤を整えておくほど効果が出やすくなります。当サイトでも旧構成時に、クリティカルCSSのインライン化などの改善でLCPを3.2秒から1.8秒へ短縮した実績があります（当サイトの実測、2026年7月計測。手順の詳細は前掲のSEOに強いコーディングで公開）。HTMLとリソース読み込みを整理するだけでも、指標は大きく動きます。

フェーズ4：公開 — 検索エンジンに正しく認識させる

コーディングが完了し、テストを経てサイトを公開する段階では、検索エンジンにサイトを正しく認識・インデックスしてもらうための設定が必要です。このフェーズを怠ると、せっかくSEOを意識して作ったサイトが検索結果に反映されないという事態になりかねません。

公開時の必須設定

まず、robots.txtの設置です。robots.txtはクローラーに対してサイトのクロールポリシーを伝えるファイルで、サイトのルートディレクトリに配置します。クロールさせたくないディレクトリ（管理画面、テスト環境など）を指定するとともに、sitemap.xmlのURLを記載します。ただし、robots.txtのDisallowはインデックスを完全に防ぐものではない点に注意が必要です。インデックスを確実に防ぎたいページには、noindexメタタグを併用しましょう。

次に、sitemap.xmlの作成と送信です。sitemap.xmlは、インデックスさせたいページをリストアップしたXMLファイルで、各ページのURL・最終更新日（lastmod）などを記載します。WordPressやNext.jsなど主要なCMS・フレームワークでは自動生成の機能やプラグインが用意されています。なお、lastmodの扱いには注意が必要です。Googleは2026年7月、lastmodが不正確なくらいならいっそ書かない方がよいという見解を示しました。lastmodは「意味のある更新をしたとき」だけ正しく更新すべきシグナルであり、CMSの都合で全ページが毎日更新されているような状態はかえって信頼されません。詳しくはXMLサイトマップのlastmodに関するGoogleの見解を報じたニュース記事を参照してください。

そして、Google Search Console（GSC）へのサイト登録です。GSCはGoogleが提供する無料のツールで、サイトの検索パフォーマンスを確認し、問題点を把握するために不可欠です。登録後はsitemap.xmlを送信し、インデックスカバレッジ（どのページがインデックスされているか）を確認します。

公開直後に確認すべき事項は次のとおりです。SSL証明書が正しく設定されhttpsでアクセスできること、httpからhttpsへの301リダイレクトが設定されていること、wwwありとなしが統一されていること、canonicalタグが全ページに設定されていること、title・descriptionのメタタグが全ページに設定されていること、OGP（Open Graph Protocol）タグが設定されていること、ファビコンが設定されていること、404ページがカスタマイズされていること。これらを一つずつ確認します。

リニューアル時のリダイレクト設計

既存サイトのリニューアルではURL構造が変わるケースが多いため、301リダイレクトの設計が極めて重要です。リダイレクトが適切に設定されていないと、旧URLで獲得していた被リンクの評価が失われ、検索順位が大幅に低下するリスクがあります。301リダイレクトと302リダイレクトの使い分けについてはリダイレクトの種類と設定方法の完全ガイドで詳しく解説しています。

リダイレクト設計の手順としては、まず旧サイトの全URLリストを作成します（Screaming FrogでのクロールやGSCからのURL取得）。次に旧URLと新URLのマッピング表を作成し、すべての旧URLに対応する新URLを決定します。対応するページがない場合は、最も関連性の高いページへリダイレクトします。リダイレクトチェーン（2回以上の連鎖）は避け、旧URLから新URLへの直接リダイレクトを設定しましょう。

実装方法はサーバー環境によって異なり、Apacheでは.htaccess、Nginxではnginx.conf、Next.jsではnext.config.jsのredirects設定を使います。参考として、Apache環境で個別URLと配下ディレクトリをまとめて301リダイレクトする.htaccessの例を示します。

# 旧個別URL → 新個別URL（301恒久リダイレクト）
Redirect 301 /blog/web-seo/ https://example.com/web-seo/

# 旧ディレクトリ配下をまとめて新ディレクトリへ（RewriteRule）
RewriteEngine On
RewriteRule ^blog/(.*)$ /$1 [R=301,L]

この設計は、当サイト自身の移行でも実践しました。scale-basics.comは2026年7月にNext.js（SSG）からWordPressへ基盤を移行し、記事URLを/blog/記事名/から/記事名/へ変更しています。このとき旧URLから新URLへの301リダイレクトを全記事分設定し、canonicalは新URLに統一しました。結果として、移行にともなうインデックスの問題は発生していません。URL構造を変更する場面では、301リダイレクトとcanonicalを併用して「正規のURLはどれか」を一貫して伝えることが実務上の要点です。リニューアル後は必ずGSCの「URL検査」で重要ページが正しくインデックスされているかを確認し、インデックスカバレッジレポートで意図しない除外がないかも定期的にチェックしましょう。

フェーズ5：運用 — 継続的なSEO改善

サイトを公開して終わりではなく、SEOは継続的な運用が成果を左右します。コンテンツSEOの取り組みも含め、PDCAサイクルを回しながら改善を続けていくことが、長期的な検索順位の向上につながります。

月次SEO運用タスク

SEO運用を効率的に進めるためには、月次で実施するタスクを明確に定義し、ルーティン化することが重要です。以下に、月次で実施すべきタスクの全体像を整理します。

第一に、検索パフォーマンスの分析です。GSCの検索パフォーマンスレポートで、表示回数、クリック数、CTR、平均順位の推移を把握します。特にCTRが低いのに表示回数が多いキーワードは、タイトルタグやmeta descriptionの改善で成果を得やすい候補です。2026年は、通常の検索に加えてAI検索での露出も観測できるようになりました。Googleは同年6月、Search Consoleに生成AIパフォーマンスレポートを追加し、AI OverviewsやAI Mode、Discoverの生成AI機能で自サイトのURLが表示された回数を計測できるようにしています（まずは一部サイトへの段階提供）。これは順位を変える機能ではなく見え方を可視化する計測ツールですが、どのページがAI検索で拾われているかを把握する入口になります。詳細はSearch Consoleの生成AIパフォーマンスレポート解説記事にまとめています。

第二に、コンテンツの更新です。情報が古くなったページを最新化し、新しいキーワードやトレンドに合わせてコンテンツを追加します。Googleは鮮度（フレッシュネス）を評価する傾向があるため、定期的な更新は順位の維持・向上に効果的です。第三に、テクニカルSEOの監視です。GSCのインデックスカバレッジレポートでクロールエラーやインデックスの問題を確認し、PageSpeed InsightsでCore Web Vitalsのスコアを定期計測します。第四に、被リンクの分析です。新規・喪失した被リンクを確認し、不自然なリンクが増えていないかもチェックします。第五に、競合の動向監視です。ターゲットキーワードでの競合の順位変動を把握し、競合が新しく上位表示しているコンテンツがあれば自サイトと比較分析します。

PDCAサイクルの回し方

SEO運用でPDCAサイクルを効果的に回すには、具体的な数値目標とアクションプランを設定することが不可欠です。漠然と「検索順位を上げたい」では改善が進みません。

Plan（計画）では、現状分析に基づいて改善の優先順位を決めます。たとえば「商品ページAの『Web制作 費用』での順位を15位から5位以内に上げる」といった具体的な目標を設定し、必要な施策（コンテンツの充実、内部リンクの強化、構造化データの追加など）を洗い出してスケジュール化します。Do（実行）では、計画した施策を一つずつ実行します。複数の施策を同時に実施しすぎると、どの施策が効いたか判別が難しくなるため、可能な限り1つずつ効果を測定してから次へ進むのが理想です。

Check（検証）では、施策実施後2〜4週間の期間を置いて効果を測定します。検索順位、オーガニックトラフィック、CTR、コンバージョン率への影響などを多角的に分析します。GSCのデータは集計に数日のタイムラグがあるため、十分にデータが蓄積されてから分析しましょう。Act（改善）では、検証結果をもとに次のアクションを決めます。効果があった施策は他ページへ横展開し、効果が薄かった施策は原因を分析して修正するか別のアプローチに切り替えます。この結果が次のPlanへのインプットとなり、サイクルが継続的に回っていきます。

ここで注意したいのが、インデックス状況の読み方です。GSCで「クロール済み-未インデックス」が多発した場合、まず技術的な不具合を疑いがちですが、Googleは「技術要因が見当たらないのに多くのページがインデックスされないなら、一歩下がってサイト全体の品質を見直すべき」と説明しています。薄い量産ページを増やすより、一次情報や独自の視点を持つ価値あるページに資源を集中する方が、結果的にインデックスにも順位にも効くという考え方です。scale-basics.comの運用でも、月次レポートのテンプレートを用意し、毎月決まったタイミングでデータを集計・分析する仕組みを整えることで、順位変動やトラフィックの推移を継続的にモニタリングし、迅速に施策を打てる体制にしています。

Web制作×SEO 全フェーズ統合チェックリスト

ここまで解説してきた5つのフェーズの施策を、一覧表としてまとめました。Web制作プロジェクトの各段階で、このチェックリストを参照しながらSEO施策の抜け漏れを防ぎましょう。

Web制作プロジェクト SEO統合チェックリスト
フェーズ 施策カテゴリ チェック項目 重要度 担当
企画 キーワード戦略 メインキーワード・サブキーワードの選定完了 必須 SEO担当 / ディレクター
検索意図の分析・分類完了 必須 SEO担当
キーワードマッピング（URL×KW対応表）の作成 必須 SEO担当 / ディレクター
競合分析 検索上位サイトのコンテンツ分析完了 必須 SEO担当
競合の技術面（速度・構造化データ等）の調査完了 推奨 SEO担当 / エンジニア
差別化ポイントの明確化 推奨 ディレクター
設計 URL設計 URL命名規則の策定 必須 エンジニア / SEO担当
URL正規化ルールの決定（www、末尾スラッシュ、https） 必須 エンジニア
情報設計 サイト構造図の作成（3クリック以内のアクセス性） 必須 ディレクター / デザイナー
ワイヤーフレームへのSEO要素の組み込み（h1、パンくず等） 必須 デザイナー / SEO担当
技術選定 レンダリング方式の決定（SSG/SSR/CSR） 必須 エンジニア
ホスティング・CDNの選定 推奨 エンジニア
実装 HTML/コーディング セマンティックHTMLの使用（header, main, nav, article等） 必須 エンジニア
見出しタグの階層構造が正しいか 必須 エンジニア
画像のalt属性・width/height属性の設定 必須 エンジニア
構造化データ JSON-LDでの構造化データ実装 必須 エンジニア
リッチリザルトテストでの検証 必須 エンジニア / SEO担当
パフォーマンス LCP 2.5秒以下の達成 必須 エンジニア
INP 200ms以下の達成 必須 エンジニア
CLS 0.1以下の達成 必須 エンジニア
公開 検索エンジン対応 robots.txtの設置と内容確認 必須 エンジニア
sitemap.xmlの生成と送信（lastmodは正確な場合のみ） 必須 エンジニア
Google Search Consoleへの登録 必須 SEO担当 / エンジニア
リダイレクト・正規化 301リダイレクトの設定（リニューアル時） 必須 エンジニア
canonicalタグの全ページ設定確認 必須 エンジニア / SEO担当
https化とリダイレクト確認 必須 エンジニア
運用 月次タスク GSCでの検索パフォーマンス確認（AI検索の表示回数含む） 必須 SEO担当
Core Web Vitalsスコアの定期計測 必須 エンジニア / SEO担当
インデックスカバレッジの確認 必須 SEO担当
改善施策 コンテンツの定期更新・リライト 推奨 ライター / SEO担当
内部リンク構造の見直し 推奨 SEO担当
被リンク分析と獲得施策の実施 推奨 SEO担当 / マーケ

このチェックリストは、Web制作プロジェクトの規模や種類に応じてカスタマイズして使用してください。コーポレートサイトとECサイトでは重要度の優先順位が異なる場合がありますし、新規構築とリニューアルでも必要な施策が変わります。重要なのは、各フェーズでSEOの視点を漏れなく取り入れることです。

まとめ

本記事では、Web制作プロジェクトにSEOを組み込む方法を、企画・設計・実装・公開・運用の5フェーズに分けて解説しました。各フェーズの要点を振り返ります。

企画フェーズでは、キーワードリサーチと検索意図の理解、トピッククラスターを意識したサイト構造設計がSEO成功の土台になります。競合分析で差別化ポイントを明確にし、戦略の方向性を定めましょう。設計フェーズでは、URL設計の原則を守り、ワイヤーフレームの段階からh1やパンくずリストなどのSEO要素を組み込みます。技術選定では、コンテンツが確実にHTMLとして検索エンジンに届く方式を選び、Core Web Vitalsの基盤を整えます。

実装フェーズでは、セマンティックHTML、構造化データ、Core Web Vitalsの最適化が三本柱です。Before/Afterで示したように、コードレベルの細かな改善が積み重なって効果を生みます。公開フェーズでは、robots.txt・sitemap.xmlの設置、Google Search Consoleへの登録といった基本設定を確実に行い、リニューアル時は301リダイレクトとcanonicalで既存の検索評価を新サイトへ引き継ぎます。運用フェーズでは、月次タスクをルーティン化し、PDCAサイクルを回し続けることが長期的な成果につながります。

後付けSEOは、サイトの根幹に関わる部分ほど手戻りが大きく、コストがかさみます。企画段階からSEOを全工程に織り込むことで、コストを抑えながら最大の効果を得られます。2026年はAIによる検索体験の変革が進んでいますが、Googleが明言するとおり、生成AI検索でも評価の土台になるのはセマンティックHTML・構造化データ・高速な表示速度といった従来からの基盤です。この記事のチェックリストとフレームワークを活用し、AI検索時代にも通用するSEOに強いWebサイトを構築してください。

執筆根拠: 本記事は2026年7月時点の情報に基づき、Google検索セントラルの公式ドキュメント・公式ブログ（SEOスターターガイド、Googlebotのクロール仕様、生成AI検索の最適化ガイド、XMLサイトマップlastmodに関する見解、Search Consoleの生成AIパフォーマンスレポート発表）、web.devのCore Web Vitals解説、および当サイトの実測データ（2026年7月計測。Next.js→WordPress移行時の301リダイレクト運用、TTFB平均0.19秒、LCP 3.2秒→1.8秒、W3C Nu HTML Checkerのエラー内訳。詳細はSEOに強いコーディングの実測レポート参照）をもとに執筆しています。数値は上記の一次情報および当サイト実測の範囲に限定し、出典のない統計は使用していません。

scale-basics編集部
監修

scale-basics編集部

SEO・AI検索最適化（AIO/LLMO/GEO）・Web制作の最前線で活動する専門チーム。テクニカルSEOからコンテンツ戦略、データ分析まで幅広い実務経験をもとに、最新のナレッジと実践的なノウハウを発信しています。

編集部について詳しく見る →

関連記事