サイト移行前のリダイレクトチェックリスト
DNSを切り替える前に確認したい15項目。価値の高い旧URL、リダイレクトマップ、チェーン、UTM、公開後モニタリングを整理し、移行後の流入ロスを防ぎます。
サイト移行は、デザインやコードよりもリダイレクト設計で失敗することがあります。DNSを切り替える前に確認すべき問いは単純です。重要な旧URLはすべて、1回のきれいなリダイレクトで正しい新URLに到達できるか。
このチェックリストは、次のような移行を進めるSEO、EC、開発チーム向けです。
- 新しいドメインへ
- 新しい CMS へ
- モノリスからヘッドレスまで
- サブドメインからルートドメインへ
- 従来のドキュメントやブログ構造からよりクリーンな URL システムへ
Shopify固有の例が必要な場合は、ShopifyのURLをheadlessへ移行してSEOを守る方法 も参照してください。このページは、ほぼすべてのスタックに使える広いチェックリストです。
ドメイン変更やワイルドカード転送も含む場合は、パスとUTMを保持してドメインを転送する方法 もあわせて確認してください。
譲れない目標
公開前に、次の 5 つがすべて満たされている必要があります。
- 価値の高い古い URL を適切な新しい URL にマッピングする
- 永続的な移動には永続的なリダイレクトを使う
- 可能な限り、リダイレクトは 1 ホップで解決する
- 内部リンクはすでに新しい正規 URL を指している
- トラフィックが切り替わる前に公開後モニタリングを準備しておく
これらのいずれかが欠けている場合、移行のリスクは急速に高まります。
リダイレクトのチェックリスト
1. 現在の URL をインベントリする
メモリからのリダイレクトを計画しないでください。
次から URL をプルします:
- XML サイトマップ
- 分析ランディング ページ
- Search Console のトップページ
- 有料キャンペーン URL
- 電子メール テンプレート
- バックリンクとパートナードキュメント
- 古いブログとドキュメントのアーカイブ
URL が検索トラフィック、コンバージョン トラフィック、またはサポート トラフィックを獲得した場合、その URL は移行インベントリに属します。
2. 最終的な正規ホスト名を早めに選択します
リダイレクト ルールを作成する前に、最終的な宛先標準を決定します。
https://new-brand.com- または
https://www.new-brand.com
ホストの決定を曖昧なままにしないでください。 http -> https -> www -> final のようなチェーンが表示される様子です。
3. リダイレクト マップを実際のシートまたは CSV に残す
少なくとも以下を追跡します:
old_url,new_url,status,priority,owner,notes
https://old-brand.com/pricing,https://new-brand.com/pricing,301,high,marketing,core landing page
https://old-brand.com/docs/api,https://new-brand.com/docs/api,301,high,engineering,docs migrationこれにより、マーケティング、SEO、エンジニアリング、サポートに 1 つの共有された信頼できる情報源が提供されます。
4. 最も価値の高い URL を最初に保護する
最も重要なページに優先順位を付けます。
- ホームページ
- 価格
- ドキュメント
- トップのオーガニックランディングページ
- キャンペーンページ
- 電子メールからリンクされた URL をサポート
トラフィックの少ないアーカイブ ページに、初日の上位コンバージョン パスと同じ注意を向けないでください。
5. 古い URL を最適な新しい宛先と一致させる
目標は、必ずしも 1 対 1 のパスの保存ではありません。目標は最適な目的地への適合です。
良い例:
- 旧製品ページ -> 新製品ページ
- 古いドキュメント ページ -> 同等のドキュメント ページ
- 削除されたキャンペーン ページ -> 最も近い現在のオファー ページ
悪い例:
- すべて -> ホームページ
- 廃止されたドキュメント -> ホームページ
- 壊れたディープリンク -> コンテキストのない一般的なカテゴリページ
6. 永続的な移動には永続的なリダイレクトを使用する
古い URL が戻ってこない場合は、永続的なリダイレクト ポリシーを使用してください。
どのコードを選択すればよいかわからない場合は、301 vs 302 vs 307 vs 308 リダイレクト を参照してください。
重要な点は、一時的な目的で永続的なサイトの移動を何ヶ月も実行したままにしないことです。
7. 意味のあるパス構造を保持します。
新しいサイトが同様の構造を維持している場合、パス保持ルールにより手動作業が軽減されます。
例:
/docs/*->/docs/*/blog/*->/blog/*/features/*->/features/*
構造が大幅に変更された場合は、ブラインド ワイルドカードの代わりに、高値のパスに対して明示的な 1 対 1 マッピングを使用します。
そのセットアップの実装パターンが必要な場合は、パスや UTM パラメーターを失わずにドメインをリダイレクトする方法 を参照してください。
8. 重要なクエリ文字列を保持する
これは次の場合に重要です。
- キャンペーンの帰属
- アフィリエイトパラメータ
- 追跡およびライフサイクル リンク
- アプリまたはページで使用される機能パラメータ
すべてのクエリ文字列が永久に存続するに値するわけではありませんが、重要なものは慎重に処理する必要があります。
9. 公開前にリダイレクト チェーンを削除する
PageSpeed やユーザーからリダイレクト パスが乱雑であると報告されるまで待ってはいけません。
チェーンを今すぐ折りたたみます:
old-url -> old-intermediate -> final-urlは次のようになります。
old-url -> final-urlより詳細なデバッグ ワークフローが必要な場合は、リダイレクト チェーンとループ を参照してください。
10. ステージング ホストまたは制御ホストでのテスト
パブリックカットオーバーの前に、以下をテストします。
- ホームページ
- トップのランディング ページ
- ドキュメント パス
- ブログ投稿
- パラメータ化された URL
- モバイルをターゲットとしたパス（存在する場合）
ブラウザー チェックと単純なコマンドライン チェックの両方を実行します。
curl -IL https://old-brand.com/docs/api11. 公開前または公開直後に内部リンクを更新する
リダイレクトはセーフティ ネットです。内部リンクは引き続き新しい正規 URL を直接指す必要があります。
含まれるもの:
- ナビリンク
- フッターリンク
- コンテンツ内リンク
- 製品 CTA
- ドキュメントサイドバー
- 移行によりパブリック URL が変更される場合の電子メール テンプレート
12. サイトマップ、正規、ナビゲーションを更新する
リダイレクト マップは移行の一部にすぎません。以下も更新します:
- XML サイトマップ
- 正規タグ
- 関連する場合は hreflang
- メインナビゲーション
- 必要に応じて構造化データの URL
リダイレクトが 1 つのことを示し、正規化が別のことを示している場合、後で自分でクリーンアップ作業を作成していることになります。
13. 公開前に公開後のモニタリングを準備する
最初の 7 ～ 14 日間の計画を立ててください。
- 404 を監視する
- 上位のリダイレクトされた URL を検査する
- 価値の高いページへのトラフィックを監視します
- キャンペーンのリンクを確認する
- ドキュメントとサポート リンクがまだ正しく表示されていることを確認します
これは、analytics、リダイレクト チェック、および リンク切れの監視 が、理論的に便利なものではなく、運用上便利になる場所です。
14. 古いリダイレクトレイヤーを十分な期間安定して維持する
公開時によくある間違いは、リダイレクトを 1 週間のタスクとして扱うことです。実際には、古いリンクは数か月または数年間トラフィックを受け続ける可能性があります。
これは特に次の場合に当てはまります。
- バックリンク
- ブックマーク
- PDF リンク
- パートナー ドキュメント
- 古いソーシャル投稿
リリース週の存続だけでなく、リダイレクトの耐久性を計画します。
15. 例外と特殊なケースを文書化する
すべての URL がリダイレクトに値するわけではありません。一部のページでは 404 または 410 が返されます。一部の法的ページまたはサポート ページでは、特別な処理が必要な場合があります。一部の古いアプリ ルートでは、単純なリダイレクトではなくデバイス対応ロジックが必要な場合があります。
後で不可解な動作にならないように、これらのケースを明示的に文書化してください。
実際の移行操作の順序
実行可能なロールアウト シーケンスを最短にしたい場合:
- URL のエクスポート
- 正規ホストを選択します
- リダイレクトマップの作成
- トップ URL をテストする
- チェーンを排除する
- 内部リンクとサイトマップを更新
- 公開
- 404 とリダイレクトされたトラフィックを監視する
この順序なら、エンジニアリング、マーケティング、SEO の関係者が作業内容を理解しやすくなります。
UrlEdge が役立つ場所
UrlEdge は、移行で次のことが必要な場合に適しています。
- 一括リダイレクト インポート
- ワイルドカード パス転送
- 高速グローバル伝播
- リダイレクト QA ツール
- リリース後のトラフィックの可視性
これは、リダイレクト ロジックをアプリ コード、リバース プロキシ、CMS プラグイン、DNS プロバイダー転送機能に散在させたくない場合に特に便利です。
よくある質問
古い URL はすべてどこかにリダイレクトする必要がありますか?
いいえ。一部の廃止された URL は実際のエラー状態を返すはずです。ただし、ビジネス価値やユーザーの期待をまだ持っているページは、関連する宛先にマップする必要があります。
すべてをホームページにリダイレクトすることは許容されますか?
通常はありません。これは、パスの意図を放棄し、ユーザーとクローラーの両方をイライラさせるため、最も弱い移行戦略の 1 つです。
移行リダイレクトはどのくらいの期間保持する必要がありますか?
ほとんどのチームが予想しているよりも長い。多くの場合、重要なリダイレクトは、リリース月を大幅に過ぎてもそのままにしておく必要があります。
時間がない場合、最初に何をテストすればよいですか?
ホームページ、価格設定、ドキュメント、トップのランディング ページ、キャンペーン リンク、および過去のトラフィックが最も強い URL を優先します。
関連する UrlEdge ガイド
権威ある参考文献
関連記事
すべて見る
Firebase Dynamic Linksの代替: アプリとキャンペーンリンク移行
Firebase Dynamic Linksの終了後に、既存のQR、広告、メール、アプリ導線を失わないための移行方針を整理します。必要なのは、ブランドURL、デバイス別ルーティング、明示的なフォールバックです。
301、302、307、308リダイレクトの違いと使い分け
サイト移行、キャンペーン、API移行でどのリダイレクトコードを選ぶべきかを整理します。判断軸は、変更が永続か一時か、HTTPメソッドを保持する必要があるかです。