ウェブサイト移行計画：フェーズ、リダイレクト、公開前チェック

892件のドメイン移行を対象とした2025年の調査では、Search Engine Journalによると、サイトが推定オーガニックトラフィックの元の水準を取り戻すまで平均523日かかったことが、Veza Digitalのウェブサイトリブランドガイド^[1]で紹介されています。これは、移行を単なる公開の成功ではなく、すでに獲得しているトラフィックを守るための施策として扱うべき理由です。

Webサイト移行計画では、リダイレクトファイルの公開後に何が起こるかまで含めて考える必要があります。検索エンジンは変更を検出しなければならず、訪問者は引き続きタスクを完了できなければならず、公開チームが離れた後も誰かが古いURLの責任を持ち続けなければなりません。

このガイドはプロジェクト計画です。詳細なテスト手順については、Webサイト移行テストのガイドを参照してください。ドメイン変更に特化した内容については、SEOドメイン変更を参照してください。

移行フェーズ、担当者、成果物の一覧#

スケジュールは、デザインチームが希望する公開日ではなく、承認ゲートを中心に組み立てます。以下は説明用のプロジェクトスケジュールであり、すべてのケースに共通するリードタイム要件ではありません。

移行フェーズ、タイミング、成果物、担当者

日付より前に依存関係をスケジュールする#

SEO責任者が移行先を承認してから、エンジニアリングが本番ルールを書きます。リダイレクトはサイトマップの切り替え前にステージングでの検証を通過し、切り替えをチームが確定する前に体験テストを完了しなければなりません。

安定したコンテンツを持つ小規模な案内サイトでは、監査とマッピングを同時に進められます。これにより引き継ぎ時間は短縮されますが、タスクテストを省略してよい理由にはなりません。問い合わせフォームに不具合があれば、見た目は整っていても移行は商業的に無意味になります。

表に共有責任が示されている場合は、責任者を一人指名し、サポートするレビュー担当者を記録してください。監査が始まる前にこれを行い、誰が公開を延期でき、誰がロールバックを承認できるのかも明確にします。そうしないと、未解決の判断が、展開の時間枠が終わるまさにその時にエンジニアリングへ持ち込まれがちです。

レガシーサイトを監査し、ベースラインを設定する#

まずはScreaming FrogまたはSitebulbを使って公開サイトをクロールします。CMSのエクスポート、XMLサイトマップ、分析用のランディングページ、サーバーログも補完として用いてください。クローラーは内部リンクをたどって孤立ページを見つけることはできないからです。

ホスト名設定が自明だと思わないでください。デスクトップのサンプルでは、wwwの使用率は2019年の48.64%から2022年の41.01%へ低下したと、HTTP Archiveの技術レポート^[2]は示しています。自社のホストの挙動は、慣例ではなく明示的なテストが必要です。

監査可能なエクスポートを作成する#

各エクスポートに定義済みのスキーマを設定し、別のチームメンバーがベースラインを再現できるようにします。

• crawl-export.csv: URL、ステータスコード、canonical の対象、インデックス可能性、タイトル、テンプレート、内部リンク数を含めます。正規化された一致キーがある場合でも、元の URL 文字列をそのまま保持します。
• gsc-landing-pages-12m.csv: 利用可能な年次の Search Console 履歴を、ランディングページ、日付、クリック数、表示回数、プロパティとともにエクスポートします。エクスポート間でフィルターを一貫させてください。
• backlinks-by-url.csv: Ahrefs、Semrush、または別の被リンクツールを使用して、遷移先 URL、参照ドメイン数、重要なリンク元ページを記録します。
• host-check.csv: HTTPS と HTTP のリクエストについて、要求した URL、リダイレクトの経路、最終的なホスト名、canonical タグを記録します。ホスト名のバリエーション、大文字小文字の違い、末尾スラッシュの挙動も含めてください。

外部レビューは、既存の可視性の問題と移行リスクを切り分けるのに役立ちます。Baikou のウェブサイトの検索可視性をレビューする^[3]ためのリソースは、どの既存ページをより詳しく調査すべきかを判断する際の有用な参考資料です。

使える参照基準を固定する#

baseline-metrics.csvを作成し、インデックス済みページ数、クロール統計、テンプレート別の Core Web Vitals、ページタイプ別のコンバージョンイベントを含めます。測定日と収集方法も含め、実環境のパフォーマンスを無関係なラボテストと比較しないようにします。

重要なテンプレートについては、自動アクセシビリティ結果とキーボードのみでの操作の所見を添付します。訪問者がナビゲーションを開けるか、フォームを送信できるか、エラーから回復できるか、認証を完了できるかを記録し、監査スコアだけを保存しないようにします。

エクスポートは日付付きの共有フォルダに保存し、すべての所有者がアクセスできるようにします。監査が終了したら、そのスナップショットを保持してください。修正は変更メモを付けた新しい日付版で行います。

すべてのURLを対応付け、リダイレクトルールを書き出す#

在庫を計画的な順序で進めます:

1. レガシーURLを分類する。 レスポンスステータス、トラフィック、被リンク、コンテンツ価値を組み合わせて判断します。
2. 移行先を選ぶ。 同じ訪問者の意図を満たす、最も近いページを選択します。
3. レスポンスを割り当てる。 恒久的な移動、一時的な振り分け、真の削除を区別します。
4. ルールの動作をテストする。 パス、パラメータ、アセット、ホスト名の正規化、ルールの優先順位を確認します。

利便性より関連性を優先する#

価値のある参照ドメインがある壊れたページは、調査が必要です。実質的な内容がない薄いアーカイブは、代替先を必要としないかもしれません。どちらの判断も、現在のレスポンスコードだけで行うべきではありません。

統合には編集承認が必要です。複数の記事を1つのトピックハブにまとめる場合、コンテンツ所有者は、そのハブが各記事で扱っていた質問に答えていることを確認しなければなりません。広いカテゴリページが自動的に同等の移行先になるわけではありません。

旧URLケース別のリダイレクトアクションとステータスコード

実装前に意図を確定するために、恒久的なリダイレクトと一時的なリダイレクトの挙動を使い分けてください。一時的なルーティングには、単に別のレスポンスコードを選ぶだけでなく、有効期限の判断が必要です。

繰り返し実行できる1ホップのチェック#

表の各行はすべて1ホップで終わるべきです。2026年10月27日（UTC約01:20）に、クラウドサーバーからcurlを使って、リダイレクトを追わずにRedirHubの自社ホームページの4つのバリエーションをリクエストしました。各リダイレクト版は、ホームページに1回のホップで到達しました:

自分のホストの各バリエーションに対して curl -sS -o /dev/null -w "%{http_code} %{redirect_url}" を実行し、起動前に2回目のリダイレクトを返すものがあれば修正してください。上記の301と308の組み合わせは問題ありません。どちらも恒久的であり、違いが重要になるのはリクエストメソッドを保持する必要がある場合だけです。

明示的な例外を記述する#

キャンペーンの帰属情報と機能的なクエリパラメータは保持しますが、時代遅れのセッション識別子や、遷移先を壊すパラメータをむやみに引き継がないでください。エンコードされた文字、重複するパラメータ、深いパスを実際のアプリケーションでテストしてください。

ダウンロード可能なファイルとリンクされた画像を含めてください。コマース案件では、GrumspotのShopify移行のリダイレクトベストプラクティス^[4]が、ストアフロントの挙動と併せてルールを見直すためのプラットフォーム固有の文脈を提供します。

Patrick Stoxの移行チェックリスト^[5]では、アセットを含む直接の恒久的マッピングと、チェーンを概ね3ホップ以内に抑えることが推奨されています。ホスト名のリダイレクト、プロトコルのリダイレクト、パスの書き換えを重ねるのではなく、最終的な宛先へ直接解決することを優先してください。

承認済みのマップは、旧URL、宛先、想定レスポンス、理由、担当者、レビュー担当者を含むバージョン管理されたファイルとして保存してください。具体的なマッピングを広範なパターンより優先し、いずれかを変更した場合は必ずレビューを求めてください。Migration Redirect Mapperは、旧URLと新URLのペアを整理するのに役立ちます。

両方のサイトの Search Console を設定する#

切り替え前にレポートアクセスを準備します。SEO リードは、旧プロパティと新プロパティを個別に確認する必要があります。統合ダッシュボードでは、他の箇所での成長の陰に、稼働しなくなった旧セクションの不具合が隠れてしまう可能性があります。

アクセスとレポートを準備する#

• 所有権を確認する： 組織が管理する永続的な確認方法を使用し、退任する請負業者のアカウントに依存しないでください。トラフィックを伴うサブドメインも監視対象に含めます。
• プロパティ範囲を一致させる： ドメイン プロパティにはホスト名とプロトコルのバリエーションが含まれますが、URL プレフィックス プロパティの境界はより狭くなります。比較対象が同等の URL セットをカバーしていることを確認してください。
• サイトマップを準備する： 想定する正規の遷移先から生成し、公開前に検証します。送信は、それらの遷移先とそのリダイレクトが本番環境で機能するまで保留してください。
• レポートをアーカイブする： パフォーマンスとインデックスのエクスポートを監査フォルダに保存し、フィルタとプロパティ名を記録します。
• レビュー担当者を割り当てる： 各プロパティに所有者とバックアップを設定し、安定化期間中は定期的なレビュー予定を設けます。

ドメイン移行を慎重に扱う#

対象となるドメイン移行では、旧プロパティでアドレス変更ツールの手順を準備し、リダイレクトが有効になってチェックが通過した後に送信します。URL のマッピングの代わりや、サポートされていない変更の代用として使わないでください。

旧プロパティは、レガシーURLが監視上なお重要である限り、検証済みのまま維持してください。早期にアクセスを削除すると、継続的なインプレッション、見逃されたURL、予期しないクロール挙動の調査が難しくなります。

分析の継続性も維持してください。イベント名、同意の挙動、クロスドメイン設定を確認し、トラッキング変更がトラフィックやコンバージョンの減少に見せかけないようにします。

同一ドメインでのプラットフォーム移行では、ドメインはそのままで背後のプラットフォームが変わる場合、Integration Modeにより新しいプラットフォーム（Cloudflare Workers、Vercel上のNext.js、またはCaddy）がDNS変更なしでRedirHubからリダイレクトマップを提供し、公開後に訪問者が依然としてアクセスする404を報告できます。

公開前チェックとGo / No-Go判断#

ホームページが合格しても、サイトの準備完了は証明されません。トラフィックのあるページ、リンクされたアセット、別形式のURL、そして訪問者が価値あるタスクを完了するために使うテンプレートからテストセットを作成してください。

インベントリをステージング環境で再現する#

エンジニアリングは、CDNルールやアプリケーションのリダイレクトを含め、本番のルーティングを隔離環境で再現すべきです。ホスト上書きやそれに相当する制御されたセットアップを使い、ステージングを検索エンジンに公開せずにレガシーリクエストを実行してください。

再現レポートには、要求されたURL、予想される遷移先、実際の遷移先、応答の経路、パラメータの結果、最終的なインデックス可能性が必要です。ループ、説明のつかないチェーン、予期しない成功レスポンス、遷移先の不一致、失われたパラメータ、エラーで終わるリダイレクトをフラグ付けしてください。

リソースと発見シグナルも確認してください:

• アプリケーション資産: JavaScript、CSS、画像、ダウンロードは、認証やルーティングの失敗なしに読み込まれなければなりません。
• 検索ディレクティブ: robots.txt、canonical タグ、hreflang 参照、内部リンク、サイトマップのエントリを確認してください。
• リリース制御: 本番環境がステージングのパスワード、誤ったクロールブロック、または意図しない noindex ディレクティブを引き継がないことを確認してください。
• 計測: ページビューだけでなく、テスト送信と完了したトランザクションを使ってコンバージョンイベントを検証してください。

当社の無料のリダイレクトチェッカーは再現作業を支援でき、301 リダイレクトサービスは遷移先のマッピング、必要なパスとクエリの転送、公開前の遷移テストを支援します。一括リダイレクト確認ワークフローを使用して、ブラウザでの抜き取り確認に頼るのではなく、結果を再現可能にしてください。

許可された削除を考慮しながら、レスポンスクラスの分布をベースラインと比較してください。インデックス済みページ数、オーガニッククリック、クローラーの活動は、公開後に本番比較の指標となります。ステージングでは技術的な準備完了を確認できますが、検索回復は確認できません。

人々が完了できるかどうかをテストする#

キーボードのみのナビゲーション、スクリーンリーダー、モバイル端末を使って、旧体験と新体験で同等のタスクを実行してください。チェックアウトまたはリードフォーム、認証、検証エラー、送信失敗後の回復を含めてください。

欧州アクセシビリティ法は、EUユーザー向けの対象製品およびサービスについて、2025年6月28日に施行されました。詳細はNiteco のウェブサイト移行ガイド^[6]に記載されています。適用される場合はアクセシビリティの受け入れをコンプライアンス関連として扱い、責任ある法務またはアクセシビリティの専門家にプロジェクトの範囲を確認してもらってください。

テスト前にタスクの受け入れ基準を作成してください。同等の条件下で再現可能な遅延がなく成功裏に完了することを要件とし、通常の参加者差を欠陥として扱うのではなく、タイミングの違いを調査してください。

リリース判断を明確にする#

移行リードは、具体的な証拠に基づいて承認を集める必要があります:

• 棚卸しとマッピング: 棚卸しは日付が明記され、遷移先の判断は承認済みで、リリースは確認済みのマップ版を参照していること。
• 技術的受け入れ: 高価値URLに未解決のルーティング失敗が残っていないこと。
• 体験面の受け入れ: 重要なタスクに、未解決のアクセシビリティ上または機能上の回帰がないこと。
• 復旧準備: バックアップは復元可能で、ロールバックは訓練済みで、トランザクション照合には担当者がいること。
• 運用カバレッジ: すべてのフェーズに責任者とエスカレーション先の連絡先があること。

高価値項目の失敗は公開を遅らせます。見た目だけの問題は記録された修正キューに入れられますが、壊れたチェックアウト、クロールのブロック、アクセス不能なフォームは見た目だけの問題ではありません。

順番に進めるローンチ当日の手順#

各アクションごとに、オペレーター、確認担当者、記録済み結果を含むランブックを使用してください。診断に必要な人員が対応可能な時間帯を選び、単にトラフィックチャートで最も静かな時間ではなく、低トラフィックの時間帯を選びます。午前3時に、誰もトラブルシューティングできないまま行うリリースは、チーム全員がオンラインの適度な時間帯でのリリースよりもリスクが高くなります。

切り替えを実行する#

1. 変更を凍結します。 合意した切り替え前の期間中は、両システムでコンテンツの公開とURLの編集を停止してください。進める前に、重要な例外を文書化し、影響を受けるマッピングテストを再生成します。
2. リリース成果物を確認します。 変更先構成を、チェックサムまたはバージョン識別子を使って承認済みのマップと照合してください。見慣れたファイル名だけでは、エンジニアリングが確認済みのルールを適用したことにはなりません。
3. ルーティングと新サイトを同時にデプロイします。 アプリケーション、CDN、インフラの変更を調整し、訪問者が途中まで切り替わった環境に遭遇しないようにしてください。制御されたリリースの一環として、本番環境専用のアクセス制限や意図しないインデックス登録ブロックを解除します。
4. 優先URLをスモークテストします。 価値の高い旧ランディングページ、被リンクの遷移先、トランザクションの प्रवेश点を確認してください。直接ルーティング、想定された応答、必要なパラメータ、インデックス可能な正規の遷移先を検証し、その後に全件の再チェックを開始します。
5. サイトマップを公開して送信します。 変更先が正しく解決されることを確認してから、本番サイトマップを公開してください。古い Search Console のプロパティには引き続きアクセスできる状態を保ち、該当する移転通知を完了します。
6. すべてのホスト名を確認します。 旧ドメインと稼働中のサブドメインについて、DNS解決、証明書の適用範囲、ルーティングを検証してください。別のエンドポイントが確実にそのリダイレクトを提供できるようになるまで、古いサーバーを廃止しないでください。
7. ライブの挙動を監視します。 エンジニアリングはサーバーエラーとリダイレクトログを監視し、分析担当は流入イベントを確認し、UX は重要なタスクを検証します。後の調査でリリースの影響と無関係な変更を区別できるよう、デプロイ時刻を記録してください。
8. 合意したロールバック規則を適用します。 重要な導線が失敗する、リダイレクトループが発生する、またはサーバーエラーが合意したベースラインの許容範囲を超えて増加した場合は、影響を受けたリリースを停止または元に戻してください。顧客が障害に遭遇している最中に、広範な本番環境の書き換えをその場で思いつきで行わないでください。

ロールバックを使える状態に保つ#

ロールバックがアプリケーションファイルの復元を意味するのか、ルーティングの切り替えを意味するのか、データの復元を意味するのか、あるいはその組み合わせなのかを定義します。トランザクション系サイトでは、新しい注文や送信内容を突き合わせずにインフラを巻き戻すと、二次障害につながる可能性があります。再調整の手順にはリリース前に責任者を明確に割り当て、負荷がかかった状態での巻き戻しにどれくらい時間がかかるのか、チームが把握できるよう全体の流れをリハーサルしておきます。

リダイレクト層は固定された背景ではなく、ロールバック判断の一部として扱います。新しいルーティングルールが障害の原因なら、コードだけをロールバックしても壊れたリダイレクトはそのまま有効です。Google のサイト移転に関するドキュメント^[7]では、移転開始時点からサーバー側リダイレクトを設定し、新しい URL が解決できるようになってからサイトマップを送信し、旧サイトと新サイトの Search Console プロパティを別々に監視することが推奨されています。したがって、デプロイは運用上の節目であり、移行の責任が終わる時点ではありません。

公開後の監視とリダイレクトの統制#

各監視期間には、名前付きの対応担当者を付けておきます。Siteimprove の Web 変革リスクガイダンス^[8]では、動的なリダイレクト台帳、割り当てられた責任、エスカレーション基準、暫定ルールの終了判断が、移行計画における運用上の抜け漏れとして示されています。

公開後の監視頻度

以下は提案される運用スケジュールです。確認作業を省略せず、リスクに応じて人員配置を調整してください。

変更を管理し、単なるインシデント対応にとどめない#

アナリティクスはトラッキングの整合性とベースライン比較を担当し、SEOは検索調査を担当し、エンジニアリングはデプロイとロールバックを担当し、コンテンツは遷移先の関連性と内部リンク修正を担当する。警告が適切な担当者に届くよう、文書化されたリダイレクト監視ワークフローを使用する。

インベントリは検索可能で版管理し、各変更にレビュー担当者を設定する。一時的なルールには有効期限と担当レビュー担当者が必要であり、期限切れは自動削除ではなく、トラフィックを確認したうえでの判断につなげるべきである。

Google のサイト移転に関するドキュメントでは、リダイレクトを少なくとも180日保持することが推奨されており、古い URL が引き続き Google 検索トラフィックを受けている場合はさらに長く保持することが推奨される。私たちの推奨は、バックリンク、ブックマーク、インデックス済み URL が何年にもわたって訪問者を送り続ける可能性があるため、恒久的な移転リダイレクトを無期限で維持することである。

SaaS 企業がブログをリソースディレクトリに移したとする。その後も、古いニュースレターが引き続き有望な訪問者を旧記事アドレスへ送るため、コンテンツ所有者はインベントリを整えるためにそれらのマッピングを廃止せず、有効なまま維持する。

回復の判断は、季節比較とページ単位の診断を伴う継続的な傾向で行う。公開初週が静かだったからといって成功は証明されず、トラフィック低下だけでは原因を特定できない。

RedirHub は、CSV インポート、パスおよびクエリの転送、接続済みホスト名に対する自動 HTTPS を備えた移行マッピングを提供する。RedirHub にアクセスして承認済み URL マップを運用に乗せ、公開後も旧リンクを機能させ続けよう。