SEOで何を変更したか管理する方法｜設定変更・影響・復旧を記録

監修: 菊地 将（リブランディング株式会社）

検索順位や自然検索流入が急に下がったとき、「Googleのアップデートなのか」「昨日のサイト修正なのか」「計測設定が変わっただけなのか」をすぐに説明できるでしょうか。

説明に手間取るのは、いつ・どこを・何の目的で変更したかを後から追えない場合です。Googleも、検索トラフィックの減少には技術的な問題、アルゴリズム更新、検索需要の変化、サイト移転など複数の原因があると案内しています。変更の記録がないと、これらの候補から何を疑うべきかを絞りにくくなります。

そこで役立つのが「SEO変更履歴台帳」です。単なる作業日報ではなく、リリース日時、対象URL、変更前後、担当者、想定影響、確認結果、問題があったときに元へ戻す方法（ロールバック方法）までを1か所に残し、順位変動や障害が起きたときの原因の絞り込みに使う記録です。

この記事では、そのままスプレッドシートへ移せる項目設計から、変更のリスク分類、リリース後の確認、ロールバックの判断、台帳を続けるための運用ルールまでを説明します。

変更履歴を誰が残し、どう運用するかをSEO体制全体から確認したい場合は、SEO導入の体制構築とは？内製・外注・ハイブリッドの判断基準と進め方の全体地図を参照してください。

SEO変更履歴台帳とは？サイトの変更と検索への影響を時系列で結びつける記録

SEO変更履歴台帳とは、検索エンジンのクロール・インデックス・検索表示・流入に影響する可能性がある変更を、時系列で記録する管理表です。

クロールは検索エンジンがページを巡回して内容を取得すること、インデックスはそのページの情報が検索エンジンに登録されることを指します。この2つは別の段階なので、変更がどちらに影響しうるかは、台帳の「想定SEO影響」欄に書きます。

ここで押さえたいのは、SEO担当者が実施したSEO施策だけを記録の対象にしないことです。SEOを目的としていない開発やデザインの変更でも、検索へ影響する場合があるからです。記録の対象になる変更には、たとえば次のようなものがあります。

• CMSやテンプレートの変更
• URL変更
• リダイレクト変更
• canonicalの変更
• robots.txtの変更
• noindexの追加・削除
• XMLサイトマップの変更
• グローバルナビゲーション変更
• 内部リンク変更
• title・見出し・本文の変更
• 構造化データ変更
• JavaScriptの変更
• CDN・サーバー・DNSの変更
• Googleタグマネージャー（GTM）の公開
• アクセス解析設定の変更

GoogleはSearch Consoleについて、定期確認に加えて、サイトのコンテンツに変更を加えた場合にもデータを確認することを推奨しています。変更履歴と検索データを別々に管理せず、次の一連の運用にすると、後から原因を調べやすくなります。

変更する → 記録する → Search Consoleなどで確認する → 結果を追記する

なぜSEO変更履歴を残す必要があるのか

最大の理由は、順位や流入が変化したときに、原因の候補を絞り込めるようにするためです。

検索流入が下がったからといって、その直前に行った変更が原因とは限りません。Googleは検索トラフィック減少の主な原因として、アルゴリズム更新、技術的問題、セキュリティ問題、検索需要の変化、サイト移転など複数の可能性を示しています。

たとえば、次の2つの事実があるとします。

「8月20日に順位が落ちた」
「8月18日にテンプレートを変更した」

この2つだけでは、テンプレート変更が原因だとは判断できません。一方、変更履歴に次の情報まで残っていれば、原因の候補をかなり絞れます。

• 変更日時
• 影響したURL
• 変更内容
• 変更前後
• Search Consoleの変化
• インデックス状況
• Google公式アップデートの期間
• 他に同時実施した変更

台帳の役割は、因果関係を自動的に証明することではありません。調査を始めるときに「何を疑うべきか」をすぐ特定できる状態を作ることが目的です。

SEO変更履歴台帳に最低限入れる15項目

実務では、変更1件につき1行で記録すると管理しやすくなります。最低限、次の15項目を用意します。

項目	記録する内容
変更ID	SEO-20260829-001など一意の番号
リリース日時	本番環境へ反映した日時
対象範囲	全サイト・ディレクトリ・特定URLなど
対象URL	URLまたはURLパターン
変更カテゴリ	URL、コンテンツ、内部リンク、タグ、インフラなど
変更前	修正前の状態
変更後	修正後の状態
変更目的	なぜ変更するのか
想定SEO影響	クロール、インデックス、順位、CTRなど
担当者	実装担当者
関連資料	チケット、PR、コミット、仕様書など
SEOリスク	高・中・低
リリース後確認	Search Consoleやクロール結果
判定	正常・経過観察・要調査・修正・ロールバック
ロールバック方法	元に戻す方法・対象バージョン

15項目は、基本情報、変更内容、影響の仮説、検証、復旧の5つの領域に分けて考えると整理できます。変更内容だけでなく、「何を想定し、実際に何が起き、問題があればどう戻すか」まで一続きで管理するための構成です。

なかでも「変更前」と「変更後」を分けて残すことは欠かせません。「titleを修正した」と書くだけでは、数か月後に何をどう直したのか確認できないからです。可能な範囲で、次のように具体的な差分を残します。

変更前：「SEO対策について」
変更後：「SEO対策とは？企業が実施すべき7つの施策」

「想定影響」と「確認された影響」は分けて記録する

台帳で混同しやすいのが、変更時点の予測と、変更後に実際に確認された結果です。この2つは別の項目にして記録します。次の表は、重要ページへ内部リンクを追加した場合の記入例です。

項目	内容
変更内容	重要ページへの内部リンクを追加
想定影響	Googleが対象ページを発見しやすくなる可能性
確認された影響	対象ページのクロール頻度・表示回数を継続確認
判定	経過観察

この例では、変更時点で書いたのは「Googleが対象ページを発見しやすくなる可能性」という仮説だけです。実際にどうなったかは、クロール頻度や表示回数を継続して確認したうえで書くことになり、それまでの判定は「経過観察」にしています。

変更した直後に「順位改善」「流入増加」と書いてしまうと、後から事実と仮説が混ざります。そこで、変更時点では仮説を書く。結果欄はデータを確認してから更新する。というルールにすると、記録の信頼性が高まります。

SEO変更はリスク別に「高・中・低」の3段階に分ける

すべての変更を同じ重さで管理する必要はありません。SEOへの影響範囲を基準に、3段階程度へ分類すると運用しやすくなります。次の表は、リスクごとの主な変更例と、リリース前後の対応をまとめたものです。

リスク	主な変更例	リリース前後の対応
高	URL変更、noindex、robots.txt、canonical、大量リダイレクト、サイト移転	SEO担当者確認、バックアップ、即時確認、ロールバック準備
中	テンプレート、内部リンク、title一括変更、構造化データ	対象範囲確認、代表URLテスト、リリース後監視
低	誤字修正、画像差し替え、SEOに関係しにくい軽微なUI変更	台帳記録、通常確認

URLやindex制御など影響範囲の大きい変更ほど、公開前の確認とロールバックの準備を厚くします。高リスク変更は、履歴を残すだけでなく、本番公開前にnoindex・robots.txt・canonical・リダイレクトなどのクリティカル項目を確認し、公開してよいか止めるか（GO/HOLD）を判断します。具体的な承認ゲートはSEOリリース前チェックの作り方で解説しています。

とくにサイト移転やURL変更は、通常のテキスト修正とは分けて扱います。Googleはサイト移転について、大規模な変更後には再クロール・再インデックスの間にランキングが一時的に変動する場合があり、中小規模サイトでも反映に数週間かかることがあると説明しています。

そのため、URL移転直後の順位変動だけで「失敗」と判断してすぐ元に戻すのではなく、次の点を確認してから判断します。

• リダイレクトが正常か
• canonicalが正しいか
• sitemapが更新されているか
• クロールエラーが増えていないか
• 新URLが認識され始めているか

変更前にロールバック方法まで決めておく

障害が起きてから「どう戻すか」を考えるのではなく、重要なSEO変更では、戻し方をリリース前に決めておきます。変更の種類ごとの戻し方の例は、次の表のとおりです。

変更	ロールバック例
robots.txt	変更前ファイルを再配置
noindex	元のmeta robots設定へ戻す
canonical	変更前URLへ復元
リダイレクト	旧リダイレクト設定を再適用
GTM	直前の正常バージョンを再公開
テンプレート	直前のGitコミット・リリースへ戻す
コンテンツ	CMSのリビジョンから復元

Googleタグマネージャーには公開ごとのバージョン履歴が保存され、公開日時や公開者を確認できます。また、以前のバージョンへ戻して再公開する仕組みも用意されています。

この考え方をWebサイト全体へ広げると、変更履歴だけでなく「戻せる状態」までセットで管理することが重要だと分かります。

どんなときにロールバックするか？「順位が下がった」だけで決めない

ロールバックを判断するときは、技術障害と検索順位の変動を分けて考えます。

即時対応を検討しやすいケース

• 重要ページに意図しないnoindexが付いた
• robots.txtで重要ディレクトリをブロックした
• 大量のURLが404になった
• canonicalが別ページを向いている
• 本番環境で500エラーが発生している
• リダイレクト先が誤っている

これらは実装上の不具合として確認できれば、早い対応が必要です。

すぐ戻さない方がよいケース

• 順位が数日間下がった
• Search Consoleのクリック数が短期間減った
• コンテンツ改善後すぐ順位が動かなかった
• サイト移転直後に順位が揺れた

Googleは、小幅な順位変動について、ページがすでに良好な状態なら急激な変更を避けることを推奨しています。また、大きな変更の効果が確認できるまで数週間以上かかる場合があると説明しています。

したがって、判断の軸を次の2つに分けます。

技術的な異常は早く戻す。検索評価の変化は観測期間を設ける。

誤ったnoindexや500エラーなど明確な技術障害は早めに対応し、通常の順位変動はデータを確認してから判断します。

SEO変更履歴はどう運用するか？5ステップの実務フロー

台帳は作るだけでは機能しません。次の5ステップを標準の流れにします。

変更を記録した時点では、台帳はまだ完成ではありません。公開後の確認結果と最終判断まで追記して、はじめて運用が一巡します。

1. 変更前に台帳へ登録する

変更を実施する前に、最低でも次の項目を記録します。

• 対象
• 変更内容
• 目的
• 担当者
• SEOリスク
• ロールバック方法

高リスク変更は、SEO担当者またはWeb責任者による確認を入れます。

2. リリース日時を確定する

記録するのは予定日時ではなく、実際に本番へ反映した日時です。

複数の施策を同時に実施した場合は、できるだけ変更単位を分けて記録してください。一度に大量の変更を行うと、結果が変化したときにどの変更が関係したのか切り分けにくくなるためです。

3. リリース直後に技術確認する

代表URLを使って、次の点を確認します。

• HTTPステータス
• robots
• canonical
• noindex
• 内部リンク
• 構造化データ
• ページ表示
• 計測タグ

4. Search Consoleで変化を確認する

変更対象のURLやディレクトリ単位で、次の項目を確認します。

• クリック
• 表示回数
• クエリ
• URL
• インデックス状況

Googleはトラフィック減少を分析するとき、期間比較に加えて、影響がサイト全体なのか、一部ページなのかを切り分ける方法を案内しています。台帳の「対象URL」とSearch Consoleの「影響URL」を突き合わせると、調査しやすくなります。

5. 結果と判断を追記する

確認が終わったら、次のいずれかのステータスに更新します。

• 正常
• 経過観察
• 要調査
• 修正
• ロールバック

これで、変更履歴が「作業記録」から「判断記録」になります。

台帳にはどう書くか？具体的な記入例

実際の記入例を次の表に示します。1行が1件の変更で、確認結果に応じて判定を付けています。

変更ID	日時	対象	変更内容	リスク	確認結果	判定
SEO-001	8/20 10:00	/service/配下	titleテンプレート変更	中	インデックス正常、表示回数監視	経過観察
SEO-002	8/22 14:30	/column/旧URL	301リダイレクト設定	高	旧URL→新URL正常	正常
SEO-003	8/25 18:00	全ページ	GTM設定変更	中	GA4計測異常を確認	ロールバック
SEO-004	8/27 11:00	/product/a/	canonical変更	高	canonical先の誤りを確認	修正

たとえば、SEO-002の301リダイレクト設定は、旧URLから新URLへの転送を確認できたため「正常」です。SEO-003のGTM設定変更ではGA4の計測異常を確認したため「ロールバック」、SEO-004のcanonical変更ではcanonical先の誤りを確認したため「修正」としています。

大切なのは、成功した変更だけでなく、失敗した変更も残すことです。失敗の履歴は、次のような将来の判断材料になります。

「この設定は以前問題が起きた」
「このリリース方法では確認項目が不足した」

Git・GTM・GA4だけではSEO変更履歴台帳の代わりにならない

既存のツールにも変更履歴の機能があります。

GitHubでは、push・merge・branch変更などリポジトリ内の変更履歴を確認し、コミット単位で差分を追跡できます。Googleタグマネージャーにも、バージョン、公開日時、公開者、変更内容の履歴があります。Google Analytics 4（GA4）では、レポートの特定日にメモを付け、トラフィック増減、キャンペーン開始、商品リリースなどの出来事を記録できます。

ただし、それぞれ管理する対象が異なります。次の表で、得意なことと足りない情報を比べます。

管理方法	得意なこと	足りない情報
Git/GitHub	コード差分・実装者・コミット	SEO上の目的や結果
GTM	タグ変更・バージョン・復元	サイト全体の変更
GA4メモ	数値変化とイベントの時系列確認	技術的な差分・戻し方
SEO変更履歴台帳	SEOに関係する変更を横断管理	詳細差分は各ツールを参照

表のとおり、各ツールが持つのは自分の範囲の履歴で、足りない情報はツールごとに異なります。一方、台帳は詳細な差分を持たない代わりに、SEOに関係する変更を横断して管理できます。

したがって、すべてをスプレッドシートへ転記する必要はありません。台帳には「何が変わったか」と「どこを見れば詳細を確認できるか」を記録し、Git、GTM、チケット管理などの詳細履歴へリンクできるようにするのが現実的です。

順位変動が起きたときは「変更タイムライン」を作る

検索流入が大きく変化した場合は、台帳を使って対象期間のタイムラインを作ります。たとえば、次のような形です。

8月10日：重要記事20ページをリライト
8月12日：内部リンクテンプレート変更
8月18日：Googleのアップデート開始
8月20日：表示回数低下
8月22日：特定ディレクトリの順位低下を確認

そのうえで、次の6点を照合します。

1. 影響したURL
2. 変更対象URL
3. Google公式アップデート期間
4. クロール・インデックス異常
5. 検索需要の変化
6. 同時期の別変更

ここで注意したいのは、時期が一致しただけで原因と決めないことです。変更対象外のページも同じように下落しているなら、その変更だけでは説明できない可能性があります。反対に、特定テンプレートを変更したURL群だけに問題が集中しているなら、変更との関連を優先的に調べる価値があります。

台帳を続けるにはどうするか？4つの運用ルール

台帳が続かなくなる最大の理由は、項目数よりも「誰がいつ書くのか」が決まっていないことです。次の4つのルールで、記録する人、確認する範囲、記録のタイミング、見直しの頻度を決めます。

実装担当者が変更前に登録する

SEO担当者が後から聞き取って記録する方式では、漏れが出ます。変更を実施する担当者が自分で登録する仕組みにします。

高リスク変更だけSEO担当者が確認する

すべての軽微な更新に承認を求めると、運用が重くなります。URL、index制御、robots、canonical、テンプレートなど影響範囲が大きい変更を重点的に管理します。

「台帳登録済み」をリリース条件にする

リリースチェックリストに「SEO変更履歴への登録」を1項目追加すると、記録漏れを防ぎやすくなります。

月1回、未完了行を確認する

「経過観察」のまま結果が記録されていない変更が増えると、台帳の価値が下がります。月次で、次の点を確認します。

• 結果未入力
• ロールバック方法未入力
• 対象URL不明
• 関連資料リンク切れ

SEO変更履歴台帳で最も重要なのは「あとから判断できるか」

変更履歴を細かく書くこと自体が目的ではありません。必要なのは、数週間後や半年後に別の担当者が見ても、次の内容を理解できることです。

「いつ」
「何を」
「なぜ」
「誰が」
「どこへ」
「どのように変更し」
「何が起き」
「問題があればどう戻せるか」

そのため、台帳の項目を設計するときは、この行だけを見て、順位変動の調査を開始できるかを基準にしてください。

まとめ

SEO変更履歴台帳は、SEO施策の実績表ではなく、サイト変更と検索パフォーマンスを時系列で追跡するための運用基盤です。最低限、次の項目を記録します。

• リリース日時
• 対象URL
• 変更前後
• 変更目的
• 担当者
• SEOリスク
• 関連資料
• リリース後確認
• 判定
• ロールバック方法

運用で気をつけたいのは、「変更したから順位が動いた」とすぐ因果関係を決めないことです。変更履歴、Search Console、クロール・インデックス状況、Googleのアップデート、検索需要などを時系列で照合すると、原因の候補を切り分けやすくなります。

SEO担当者と開発担当者が同じ変更履歴を共有できるようにすると、問題発生時の調査が速くなるだけでなく、変更前のリスク管理やロールバックの判断も改善できます。

まずは、影響の大きいURL変更、index制御、リダイレクト、テンプレート変更から、1行1変更で記録を始めるとよいでしょう。

参考文献・データ元

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

関連記事

• › SEO内製化後の運用設計｜RACI・会議体・判断記録で属人化を防ぐ
• › 【2026年版】SEOツールおすすめ10選｜無料・有料の機能・料金・用途を比較
• › 【2026年版】SEO対策会社10選｜費用・対応範囲・実績を比較
• › SEO対策会社へ依頼する前に決めること｜範囲・KPI・権限・成果物
• › SEO対策会社の提案はどこを比較？範囲・工数・KPI・見積もり
• › SEO対策会社の契約更新判断｜成果・実装量・残る課題・次の施策
• › SEO対策会社を乗り換えるときにやること｜Search Console・GA4・CMS・これまでの対応内容・権限を引き継ぐ
• › 社内SEO担当者の引き継ぎ｜GA4・対応履歴・権限を整理
• › SEO対策会社の月次レポートの見方｜順位・流入・CV・実施内容・次月計画を評価する方法
• › SEO対策会社へ相談する前に準備する7項目｜目標・対象ページ・Search Console・実装体制を整理
• › SEO改善が止まる原因は？課題特定・実装・検証・優先順位・専門性の5工程で診断
• › SEO対策会社と契約する前に確認すること｜実装範囲・権限・成果定義・引き継ぎ
• › SEO施策の実装が開発待ちで止まるときの進め方｜仕様・チケット・担当・検証を整える
• › SEO修正が本番に反映されたか確認する方法｜HTML・レンダリング・canonical・計測タグを検証
• › SEO実装はどこまで外注する？仕様・開発・QA・公開後検証
• › SEO対策の費用相場｜施策別料金・契約形態・費用対効果を整理

関連テーマ

AIO MEO 口コミ・風評対策 採用改善 オウンドメディア集客