「公開後にSEO改善をやりましょう」と開発会社に依頼したら、「URL構造は今のままでは変更できません」「CMSがmeta設定に対応していないので追加開発が必要です」「表示速度を上げるには大規模なリファクタが必要で、別途お見積りになります」と返ってきた——。Webサイトのリニューアルや新規構築を経験した発注担当者なら、似たやり取りに心当たりがあるはずです。
この問題の根本原因は、技術力でも費用感でもなく、要件定義段階でSEOを織り込まなかったことにあります。SEOは公開後に追加できる施策と思われがちですが、URL設計やレンダリング方式といったテクニカルSEOの大半は、要件定義の意思決定によって良くも悪くも"固まって"しまいます。
とはいえ、SEOの専門家ではない発注担当者が要件定義書にSEOをどう書き込めばよいのか、判断材料は意外と少ないものです。検索しても出てくるのは「SEOで気をつけるべき15のこと」のような一般論ばかりで、「では明日の打ち合わせで開発会社に何を伝えればよいのか」という疑問には答えてくれません。
本記事では、システム開発の要件定義書に書き込むべきSEO要件を、機能要件・非機能要件・運用要件の3つに分けて整理します。後からでは変更困難な要素・追加費用が発生しやすい項目・契約書で押さえるべき条項を明示し、開発会社との打ち合わせでそのまま使える質問テンプレートと、要件定義書のサンプル記述例まで掲載します。
読み終えたあと、次回の打ち合わせで「URL構造はこの方針で」「Core Web Vitals は LCP 2.5秒以内を非機能要件に入れたい」と具体的に発言できる状態になることを目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
なぜシステム開発の要件定義にSEOを含めるべきか
「SEOは公開後にSEO会社へ依頼すればよい」という発想は、半分は正しく半分は危険です。コンテンツ施策（記事制作・キーワード最適化など）は確かに公開後でも積み上げられますが、テクニカルSEOの根幹はシステム構造そのものに依存します。要件定義の段階で意思決定を誤ると、公開後にどれだけ費用をかけても挽回できない領域が生まれてしまいます。
「公開後にSEOができない」と言われる3つの典型パターン
実際に発注者が直面しやすい後悔パターンは、大きく次の3つに分類できます。
- URL構造を変更できない: ディレクトリ構造とCMSのスラッグ命名規則が密結合になっており、SEOコンサルから「カテゴリURLを再設計したい」と提案されても、CMS全体を作り変える必要があると判明する
- meta情報を動的に出し分けられない: CMSのテンプレート機能でタイトル・descriptionの個別最適化ができず、全ページが同一のタイトルパターンになる。記事ごとの最適化に追加開発が必要
- JavaScript過剰でクロールが阻害される: SPA構成で重要なコンテンツがクライアントサイドレンダリングされており、Googleがコンテンツを認識できない／インデックスが極端に遅い
これらはいずれも「公開してから気づく」典型例です。リリース直後はアクセスが少なく問題が顕在化しないため、半年後・1年後にSEO投資を始めた段階で初めて致命的な制約として顔を出します。
後からの修正コストが要件定義段階の数十倍になる理由
ソフトウェア開発の世界では、要件定義段階で見つけたバグの修正コストを「1」とすると、設計段階では「3〜6」、実装段階では「10」、運用段階では「100以上」になると言われます（バリー・ベーム氏のソフトウェアエンジニアリング経済学に基づく古典的知見）。
SEO要件も同じです。要件定義書に「URL構造は /category/article-slug/ 形式とする」と1行書き加えるコストはほぼゼロですが、運用開始後にURL構造を変更するとなると、リダイレクト設計・既存被リンクの引き継ぎ・サイトマップ再生成・検索順位の一時的な低下リスクまでセットで対応することになります。
SEOは「機能要件」ではなく「設計制約」として扱うべき
もう一つ重要な視点が、SEOは画面や機能と並列の「やること」ではなく、システム全体に通底する「設計制約」だということです。
機能要件として「SEO対策機能」を1項目立てるだけでは不十分で、「全ページのURL設計」「すべてのHTML出力」「画像配信の方式」「JSのロード戦略」といったシステム全体に横断する観点として要件定義書に組み込む必要があります。詳しい要件定義書の書き方については要件定義書の書き方とテンプレートも参考にしてください。
SEOとシステム開発の関係｜テクニカルSEOが開発要件である理由
SEOとシステム開発の関係を整理するうえで、まず押さえておきたいのが「SEOの内訳」です。SEOは大きく3つの領域に分かれており、それぞれの担当者と関与タイミングが異なります。
コンテンツSEO／テクニカルSEO／外部SEOの3分類と担当領域
分類 | 内容 | 主な担当 | 開発フェーズへの依存度 |
|---|---|---|---|
コンテンツSEO | キーワード設計・記事制作・E-E-A-T強化 | マーケ担当・SEOコンサル・ライター | 低（CMSが対応していれば公開後に積み上げ可） |
テクニカルSEO | URL構造・レンダリング・表示速度・構造化データ・sitemap・robots | システム開発会社 | 高（要件定義段階で固まる） |
外部SEO | 被リンク獲得・SNS拡散・PR | マーケ担当・広報 | 低（システムにほぼ依存しない） |
このうち、要件定義段階で意思決定すべきはほぼテクニカルSEOです。コンテンツSEOと外部SEOは公開後にも自由度がありますが、テクニカルSEOは「どう作るか」を決める段階で大半が決まってしまいます。
テクニカルSEOが開発フェーズに依存する理由
なぜテクニカルSEOが開発フェーズに強く依存するのか。それは、検索エンジンに評価される技術要素の多くが「アーキテクチャ選定」「フレームワーク選定」「CMS選定」の段階で決まる構造的制約だからです。
具体的には次のような項目です。
- レンダリング方式: SSR（サーバーサイドレンダリング）／SSG（静的サイト生成）／CSR（クライアントサイドレンダリング）の選択
- URL設計の自由度: CMSのルーティング機構・パス命名規則の制約
- meta情報のテンプレート機能: ページ種別ごとに動的にtitle/descriptionを生成できるか
- 構造化データの埋め込み: JSON-LDをHTMLに動的出力できるか
- インフラ性能: CDN利用・画像最適化サーバー・キャッシュ戦略
これらはすべて「公開後に追加機能で対応する」のではなく、「最初からその機能を備えたアーキテクチャで作る」べき要素です。
SEOコンサル会社と開発会社の連携設計
ここで発注者が悩むのが、「誰が要件を策定し、誰が実装するのか」という役割分担です。
理想的な連携は次のような構造です。
- SEOコンサル会社（または発注者自身）が「何を実現したいか」のSEO要件を策定する
- 開発会社がその要件を技術的にどう実装するかを翻訳・設計する
- 発注者が両者の橋渡しをし、要件定義書に正式に書き込む
問題が起きやすいのは、SEOコンサルがいない場合（発注者が自分でSEO要件を作る必要がある）と、SEOコンサルがいても開発会社との認識合わせができていない場合の二つです。本記事では前者を想定し、発注者が自力で要件を整理できるようサポートしていきます。
後からできないSEO対策の具体例｜契約前に必ず決めておくべきこと
ここからは、発注者が要件定義段階で意思決定すべき項目を、後変更コストの観点で整理します。「公開後でもよい項目」と「契約前に決めておかないと取り返しがつかない項目」を切り分けることが、SEO要件の優先順位付けの第一歩です。
後変更が困難なSEO要素一覧
次の項目は、公開後の変更が技術的に困難・もしくは大規模改修が必要になる代表例です。
要素 | 後変更が難しい理由 |
|---|---|
URL構造（パス階層・命名規則） | 既存URLからのリダイレクト設計・被リンクの引き継ぎ・サイトマップ再生成が必要。検索順位の一時低下リスクあり |
ドメイン構成（サブドメイン／サブディレクトリ） | DNS設定・SSL証明書・GA4/Search Console再登録など全面的な作業発生 |
CMS選定 | 移行コスト＝事実上の作り直し。記事資産の再投入が必要 |
レンダリング方式（SSR/SSG/CSR） | フレームワーク選定そのものを変える必要があり、フルリプレース相当 |
多言語対応の構造 | URL構造に組み込まれているため、後付けで |
これらは「あとで考えればいい」と先送りすると、後で大規模なリプレース費用を負担するか、SEO上の制約を抱えたまま運用し続けるかの二択になります。
後対応で"追加費用が発生しやすい"SEO項目
完全な作り直しまでは行かないものの、追加開発費用が発生しやすい項目もあります。
- meta情報の動的生成: 記事ごと・カテゴリごとにtitle/descriptionを個別最適化する機能がないと、テンプレート改修が必要
- 構造化データ（JSON-LD）の自動出力: Article・Breadcrumb・FAQなどスキーマごとにテンプレート改修が必要
- 多言語対応の
hreflangタグ: 言語切替UIだけ作ってhreflangを入れていないケースが頻発し、後対応で全テンプレート改修が発生 - 画像の最適化配信（WebP・遅延読み込み）: CDN・画像配信サーバーの選定からやり直しになることがある
- Core Web Vitals 改善: 初期実装で対応していないと、CSS/JSのリファクタ・サーバーレスポンス改善まで広範囲に及ぶ
契約書・見積書で必ず確認すべき条項
要件定義書だけでなく、契約書・見積書でも次の3点を確認しておくと、後のトラブルを大きく減らせます。
- SEO要件の責任範囲: 「SEO対策込み」とだけ書かれている場合、何が含まれて何が含まれないかを別紙で明示してもらう
- 検収条件: 「Core Web Vitals が PageSpeed Insights で◯◯以上」「sitemap.xml が自動生成される」など、客観的に確認可能な条件を明記する
- 保守時の修正範囲: 公開後にSEO観点の修正（meta変更・構造化データ追加など）を依頼した場合、保守契約の範囲内で対応されるか別途見積もりかを明示する
特に「SEO対策込みです」という一文だけでは、ベーシックなmetaタグ設定だけを指していることもあれば、構造化データやCore Web Vitalsまで含まれていることもあります。曖昧なまま契約しないことが何より重要です。
開発前に決めるべきSEO要件チェックリスト
ここからが本記事の中核です。要件定義書に書き込むべきSEO要件を、機能要件・非機能要件・運用要件の3つに分類し、各項目について「なぜ必要か／何を決めるか／開発会社にどう伝えるか」の3点セットで整理します。
URL設計要件
なぜ必要か: URL構造は検索エンジンがサイトの情報構造を理解する手がかりであり、一度公開すると変更コストが極めて高い領域です。命名規則・パラメータの扱い・末尾スラッシュなど、些細に見える要素が後々の運用と被リンク資産に影響します。
何を決めるか:
- パスの階層構造（例:
/category/sub-category/article-slug/） - スラッグの命名規則（英数字小文字・ハイフン区切りを推奨）
- パラメータの扱い（フィルタ・ソート用パラメータをURLに含めるか、
canonicalで本URLに集約するか） - 大文字小文字の正規化（
/Articleと/articleを別ページとして扱わない） - 末尾スラッシュの統一（あり／なしを統一しリダイレクト処理）
どう伝えるか: 「URL命名規則を別紙にまとめます。すべての公開URLはこの規則に従い、リダイレクト規則も合わせて整備してください」と要件定義書に明記し、サンプルURLを20件程度添付すると認識齟齬を防げます。
meta／HTML要件
なぜ必要か: title・descriptionは検索結果でユーザーがクリックするか判断する最初の接点であり、canonical・OGPなどはコンテンツの正規化や外部共有時の表示品質に直結します。CMS側でページ単位に編集できるかが、運用品質を大きく左右します。
何を決めるか:
- 全ページでtitle・descriptionを個別編集できるCMS機能の有無
- ページ種別ごとのテンプレート（記事・カテゴリ・タグ・固定ページ等）
- 見出し階層の自動生成ルール（h1は1ページ1つ・本文はh2から）
canonicalの自動付与ルール（重複コンテンツの正規化）- 多言語サイトの場合は
hreflangの出力仕様 - OGP（og:title・og:description・og:image）の自動／手動切替
どう伝えるか: 「すべてのページでtitle・descriptionを個別に編集できること。記事ページではOGP画像をアップロードできること。canonical は同一コンテンツに対し1つだけ出力されること」を機能要件に列挙します。
パフォーマンス要件（Core Web Vitals）
なぜ必要か: Core Web Vitals は Google のページエクスペリエンスシグナルとしてランキング要因に組み込まれており、ユーザー体験の客観指標でもあります。要件定義段階で目標値を非機能要件に書き込んでおかないと、後から「現在のアーキテクチャでは達成困難」と言われた際に交渉余地がなくなります。
何を決めるか: Google の公式基準（web.dev: Core Web Vitals）に基づき、以下の目標値を非機能要件に記載します。
- LCP（Largest Contentful Paint）: 2.5秒以下
- INP（Interaction to Next Paint）: 200ミリ秒以下（旧 FID から置き換え）
- CLS（Cumulative Layout Shift）: 0.1以下
加えて、画像最適化（WebP/AVIF 対応・遅延読み込み）、キャッシュ戦略（CDN 利用・ブラウザキャッシュのヘッダー設定）、JS/CSS の最適化（コード分割・不要なライブラリの除外）を要件として明示します。
どう伝えるか: 「主要ページ（トップ・記事・カテゴリ）の Core Web Vitals は、PageSpeed Insights のモバイルスコアで Good 判定（LCP 2.5秒以下／INP 200ms以下／CLS 0.1以下）を満たすこと。これを検収条件とする」と非機能要件に明記します。客観的な計測ツールでの数値を条件にすることで、検収時の認識齟齬を避けられます。
構造化データ要件
なぜ必要か: 構造化データ（JSON-LD）は検索結果のリッチリザルト表示や Knowledge Graph への登録に影響し、CTRを押し上げる効果があります。HTML テンプレートに静的に埋め込むのではなく、ページ種別ごとに動的生成できる設計が望ましいです。
何を決めるか:
- 採用するスキーマの種類（Article・BreadcrumbList・FAQPage・Organization・WebSite など）
- ページ種別ごとのJSON-LD自動出力（記事ページには Article、リスト系には BreadcrumbList など）
- 構造化データテストツール（Schema Markup Validator）でのエラーゼロを検収条件にするか
どう伝えるか: 「記事ページには Article スキーマ、全ページに BreadcrumbList スキーマ、コーポレートサイトトップに Organization スキーマを自動出力すること。Schema Markup Validator でエラー・警告ゼロを検収条件とする」と機能要件に明記します。
クロール／インデックス要件
なぜ必要か: 検索エンジンにサイト全体を正しく認識させるための基盤要件です。サイトマップやrobots.txtは些細に見えますが、不適切な設定は「重要なページがインデックスされない」「公開すべきでないページが検索結果に出てしまう」という致命的なトラブルを招きます。
何を決めるか:
sitemap.xmlの自動生成（新規ページ追加時に自動反映）robots.txtの制御方針（クロール除外ディレクトリ・許可するクローラー）noindex運用ルール（テスト環境・タグページ・検索結果ページ等の noindex 化）- ページネーション（カテゴリ一覧の2ページ目以降の
canonicalまたはnoindex方針） - 404ページ／410ページの設計
どう伝えるか: 「sitemap.xml は記事追加時に自動更新されること。テスト環境（ステージング）には Basic 認証または noindex を設定し、検索結果に出ないこと」を機能要件に明記します。ステージング環境のインデックス事故は実案件で頻発するため、要件定義段階で必ず釘を刺しておきます。
モバイル・アクセシビリティ・計測要件
なぜ必要か: モバイル対応は Google のモバイルファーストインデックスにおいて評価対象そのものであり、アクセシビリティは検索品質と並んで重視される領域です。さらに、効果測定の基盤（GA4・Search Console・タグマネージャー）が初期実装に組み込まれていないと、公開後にSEO効果を判断するデータが取れません。
何を決めるか:
- レスポンシブ仕様（主要ブレイクポイント・タップ領域のサイズ）
- 代替テキスト（alt属性）の入力必須化・チェック機能
- カラーコントラスト・キーボード操作（WCAG 2.1 AA レベル相当）
- GA4 タグの設置・主要イベント計測（資料DL・問い合わせなど）
- Search Console の所有権設定・XML サイトマップの送信
- Google Tag Manager（GTM）導入の有無と管理権限
どう伝えるか: 「画像のalt属性はCMS入力時に必須項目とすること。GA4・Search Console・GTM を導入し、公開時点で計測が開始できる状態にすること。主要CV（資料DL・問い合わせ）はイベント計測で追えるようにすること」と要件定義書に明記します。
なお、これらの要件を「機能要件」と「非機能要件」のどちらに書くべきか迷う場合は、機能要件と非機能要件の違いを参考にすると整理しやすくなります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
開発会社へのSEO要件の伝え方｜打ち合わせ・要件定義での具体テンプレート
要件項目を整理できても、それを開発会社に伝える「伝え方」が曖昧だと、結局「SEO対策込みです」という回答に戻ってしまいます。ここでは、打ち合わせアジェンダ・質問テンプレート・回答の深掘り方を提示します。
初回打ち合わせでぶつけるべき10の質問
要件定義の初回打ち合わせで、次の10問を聞いておくと、開発会社のSEO対応力と、現時点の見積もりに何が含まれているかが明確になります。
- URL構造は誰がどう決めますか？私たちで命名規則を作成してもよいですか？
- CMSは何を採用しますか？meta情報は全ページで個別編集できますか？
- レンダリング方式（SSR/SSG/CSR）はどれを採用予定ですか？SEO観点での選定理由を教えてください
- Core Web Vitals の目標値を非機能要件に入れたいのですが、どのレベルなら検収条件にできますか？
- 構造化データ（JSON-LD）は標準で出力されますか？対応スキーマを教えてください
sitemap.xmlは自動生成ですか？ステージング環境は noindex 化されますか？- 画像の最適化配信（WebP/AVIF・遅延読み込み）は対応しますか？
- GA4・Search Console・GTM の導入は見積もりに含まれていますか？
- 公開後にSEO観点の修正（meta変更・構造化データ追加など）を依頼した場合、保守の範囲内ですか？
- 過去にテクニカルSEOを意識した案件の実績はありますか？簡単に教えてください
SEO要件を要件定義書に記載してもらうための依頼文テンプレート
口頭の合意だけでは後から「言った言わない」になりやすいため、要件定義書への記載を依頼する文面をテンプレート化しておくと便利です。
要件定義書に「SEO要件」の章を新設してください。最低限、次の5項目を含めてください。
- URL設計の方針（命名規則・パラメータ運用）
- CMSのmeta／構造化データ機能仕様
- Core Web Vitals の目標値（LCP/INP/CLS の数値）
- sitemap.xml／robots.txt の設計
- GA4・Search Console・GTM の導入範囲
各項目について「対応する／対応しない／別途見積もり」の区分を明示し、対応する項目には実装内容を記載してください。
開発会社からの「SEO対策込みです」回答を深掘りする質問例
最も注意したいのが、「SEO対策込みです」という一文だけで合意してしまうケースです。次のような深掘り質問で具体化していきます。
- 「SEO対策込み」とは具体的にどの項目が含まれますか？一覧で教えてください
- meta情報の動的生成は含まれますか？画像の最適化配信は含まれますか？
- 構造化データの出力は含まれますか？対応スキーマは何ですか？
- Core Web Vitals 改善は含まれますか？目標値はありますか？
- 含まれない項目は何ですか？追加する場合の費用感を教えてください
「SEO対策込み」を契約書に書く前に、これらを別紙で文書化してもらうことを必ず依頼します。
SEOコンサル会社が併走する場合の三者連携の進め方
SEOコンサル会社が既に参画している場合は、コンサル・開発・発注者の三者でSEO要件のキックオフを設けます。コンサルが「やりたいこと」、開発が「実現できる方法」、発注者が「どちらの提案を採用するか」を決める三者連携です。要件定義書のSEO章は、この三者の合意内容を文書化するアウトプットとして位置づけます。
フレームワーク・CMSによるSEO特性の違い
技術選定はSEOに直接影響します。要件定義の段階で「どのフレームワーク／CMSを選ぶか」を開発会社任せにせず、SEO観点から確認すべきポイントを押さえておきます。
レンダリング方式とSEOへの影響
レンダリング方式は、検索エンジンがコンテンツを認識するスピード・正確性に大きく影響します。
方式 | 概要 | SEO適性 | 代表的な選択肢 |
|---|---|---|---|
SSG（静的サイト生成） | ビルド時にHTMLを生成 | 高（読み込み速い・確実にクロール可） | Next.js (SSG)・Astro・Nuxt (SSG)・Hugo |
SSR（サーバーサイドレンダリング） | リクエスト時にサーバーでHTML生成 | 高（動的でも検索エンジンが認識可） | Next.js (SSR)・Nuxt・Rails＋Turbo |
ISR（増分静的再生成） | SSGを部分的に再生成 | 高（更新頻度の高いサイト向け） | Next.js (ISR) |
CSR（クライアントサイドレンダリング） | ブラウザでJSがHTMLを生成 | 低〜中（クロールが遅延する場合あり） | React SPA・Vue SPA |
更新頻度の低いコーポレートサイト・記事サイトは SSG/ISR が推奨されます。CSR は管理画面や認証後コンテンツに留めるのが無難です。
主要フロントエンドフレームワークのSEO適性
- Next.js / Nuxt: SSR・SSG・ISRを柔軟に選択でき、metaタグの動的生成も標準サポート。コーポレートサイト・メディアサイトに最適
- Astro: コンテンツ中心サイトに特化したSSG。JSを最小限に抑え、Core Web Vitals 改善に強い
- Gatsby: SSGの老舗。エコシステムが豊富だが、近年は Next.js / Astro に押されている
- SPA（React／Vue 単体）: CSRが基本になり、SEO観点では追加対応が必要。コンテンツ中心サイトには非推奨
主要CMSのSEO設定の自由度
CMS | meta編集 | URL構造変更 | 構造化データ | 備考 |
|---|---|---|---|---|
WordPress | ◎（プラグインで柔軟） | ◎ | ◎（プラグイン） | 自由度高いが運用負荷あり |
Strapi（ヘッドレス） | ◎（フロント実装次第） | ◎ | ◎（実装次第） | フロントと組み合わせて柔軟 |
MovableType | ○ | ○ | △（テンプレ実装） | 国産・静的書き出し中心 |
Shopify | △ | △（制約あり） | △（テーマ依存） | ECに特化、URL構造に制約 |
ヘッドレスCMS（Strapi など）はフロント実装の自由度が高い反面、SEO要件をフロント側で実装する責任が開発会社に集中します。要件定義段階で「フロントエンド側で何を実装するか」を具体化しておくことが重要です。
SaaS型ECプラットフォームのSEO制約と回避策
Shopify などSaaS型ECプラットフォームは、URL構造（/products/ /collections/ などが固定）・テンプレート機能（テーマ依存）・サーバー側のカスタマイズ性に制約があります。
回避策としては、SEOで競争したい記事コンテンツを別ドメインまたはサブディレクトリで別CMSで運用し、商品ページのみ Shopify を使う「ハイブリッド構成」もあります。詳細はECサイト構築の3方式比較もあわせて参照してください。
要件定義書に書くべきSEO項目テンプレート（実記載例）
ここまで整理してきた要件を、実際の要件定義書フォーマットに落とし込みます。コピーして自社の要件定義書に転用しやすい粒度で記載します。
要件定義書のどのセクションにSEO要件を書き込むか
要件定義書には標準的に「機能要件」「非機能要件」「制約条件」「運用要件」などの章があります。SEO要件は次のように分散して書き込むのが実務的です。
- 機能要件: meta機能・構造化データ・sitemap・GA4／GTM など機能として実装する項目
- 非機能要件: Core Web Vitals の目標値・表示速度・モバイル対応
- 制約条件: URL構造・CMS選定理由・レンダリング方式
- 運用要件: 公開後の保守でカバーする範囲・SEO修正依頼の扱い
「SEO要件」という独立章を立てるのも一つの選択肢ですが、各章に散らして書く方が開発会社の各担当者（フロントエンド・バックエンド・インフラ）にとって参照しやすいことが多いです。
機能要件テンプレート（記入例つき）
[SEO関連機能要件]
F-SEO-01: 全ページのtitle・descriptionを管理画面から個別に編集できること
F-SEO-02: 記事ページにはJSON-LD形式でArticleスキーマを自動出力すること
F-SEO-03: 全ページにBreadcrumbListスキーマを自動出力すること
F-SEO-04: sitemap.xmlを自動生成し、記事追加・更新時に自動反映されること
F-SEO-05: ステージング環境はBasic認証またはnoindexで検索結果に表示されないこと
F-SEO-06: 画像はWebP形式で配信し、遅延読み込み（loading="lazy"）を実装すること
F-SEO-07: GA4・Search Console・Google Tag Managerを導入し、公開時点で計測開始できること
非機能要件テンプレート（Core Web Vitals目標値・SLAの書き方）
[SEO関連非機能要件]
NF-SEO-01: 主要ページ（トップ・記事・カテゴリ）のCore Web Vitalsは以下の基準を満たすこと
- LCP: 2.5秒以下
- INP: 200ミリ秒以下
- CLS: 0.1以下
測定ツール: PageSpeed Insights（モバイル）
NF-SEO-02: モバイル対応はレスポンシブで実装し、主要ブレイクポイント（375px / 768px / 1024px）で崩れないこと
NF-SEO-03: 画像のalt属性はCMS入力時に必須項目とすること
NF-SEO-04: WCAG 2.1 AAレベル相当のアクセシビリティを満たすこと
検収条件テンプレート（公開前のSEOチェックリスト）
[公開前SEO検収条件]
C-SEO-01: PageSpeed Insightsで主要ページのCore Web Vitalsが「Good」判定であること
C-SEO-02: Schema Markup Validatorで全構造化データがエラー・警告ゼロであること
C-SEO-03: sitemap.xmlがSearch Consoleで送信・読み込み成功すること
C-SEO-04: ステージング環境が検索結果に出現していないこと（site:検索で確認）
C-SEO-05: GA4でリアルタイムの計測データが取得できること
C-SEO-06: 全ページでcanonicalタグが1つだけ出力されていること
これらを要件定義書に書き込んでおけば、検収段階で「どこまでが契約範囲か」が明確になり、後の追加費用交渉でも根拠を持って話せます。
まとめ｜要件定義段階でSEOを織り込めば手戻りは防げる
システム開発の要件定義にSEOを織り込むかどうかは、公開後の検索流入・運用コスト・改修費用に長期的な影響を与える分岐点です。
本記事で押さえた要点は次の3つです。
- 後から変更が困難な要素は要件定義で必ず決め切る: URL構造・CMS選定・レンダリング方式は公開後の変更コストが極めて高い
- 要件定義書にSEO関連項目を分散して書き込む: 機能要件・非機能要件・制約条件・運用要件に散らし、Core Web Vitals は数値で検収条件化する
- 開発会社へは「SEO対策込み」では済ませず、具体テンプレートで質問する: 10の質問・依頼文テンプレート・深掘り質問を使って契約前に範囲を明確化する
次の打ち合わせでは、本記事のチェックリストと質問テンプレートを持参して、開発会社の回答を一つずつ文書化していきましょう。それだけで、半年後・1年後にSEO投資を始めた際の「これは対応できません」を大幅に減らせるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
