SEO施策の変更履歴を管理する方法｜検証できる記録の残し方
目次
SEO施策は、変更した内容を記録しなければ検証できません。クリックや順位が変化しても、いつ、どのページを、何の目的で直したか分からなければ、施策との関係を判断できないからです。ECサイトでは商品更新、セール、在庫変動、システム改修が同時に起こるため、検索データだけを見ても原因を切り分けられません。
変更履歴は、作業報告のためではなく、次の判断を再現するために残します。この記事では、記録する項目、管理方法、効果測定やロールバックへの使い方を説明します。
SEOで変更履歴が必要な理由
検索パフォーマンスは、施策を実施した直後に安定して変化するとは限りません。Googleの再クロールと処理、検索需要、競合、アルゴリズムの変化などが影響します。数週間後に変化が見えても、記憶だけでは施策内容を正確に戻せません。
履歴があれば、変更前後の設定、対象クエリ、評価期間を確認できます。担当者が変わったときも、同じページを同じ理由で繰り返し直すことを防げます。
記録する施策の範囲
titleとmeta descriptionだけでなく、本文、見出し、内部リンク、canonical、noindex、リダイレクト、構造化データ、URL、テンプレートなど、検索表示やページ内容に影響する変更を記録します。
すべての誤字修正を同じ重さで残す必要はありません。検索意図、商品判断、技術状態、計測に影響する変更を対象にします。何を履歴対象とするかをチームで決めます。
変更前と変更後を保存する
titleやmeta descriptionは、変更後の文だけでなく変更前の文も保存します。本文は全文を表計算へ貼るより、CMSの版管理、リポジトリ、文書の改訂履歴を使い、変更箇所への参照を残します。
テンプレート変更では、影響したページ群と対象外条件を記録します。一つの修正が数千ページへ反映される場合、代表URLだけを残すと影響範囲を追えません。
変更理由を具体的に書く
「SEO対策のため」「CTR改善」とだけ書いても、次の担当者は判断を再現できません。「非ブランドの主要クエリで表示回数があるが、titleがカテゴリ名だけで商品条件を伝えていない」のように、データと問題を結び付けます。
仮説は事実と分けます。「CTRが低い」は観測事実、「検索結果で品ぞろえが伝わらないことが原因」は仮説です。施策後に仮説が妥当だったかを見直せます。
対象クエリとページを記録する
ページURLだけでなく、主に確認した検索クエリを残します。同じページでもクエリによって順位とCTRが違います。変更時に優先した意図を明確にします。
クエリを大量に列挙する必要はありません。主要クエリ、クエリ群の分類、ブランド・非ブランドなど、変更判断に使った範囲を記録します。
基準値と比較条件を残す
変更前の表示回数、クリック数、CTR、平均掲載順位を、期間、検索タイプ、デバイス、国などの条件とともに保存します。数字だけでは、後から同じ条件を再現できません。
平均掲載順位は地域や端末などを含む平均値であり、一つの固定順位ではありません。比較期間の季節性やセールもメモします。
公開日と確認日を分ける
原稿を承認した日、サイトへ反映した日、Googleが再クロールした日、効果を確認した日は別です。少なくとも反映日と次回確認日を分けて記録します。
システム上の公開が遅れた場合、承認日を起点に比較すると期間がずれます。実際にページへ出力されたことを確認し、反映日を確定します。
担当者と承認者を記録する
提案者、内容確認者、実装担当、最終承認者を必要に応じて残します。健康、安全、法務に関わる商品では、誰が表現を確認したかが重要です。
担当者名を責任追及のために使うのではなく、疑問が出たときに判断根拠へ戻るために使います。退職後も分かるよう、資料と承認コメントを共有場所へ保管します。
表計算で管理する項目
- 施策IDと対象URL
- ページ種別と関連カテゴリ
- 主要クエリまたはクエリ群
- 変更前と変更後の内容
- 問題、仮説、変更理由
- 提案者、確認者、実装担当
- 反映日と次回確認日
- 比較期間と変更前後の指標
- 維持、再調整、復元などの判断
URLだけを主キーにすると、同じページの複数施策を区別できません。施策IDを付け、一ページに複数の履歴を時系列で残します。
CMSと表計算の役割を分ける
CMSの版管理は変更内容の保存に向き、表計算やチケット管理は目的、担当、評価結果の整理に向きます。一つのツールですべてを管理しようとせず、相互に参照できるIDやURLを付けます。
開発を伴う施策は、チケット番号、リリース日、対象テンプレートを記録します。検索データのレポートから実装内容へ戻れるようにします。
ロールバックの条件を決める
変更履歴があれば、以前の設定へ戻す選択肢を持てます。ただし、順位が一時的に下がっただけで自動的に戻すのは避けます。需要、競合、Googleの更新、本文や在庫の変化を確認します。
明らかな誤表示、商品名の欠落、文字化け、全ページへの誤反映などは、検索データを待たずに修正します。効果判断と品質事故の復旧を分けます。
履歴から運用ルールを改善する
一定数の施策がたまったら、成功パターンを断定するのではなく、どの条件でどの変更が行われたかを振り返ります。同じテンプレートの誤りが繰り返されるなら、個別修正ではなく生成ルールを直します。
成果が弱かった施策も削除せず残します。対象選定、確認期間、実装、仮説のどこに問題があったかを見直します。
よくある間違い
変更後の文だけを保存し、変更前を上書きするケースがあります。以前の状態へ戻れず、どこが変わったか比較できません。公開前にスナップショットを保存します。
Search Consoleの数字を手作業で貼るだけで、条件を記録しないことにも注意します。日付、検索タイプ、ページ、クエリ、端末が違えば比較できません。
テンプレート変更は影響範囲も保存する
ECサイトでは、個別ページの編集よりもテンプレートや商品データ連携の変更が広い範囲へ影響します。「カテゴリのtitle形式を変更」とだけ残すのではなく、対象となったURL一覧、除外したカテゴリ、適用条件、公開した設定の版を保存します。後から新しいページが同じルールで生成された場合も追跡できます。
一括変更では、代表URLだけでなく、長い商品名、ブランド名がない商品、階層の深いカテゴリ、ページ送りなど例外になりやすいURLを試験対象に含めます。公開後の確認結果も施策IDへ追加します。
CMSやデータ連携の設定を元に戻せるかも公開前に確認します。ただし、元に戻す判断は検索指標だけでなく、誤表示や法務上の問題、顧客への影響を優先します。
一括反映を段階に分けた場合は、各回の対象範囲と時刻も記録します。同じ施策の中で公開条件が違っても、後から正しく比較できます。
まとめ
SEO施策の変更履歴では、対象URL、主要クエリ、変更前後、理由、担当、反映日、比較条件、評価結果を一つにつなげます。記録は報告のためではなく、次の担当者が判断を再現し、必要なら安全に戻すためのものです。小さな施策IDから始め、CMS、表計算、開発チケットを結び付けましょう。
