SEO施策の実装が開発待ちで止まるときの進め方｜仕様・チケット・担当・検証を整える

SEO改善案を開発チームが実装できる仕様とチケットへ整理しているオフィスのデスク

SEOの改善案は決まっているのに、開発チームへ依頼した後から進まない。バックログに入ったまま数か月動かない。そうした状態に心当たりはないでしょうか。

この状態は、SEOの重要性を繰り返し説明するだけでは解消しにくいものです。必要なのは、SEO側の改善案を、開発側が工数を見積もり、実装し、完了を判定できる単位まで具体化することです。

具体化の軸は、チケットに入れる次の9項目です。背景、対象、現状、変更内容、対象外、優先度、依存関係、受け入れ条件（何を満たせば完了とするかの条件）、公開後の確認です。この記事では、改善案が決まってから実装・検証まで進める方法を、この9項目の書き方から順に説明します。後半には記載例とチェックリストも載せています。

開発待ちを解消するには、SEOの提案をどこまで「開発できる仕様」にするか

SEO施策が開発待ちで止まっているとき、最初に確認したいのは「依頼済みか」ではありません。開発チームがその情報だけで工数を見積もり、実装方法を判断できる状態かです。

「canonicalを直す」「内部リンクを増やす」「構造化データを実装する」といったSEO側の指示だけでは、開発担当者にとって情報が足りないことがあります。たとえば「canonicalを修正する」という施策でも、開発側では次の点を確認する必要があります。

どのURL・テンプレートが対象か
現在はどのような出力になっているか
変更後に何を出力するか
パラメータURLやページネーションはどう扱うか
対象外にするURLはあるか
他機能への影響はないか
何を確認できれば実装完了とするか

Googleも、検索向けの技術実装では、リンク、サイトマップ、JavaScript、canonical、robots設定など、検索エンジンがページを発見・理解できる状態を技術面から確認するよう案内しています。

そのため、SEO担当者から開発担当者へ渡す段階では、「何を改善したいか」で止めずに、「何をどの条件で変更すれば完了なのか」まで整理します。

図のとおり、改善案はそのまま渡さず、開発側が判断できる仕様とチケットに変換してから実装へ進めます。次の節では、そのチケットに入れる項目を見ていきます。

SEO実装チケットには何を書くか｜入れる9項目

開発チームに渡すチケットには、少なくとも次の9項目を入れると、SEO側と開発側の認識のずれを減らしやすくなります。表の番号は、後の記載例でも同じ順で使います。

項目	記載する内容
1. 背景	なぜ変更が必要なのか
2. 対象	URL、テンプレート、機能など
3. 現状	現在どのような挙動になっているか
4. 変更内容	何をどう変更したいか
5. 対象外	今回変更しない範囲
6. 優先度	なぜ今対応するのか
7. 依存関係	他チケット・機能・部署との関係
8. 受け入れ条件	何を満たせば完了か
9. 公開後の確認	何を、いつ、誰が確認するか

SEO実装チケットに必要な背景、対象、変更内容、優先度、受け入れ条件など9項目の構造

9項目がそろっていれば、開発担当者は見積もりから実装、完了判定まで進められます。

9項目のうち、とくに「対象外」と「受け入れ条件」は、チケットが止まるかどうかを左右します。

対象だけを書くと、開発の途中で「このケースも対象なのか」「別のテンプレートにも適用するのか」という確認が増え、見積もりや実装が止まりやすくなります。一方、受け入れ条件がなければ、コード上は変更されていても、SEO側が期待していた状態になっているかを判断できません。

ソフトウェア開発における受け入れ条件は、成果物を受け入れるために満たすべき条件を事前に定義するものです。NASAのSoftware Engineering Handbookでも、利用者・開発側が事前に受け入れ条件を定義し、テスト方法や担当を計画することが重要とされています。

SEOの要望ではなく「変更前・変更後」で仕様を書く

開発側へ伝えるときは、「SEO上よくないので改善してください」とは書かず、変更前と変更後を明確にします。次の表は、曖昧な依頼を開発仕様として書き直した例です。

曖昧な依頼	開発仕様として整理した例
内部リンクを増やす	商品詳細ページ下部に同カテゴリの商品へのリンクを最大5件表示する
canonicalを正しくする	指定テンプレートではパラメータを除いた正規URLをcanonicalとして出力する
noindexを直す	指定テンプレートのindex対象ページからnoindexを削除する
構造化データを入れる	対象ページへ指定プロパティを持つ構造化データを出力する
ページ速度を改善する	対象テンプレートの画像読み込み方法を変更し、変更前後を計測する

どの行も、右側では「どのページで、何を、どう変えるか」が分かります。「何を良くしたいか」は背景として必要ですが、実装の段階では、システムをどう変更するかまで具体化しなければなりません。

ただし、SEO担当者がコードの実装方法まで決める必要はありません。SEO上守るべき条件と、技術的な実装方法を分けて書きます。SEO側が条件を示し、実装方法は開発側が判断できる形にしておくのが分担の考え方です。

対象範囲と対象外をセットで決める

SEO施策の実装では、「どこまで直すか」が曖昧なままだと、開発側は工数を出しにくくなります。たとえば「一覧ページの内部リンクを修正する」という施策でも、サイト内には次のようなページがあるかもしれません。

カテゴリ一覧
地域一覧
検索結果一覧
絞り込み一覧
特集一覧
会員向け一覧
管理画面

この場合、「一覧ページ」とだけ書かずに、次のように対象と対象外を分けて示します。

対象

カテゴリ一覧
地域一覧

対象外

サイト内検索結果
会員ページ
管理画面
絞り込み条件付きURL

対象外を決める目的は、作業を減らすことではありません。今回の変更範囲を開発側が正確に見積もれる状態にすることです。

SEO施策の優先順位は「効果」だけでなく「工数・依存関係」も並べて決める

SEO側だけで優先順位を決めると、重要でも実装負荷の大きい施策ばかりが上位に並び、結果として何も実装されないことがあります。開発へ渡す段階では、少なくとも次の4点を並べて判断します。

判断軸	確認内容
SEO上の影響	クロール・インデックス・流入などへの影響
開発工数	小・中・大、または見積工数
依存関係	他機能や別チケットの完了が必要か
実装時期	次回リリースで対応可能か

SEOへの影響だけでなく、開発工数・依存関係・実装時期もあわせて見て、着手順を決めます。影響が大きくても工数の大きい施策は、この4点を並べることで、小さく分ける、次回リリースに合わせるといった現実的な進め方を検討しやすくなります。

誰が何を担当し、次に誰が判断するかを決める

実装を進めるには、役割ごとの担当者を決めておく必要があります。少なくとも次の役割を割り当てます。

役割	主な担当
SEO要件の責任者	SEO担当・Web担当
技術確認	開発担当
工数・スケジュール判断	開発責任者・PM
事業優先度の判断	Web責任者・事業責任者
実装	開発担当
SEO受け入れ確認	SEO担当
公開後検証	SEO担当＋必要に応じて開発担当

この表のうち、「技術確認」「工数・スケジュール判断」「事業優先度の判断」は、いずれも誰かの判断を待つ役割です。チケットには、いま誰の判断を待っているのか、次に判断するのは誰なのかが分かるようにしておきます。

受け入れ条件は「目視確認」だけにしない

受け入れ条件には、画面を見て確かめるだけでなく、施策に応じた確認方法を入れます。次のような方法から選びます。

ブラウザでの表示確認
HTMLソースの確認
HTTPステータスの確認
canonicalの確認
robots metaの確認
robots.txtの確認
内部リンクの確認
構造化データの確認
URL検査
Rich Results Test
クロールツールによる確認

施策ごとに、どの方法で何を確かめれば完了とするかを、受け入れ条件に書いておきます。

実装完了とSEO施策完了を分ける

開発チケットが完了しても、SEO施策が完了したとは限りません。チケットを閉じた後に、検索エンジン側の認識と、施策の目的に対応する指標まで確認します。確認は次の3段階で進めます。

1｜実装確認：仕様どおりに変更されたか

受け入れ条件に照らして、仕様どおりに変更されているかを確認します。

2｜検索エンジン側の確認：Googleがどう認識しているか

Googleが変更後のページをどのように認識しているかを確認します。

3｜成果確認：目的の指標が変わったか

変更の目的に対応した指標を、一定期間にわたって確認します。

開発待ちのSEO施策を動かす5ステップ

ここまでの内容を、実際に進める順に並べ直すと次の5ステップになります。

ステップ1｜改善案を1チケット1目的に分ける

改善案をひとまとめにせず、実装単位に分けます。1枚のチケットでは、目的を1つに絞ります。

ステップ2｜仕様と対象外を明確にする

曖昧な依頼ではなく変更前後で仕様を書き、対象とあわせて対象外も明記します。

ステップ3｜SEO影響・工数・依存関係で優先順位を決める

SEO上の影響だけでなく、開発工数や依存関係も並べて着手順を決めます。

ステップ4｜受け入れ条件を決めてから実装する

何を満たせば完了なのかを、実装を始める前に決めます。確認方法は目視だけにしません。

ステップ5｜公開後の確認日を最初から決める

公開後に何を、いつ、誰が確認するのかを、チケットを作る時点で決めておきます。

SEO実装チケットの記載例（カテゴリ一覧ページの内部リンク修正）

9項目を使った記載例です。カテゴリ一覧ページの内部リンクを修正する施策を想定した、仮想の例として読んでください。

施策：カテゴリ一覧ページの内部リンク修正

背景
カテゴリ一覧から商品詳細ページへのリンクがJavaScriptのクリック処理のみになっているため、検索エンジンが通常のリンクとして辿れる形へ変更する。

対象
カテゴリ一覧テンプレート

現状
商品カード全体がJavaScriptのクリック処理で遷移している。

変更内容
商品詳細ページへ遷移する商品名部分を、href属性を持つリンクとして出力する。

対象外

モーダル表示ボタン
絞り込みUI
ページ遷移を伴わない操作

優先度
高

依存関係
商品カードコンポーネントの変更が必要。

受け入れ条件

対象の商品詳細URLがHTML上のリンクとして存在する
PC・スマートフォンとも現在の画面操作を維持する
対象外UIの挙動に変更がない

公開後確認

本番HTMLを確認
主要URLをURL検査
クロール状況を継続確認

この例では、「対象外」に挙げたUIが、受け入れ条件の「対象外UIの挙動に変更がない」と対応しています。対象外を決めておくと、完了の判定もしやすくなります。

開発工数そのものが足りないときはどうするか

ここまで整理しても、開発リソースが純粋に不足していれば、SEO施策は進みません。その場合は、次の選択肢を検討します。

小さな施策へ分割する
次回リリースへ組み込む
大規模改修とは別枠でSEO改善枠を設ける
制作会社や外部開発会社へ実装を依頼する
SEO担当と開発担当が直接相談できる時間を設ける
大規模改修は別プロジェクトとして計画する

実装を担う人員の不足を含め、SEOを内製・外注・ハイブリッドのどの体制で進めるかを判断したい場合は、SEO導入の体制構築の全体地図を確認してください。

自社のSEO開発フローを確認するチェックリスト

自社の進め方を点検するためのチェックリストです。当てはまらない項目が、次に整える箇所になります。

改善案を実装単位に分けている
対象URL・テンプレートが明確
変更前と変更後が分かる
対象外・例外条件が明記されている
SEO上守る条件と技術的な実装方法を分けている
SEO影響だけでなく開発工数を確認している
他機能・他チケットとの依存関係を確認している
誰が次に判断するか分かる
受け入れ条件が決まっている
公開後の確認方法が決まっている
公開後の確認担当が決まっている
SEOチケットを定期的に見直す場がある

まとめ

SEO施策が開発待ちで止まっているときは、改善案を何度も説明するより、開発チームが判断・見積もり・実装・検証できる形へ変換することが解決の中心になります。

まず、SEO改善案を実装単位に分け、「背景・対象・現状・変更内容・対象外・優先度・依存関係・受け入れ条件・公開後確認」を整理します。そのうえで、SEO効果だけでなく開発工数や依存関係も含めて着手順を決め、担当者と次の判断者を明確にします。さらに、実装完了とSEO施策完了を分け、公開後はSearch Consoleなどを使って検索エンジン側の認識まで確認します。

この流れを標準化できれば、「改善案はあるのに開発バックログから動かない」という状態を減らし、SEO施策を実装・検証まで進めやすくなります。最初の一歩として、いま止まっているSEO施策を1つ選び、9項目を書き出してみてください。

SEO施策を開発チームへ渡す際の整理項目を実務で使いたい場合は、無料ダウンロード資料もあわせて活用できます。

参考文献・データ元

この記事で参照した情報を確認できます。

Google Search Central「Get started with Search: a developer’s guide」
https://developers.google.com/search/docs/fundamentals/get-started-developers
Google Search Central「Get started with Search Console」
https://developers.google.com/search/docs/monitor-debug/search-console-start
Google Search Central「Using Search Console and Google Analytics Data for SEO」
https://developers.google.com/search/docs/monitor-debug/google-analytics-search-console
NASA Software Engineering Handbook「Acceptance Criteria」
https://swehb.nasa.gov/spaces/7150/pages/16450634/SWE-034%2B-%2BAcceptance%2BCriteria
Souza, J. & Zaina, L.「How can UX requirements be part of the acceptance criteria specification?」
https://www.clei.org/cleiej/index.php/cleiej/article/view/742
Oran, A.「Why use case specifications are hard to use in generating prototypes?」
https://ietresearch.onlinelibrary.wiley.com/doi/full/10.1049/iet-sen.2018.5239
katakuriko inc.「テクニカルSEOとは？実装が止まりやすい理由と改善の進め方」
https://katakuriko.jp/topics/technical-seo
株式会社ハウクレイジー「JavaScript SEOとレンダリング方式の選び方」
https://howcrazy.co.jp/blogs/javascript-seo

‹ 親記事: SEO導入の体制構築とは？内製・外注・ハイブリッドの判断基準と進め方の全体地図