サイトマイグレーションSEOチェックリスト

サイトマイグレーションとは、サイトのプラットフォーム、ドメイン、プロトコル、情報設計、URL構造、またはレンダリングシステムに対する管理された変更です。ユーザー、クローラー、分析ツールが安定したルートを通じて目的のコンテンツに到達でき、価値ある可視性が維持されたことをチームが証明できた時点で完了となります。

チェックリスト： サイトマイグレーションSEO。タイムボックス： 中規模サイトの場合、ローンチの6〜12週間前に開始。変更フリーズのために最終営業日5日間、ローンチ日にスタッフによる検証、少なくとも4週間のアクティブモニタリングを確保。責任者： リリース全体に対して責任を持つ1名の移行リーダーと、指定されたエンジニアリング、SEO、分析、コンテンツ、インフラストラクチャの各責任者。

このチェックリストの存在理由と実行タイミング

このSEOプロセス 内のリリース管理レイヤーは、技術ベースライン監査 からのクロールとインデックスのエビデンス、コンテンツ棚卸と監査 からの保持/統合/削除の判断、およびトピックマップと情報設計 からの宛先階層を消費します。これらのアウトプットは、リダイレクトやステージングを判断する前に存在していなければなりません。

このチェックリストは、宛先構造が承認された後、本番ルートがフリーズされる前に実行してください。早期に実行すると、チームはまだ変更される可能性のある宛先にリダイレクトをマッピングすることになります。遅れて実行すると、ルーティング、テンプレート、分析、またはローンチコミュニケーションの安全な修正がすでに高コストになっている可能性があります。

リダイレクトマップは最もリスクの高い成果物です。古いルートと新しいルートを結合するからです。価値ある古いURLはそれぞれ、その目的を保持する最も近い宛先に一対一でマッピングする必要があります。ホームページを汎用的な宛先として使用しないでください。訪問者を混乱させ、欠落している宛先を隠蔽することになります。

インプットとアウトプット

アウトプットはローンチ運用との契約です。責任者、エビデンス、または受け入れ条件がないスプレッドシートは引き継ぎとは見なされません。

チェックリスト

各項目は、何を、なぜ、どのように、ツール、および観察可能な完了条件を示します。しきい値は、より厳格なルールまたは文書化されたベースラインに基づくものにのみ置き換えてください。

フェーズ1：移行前の棚卸

1. 統合URLインベントリを構築する。 何を： クロール、XMLサイトマップ、分析、Search Console、バックリンクエクスポート、CMSレコード、有料キャンペーン、サーバーログから発見可能なすべての古いURLを結合します。なぜ： 単一のソースですべての価値あるまたはリクエストされたURLを含むものはありません。ナビゲーションに存在しないページでも、リンク、トラフィック、契約上の重要性を持つ場合があります。どのように： プロトコル、ホスト、大文字小文字、末尾スラッシュ、パラメータ、エンコード文字を正規化し、生のソース値を保持します。各URLがどこで見つかったかを記録した後にのみ重複排除します。ツール： クローラー、CMSエクスポート、分析、Search Console、バックリンクデータ、ログ。完了条件： すべてのソースに日付があり、すべての行に正規化されたURLと発見ソースがあり、重複が解決され、ソースの合計が最終インベントリと一致する。

2. すべてのURLの処分を分類する。 何を： 各URLに「保持」「移動」「統合」「削除」「調査中」のラベルを付けます。なぜ： コンテンツの判断が明確になるまで、リダイレクトは正しくマッピングできません。どのように： トラフィック、コンバージョン、バックリンク、インデックス状態、コンテンツ品質、ビジネスニーズ、インテントを組み合わせ、エビデンスと承認した所有者を記録します。ツール： インベントリワークブックとコンテンツ監査。完了条件： 対象範囲内のURLの100%に1つの処分、所有者、宛先または削除理由が割り当てられ、フリーズ時点で未解決の「調査中」の行がない。

3. 署名済みベースラインを取得する。 何を： ローンチ前のオーガニックセッション、クリック数、インプレッション数、コンバージョン数、収益、インデックス登録済みURL、クロールエラー、応答コード、アップタイム、パフォーマンスを優先テンプレートとディレクトリごとに保存します。なぜ： 日付のある比較ポイントがないと、通常の変動と移行による損害が同じように見えます。どのように： 少なくとも28日間の比較可能なデータをエクスポートし、キャンペーンと季節性を注記し、毎日レビューが必要な優先URLを特定します。ツール： 分析、Search Console、クローラー、ランクデータ、モニタリング。完了条件： ベースラインが読み取り専用で、再現可能で、セグメント化され、タイムスタンプが付与され、SEOと分析の責任者によって承認されている。

フェーズ2：リダイレクトマッピング

4. 可能な限りソースを一対一でマッピングする。 何を： 移動または統合された古いURLのそれぞれを、同じ主要インテントを持つ最も近い新しいURLに割り当てます。なぜ： 正確な宛先は訪問者にとっての継続性を維持し、クローラーに一貫性のある置き換えシグナルを提供します。どのように： トピック、製品、地域、言語、タスクを比較。統合は存続するページにマッピングし、意図的な削除を文書化します。一致しないURLをホームページにマッピングしないでください。ツール： リダイレクトマップワークブック、インベントリ、宛先クロール。完了条件： 変更されるすべてのソースに1つの承認された結果があり、すべての宛先が関連性があり対象範囲内であり、ホームページへの汎用マッピングがゼロである。

5. ローンチ前にリダイレクトの仕組みを検証する。 何を： ステータスコード、宛先、クエリ動作、大文字小文字のバリエーション、プロトコル、サブドメイン、末尾スラッシュ、ファイル、キャンペーンURLをテストします。なぜ： 正しく見えるスプレッドシートでも、ループ、チェーン、有効なページを飲み込むワイルドカード、エラーを返す宛先が発生する可能性があります。どのように： ステージングまたはプロキシルールを生成し、すべてのソースをリクエストし、ホップを追跡し、最終URLを承認済みマップと比較します。ツール： 自動化HTTPテスト、クローラー、サーバー設定レビュー。完了条件： マッピングされたソースの100%が1回の恒久リダイレクトホップで承認済みの200宛先に到達。ループ、チェーン、一時リダイレクト、エラー宛先がゼロ。

6. 正規URL、リンク、サイトマップをリダイレクトと整合させる。 何を： 正規URL 、内部リンク、hreflang参照、構造化データ、フィード、XMLサイトマップが最終URLを直接指すようにします。なぜ： 古いURLをリダイレクトしながら公開を続けると、矛盾した移行シグナルが発生し、クローラーのリクエストを浪費します。どのように： すべての参照ソースをクロールし、正規化されたターゲットをリダイレクトマップと比較します。ツール： クローラー、レンダリング済みHTML、サイトマップパーサー、設定差分。完了条件： 最終ページは承認された例外がない限り自己正規化し、リダイレクトされたURLへの内部参照がゼロ、新しいサイトマップには正規の200 URLのみが含まれる。

フェーズ3：ステージング検証

7. ステージングを公開インデックス可能にせずにテストする。 何を： 完全なステージングリリースをクロールし、検索エンジンが環境をインデックスするのを防ぎます。なぜ： チームは重複サイトが検索結果に表示されるのを許さずに、クローラーレベルのエビデンスを必要とします。どのように： 外部クローラーにはアクセス制御を使用し、本番サイトがJavaScriptレンダリングに依存する場合は認証済み内部クロールを実行します。ステージングブロックは一時的なリリース設定として扱い、そのまま本番にコピーしないでください。ツール： 認証済みクローラー、ブラウザ、応答ヘッダー検査。完了条件： 期待されるステージングインベントリがテストチームによってクロール可能であり、許可されていない公開インデックスがブロックされ、本番ローンチチェックリストがステージング専用の制御を明示的に削除する。

8. テンプレートと優先ジャーニーを検証する。 何を： すべてのテンプレートから代表的なページに加えて、ナビゲーション、検索、フォーム、サインアップ、チェックアウト、ローカライゼーション、ページネーション、フィルター、エラーページをテストします。なぜ： ホームページの合格だけでは、商品ページの正規URLバグや、分析を抑制する同意状態の破損を発見できません。どのように： デバイスとテンプレートのマトリックスを作成し、クリーンなセッションとリターンセッションをテストし、各結果のスクリーンショットまたは応答エビデンスを記録します。ツール： ブラウザ、アクセシビリティチェッカー、構造化データバリデーター、分析デバッガー、トランザクションテスト。完了条件： 対象範囲内のすべてのテンプレートと主要ジャーニーが合意されたブラウザとデバイスで合格し、重大な欠陥がゼロである。

9. ステージングを承認済み契約と比較する。 何を： タイトル、説明、見出し、正規URL、robotsディレクティブ、構造化データ、内部リンク、応答コード、コンテンツ、分析タグを旧サイトおよび宛先仕様と比較します。なぜ： プラットフォーム移行では、表示されるコピーがそのままでも、メタデータが失われたりレンダリングが変更されたりすることがよくあります。どのように： 旧本番とステージングを同じ設定でクロールし、テンプレートごとに差異をセグメント化し、意図された変更のみを承認します。ツール： クロール差分レポートとソース検査。完了条件： すべての実質的な差異が修正されるか、所有者と理由を添えた承認済み変更としてリストされ、偶発的なnoindex、正規URL、コンテンツ、トラッキングの変更がゼロである。

10. リリース候補をフリーズする。 何を： URLインベントリ、リダイレクトマップ、ルート定義、正規URLとrobotsルール、サイトマップ生成、分析と同意設定、DNS/CDN計画、関連のない本番デプロイメントをフリーズします。なぜ： テスト結果はテストされたバージョンにのみ適用されます。どのように： リリース成果物にタグを付け、変更をインシデントパスに制限し、緊急編集の影響を受けるものは再テストを要求します。ツール： デプロイメントシステム、変更ログ、承認記録。完了条件： 1つの不変の候補が命名され、アクセスが制限され、すべての例外に所有者がおり、フリーズ後のすべての変更にテスト結果が付随している。

フェーズ4：ローンチ日

11. 一元管理されたラン ブックを実行する。 何を： ルーティング、アプリケーション、DNS/CDN、分析、サイトマップ、モニターを承認された順序でデプロイします。なぜ： 順序付けられていない並行変更は、障害の特定を困難にし、ロールバックを危険にします。どのように： 1名の移行リーダーが各ステップを指示し、割り当てられたオペレーターが完了を記録し、バリデーターが次の依存ステップの前にエビデンスをテストします。ツール： ラン ブック、デプロイメントログ、DNSチェック、共有インシデントチャンネル。完了条件： 各行に実際の時刻、オペレーター、結果、エビデンスリンクがあり、口頭での確認のみに基づいて完了とマークされた依存関係がない。

12. ローンチスモークテストを実行する。 何を： ホームページ、robotsファイル、サイトマップ、テンプレートごとに少なくとも1つのURL、すべての優先ジャーニー、分析の受信、およびリダイレクトソースの層化サンプルをテストします。なぜ： 最も迅速な安全な対応は、キャッシュとクローラーが障害を拡散する前に、広範な障害を検出することから生まれます。どのように： 本番ネットワークの外部からテストし、デスクトップとモバイルを使用し、サーバー配信のHTMLとレンダリング出力の両方を検証し、フリーズされた期待値と比較します。ツール： クローラー、ブラウザ、HTTPクライアント、分析リアルタイムビュー、トランザクションモニター。完了条件： 重要なページが意図されたステータスとコンテンツを返し、優先リダイレクトが正確な宛先に到達し、分析イベントが正しいURLで到着し、すべてのローンチブロックチェックに合格する。

13. ディスカバリーシグナルを送信して検証する。 何を： 最終サイトマップを公開し、robotsと正規URLの動作を確認し、少数の優先URLについて検査をリクエストします。なぜ： クリーンなディスカバリーシグナルは、クローラーがインデックスの保証としてではなく、宛先セットに遭遇するのに役立ちます。どのように： 各本番サイトマップを1回送信し、代表的な新しいURLを検査し、Googleが報告する正規URLとインデックス状態を記録します。ツール： サイトマップとインデックス作成 およびURL検査 。完了条件： サイトマップが到達可能でフリーズされた正規インベントリを含み、代表的な検査で本番ブロックや誤った正規URLが表示されず、すべての警告に所有者がいる。

フェーズ5：ローンチ後のモニタリング

14. 最初の72時間をインシデントウィンドウとして監視する。 何を： アップタイム、5xx、4xx、リダイレクト障害、レイテンシ、クロール量、分析受信、コンバージョン、サイトマップ処理、優先ジャーニーを継続的または最短の実用的間隔で監視します。なぜ： インフラとルーティングの欠陥は迅速に表面化しますが、検索パフォーマンスはより長くかかるため、唯一のローンチアラームとして使用すべきではありません。どのように： 署名済みベースラインと比較し、テンプレートとディレクトリでセグメント化し、アラートをオンコール担当者にルーティングします。ツール： ログ、分析、クローラー、アップタイムモニター 、インシデントダッシュボード。完了条件： ダッシュボードに未説明のローンチクリティカルなアラートがなく、各インシデントに所有者とタイムスタンプがあり、24時間、48時間、72時間のレビューが署名されている。

15. 安定化後も検索とインデックスのモニタリングを継続する。 何を： ページレベルのクリック数、インプレッション数、インデックス状態、選択された正規URL、クロールエラー、ディレクトリパフォーマンス、コンバージョン結果を少なくとも4週間追跡します。なぜ： クロール、正規URLの選択、インデックスの置き換えは、インフラ検証よりも遅れます。どのように： 同等の期間を比較し、移動されたURLを変更されていないコントロールから分離し、1日の合計だけに反応するのではなくクラスターを調査します。ツール： Google Search Pages 、ディレクトリビュー 、URL検査、分析、ログ。完了条件： 優先宛先が発見可能かつインデックス可能であり、古いURLが一貫して承認された宛先に解決され、未説明の損失にチケットが作成され、所有権が通常のレポーティングサイクルに移行している。

AmICitedのツール

AmICitedはローンチのエビデンスとモニタリング画面を提供しますが、承認されたリダイレクトマップとデプロイメントログが運用上の真実のソースとして残ります。

判断ルール

これらはリリースのガードレールであり、普遍的な検索エンジンのしきい値ではありません。ローンチ前に合意し、リスクが必要とする場合には厳格化してください。

ロールバックは既知の良好なサービス状態を復元するものであり、通常の検索変動を元に戻すものではありません。ローンチ権限者が合意されたルールを適用し、エビデンスを記録します。

deliverables

エンジニアリングとSEOがアクセス可能な、バージョン管理された1つの移行管理パッケージを引き渡します。行レベルのレコードにはワークブックまたはデータベース、ローンチアクションにはラン ブック、ライブ測定にはダッシュボードを使用します。

これには以下を含める必要があります：フリーズされたインベントリとソースの調整、所有者とテスト付きの承認済みリダイレクトマップ、マッチングされた旧/ステージング/新クロール、メタデータ/正規URL/robots/サイトマップ/hreflang/構造化データ/リンク/分析の差分、署名済みベースラインと優先コホート、ローンチラン ブックと復旧手順、数値ロールバックルールと判断責任者、および24時間/48時間/72時間のエビデンスと4週間のモニタリング所有権。

移行リーダーは、正確なリリースを特定し、すべての重要テストを証明し、各ルーティング判断を再構築し、すべての例外を割り当てることができなければなりません。そうでなければ、パッケージは不完全です。

よくある問題

リダイレクトマップが現在のサイトマップのみを使用する。 孤立したURL、キャンペーンURL、バックリンク、以前にインデックスされたルートが失われるため、すべてのスプレッドシート行は合格するが、実際のリクエストは失敗します。

ホームページがデフォルトの宛先になる。 ユーザーは無関係な場所に着地し、クローラーシグナルは曖昧になり、欠落したコンテンツは実装の進捗として偽装されます。

リダイレクトは機能するが、参照は古いまま。 ナビゲーション、hreflang、正規URL、構造化データ、サイトマップが引き続きクローラーを不要なホップと矛盾した宛先に送り続けます。

ステージングの保護設定が本番にまで及ぶ。 コピーされたnoindex、認証ルール、robotsブロック、CDNポリシーがインデックス可能性 を破壊します。明示的な削除ステップと外部テストを要求してください。

チームがホームページのみを検証する。 共有テンプレートは、ホームページが合格している間に数千のページを誤設定する可能性があります。すべてのテンプレートをサンプリングし、ルールを大規模にクロールしてください。

無関係なリリースが同時に出荷される。 プラットフォーム、分析、同意、ナビゲーション、チェックアウト、CDNの変更が同じ期間に行われると、障害の特定や復旧が困難になります。

検索の評価が早すぎる、または広すぎる。 サイト全体の合計は、破損したディレクトリを隠し、1回の変動の大きい日が不必要な修正を促します。移動されたコホート、変更なしのコントロール、ディレクトリ、マッチングされた期間を比較してください。

ロールバックが障害発生時に議論される。 適切な計画は、ローンチ前にしきい値、意思決定者、復旧時間、コマンド、データへの影響、検証手順を指定します。

次のフェーズ

最初の72時間が安定したら、次のステップは継続的なリフレッシュと反復 です。このチェックリストからの署名済みベースライン、最終URLマッピング、ローンチ注釈、ディレクトリコホート、既知の例外、インシデント履歴、指名された所有者が必要です。これらのインプットがなければ、後のトラフィック減少を移行による損害、通常の需要変化、コンテンツの劣化、または測定の失敗に確実に区別できません。

リダイレクトマップと移行注釈は恒久的に保持してください。重要でない発見事項は、深刻度、仮説、所有者、期限、検証方法を添えて通常のレポーティングサイクルに移行します。

よくある質問

SEOチームはいつサイトマイグレーションに参加すべきですか？

ルート、テンプレート、プラットフォームの制約が固定される前です。SEOは現在のURLを棚卸し、価値ある宛先を保護し、新しい情報設計に影響を与え、リダイレクト動作を定義し、測定可能なローンチおよびロールバックルールに合意するために十分な時間を必要とします。

直接の置き換え先がない場合、古いURLはホームページにリダイレクトすべきですか？

いいえ。古いURLは、同じユーザーインテントを満たす最も近いページにリダイレクトしてください。関連する宛先が存在せず、コンテンツを保持すべきでない場合は、ユーザーやクローラーを無関係なホームページに送るのではなく、誠実な404または410を返してください。

移行リダイレクトはどのくらいの期間維持すべきですか？

古いURLが引き続き訪問、リンク、ブックマーク、クローラーのリクエストを受ける可能性がある限り、恒久的リダイレクトを維持してください。これらを数週間で削除するローンチ用の仮設足場ではなく、耐久性のあるルーティングインフラとして扱ってください。

移行ローンチ前に何をフリーズすべきですか？

承認されたURLインベントリ、リダイレクトマップ、正規URLとrobotsルール、サイトマップ生成、分析と同意設定、DNSとCDNの変更、および関連のない本番リリースをフリーズします。緊急修正は、指定された変更管理パスに従います。

移行はいつロールバックすべきですか？

ローンチ前に合意された基準を使用します。持続的な利用不可、広範囲にわたる5xx応答、主要なジャーニーの破損、分析データの欠落、または優先URLのかなりの割合に影響し、合意された復旧期間内に安全に修正できないルーティング障害などの失敗に対してロールバックします。